• rcorre (6/6) Jun 14 2015 Suppose I have a function defined like so:
• Adam D. Ruppe (2/2) Jun 14 2015 You can use @property there, but you don't have to because you
• rcorre (5/7) Jun 14 2015 Thanks.
• Adam D. Ruppe (19/21) Jun 14 2015 You should really only use it when you know the function is
• Gary Willoughby (3/6) Jun 14 2015 Oh yes:
• ketmar (4/14) Jun 14 2015 only if you plan to use it like `foo =3D 5;`. i.e. exactly like field/
• Timon Gehr (12/27) Jun 14 2015 struct S{
• ketmar (12/32) Jun 14 2015 i'm afraid i didn't understood you here.

"rcorre" <ryan rcorre.net> writes:

Suppose I have a function defined like so:

void foo(int i) { }

intended to be called like:

5.foo

Should it be labeled with  property?
Or is  property only for true member functions?

"Adam D. Ruppe" <destructionator gmail.com> writes:

You can use  property there, but you don't have to because you 
can call it with optional parenthesis anyway.

"rcorre" <ryan rcorre.net> writes:

On Sunday, 14 June 2015 at 12:36:43 UTC, Adam D. Ruppe wrote:
 You can use  property there, but you don't have to because you 
 can call it with optional parenthesis anyway.

Thanks.

Is there a good reference for the current state of  property?
I know it was hotly debated for awhile (and maybe still is?).
I'm just never sure when I should be using it (if at all).

"Adam D. Ruppe" <destructionator gmail.com> writes:

On Sunday, 14 June 2015 at 12:53:43 UTC, rcorre wrote:
 Is there a good reference for the current state of  property?

Easy: it does absolutely nothing right now.

 I'm just never sure when I should be using it (if at all).

You should really only use it when you know the function is 
semantically the same as a field, aka if you want the  property 
function to be entirely invisible.

Don't ask if you want it callable without parens, likely ALL 
functions will remain that way, instead ask if you want it to be 
entirely substitutable for the return value.



I'd say in practice, only use it when you're returning a callable 
and want a.foo() to call the return value (so the fact that foo 
is actually a function is entirely hidden) or if you're returning 
a ref and want &a.foo to give the address of the referenced 
variable instead of a delegate to the function (again, the fact 
that it is a function is entirely hidden, it acts identically to 
the variable).

Though note that even now, since  property doesn't do anything 
yet, you'd still have to call it explicitly, which will mean 
compile errors when it is finally implemented...



So perhaps best is to just not use it at all.

"Gary Willoughby" <dev nomad.so> writes:

On Sunday, 14 June 2015 at 12:53:43 UTC, rcorre wrote:
 Is there a good reference for the current state of  property?
 I know it was hotly debated for awhile (and maybe still is?).
 I'm just never sure when I should be using it (if at all).

Oh yes:

http://wiki.dlang.org/Property_Discussion_Wrap-up

ketmar <ketmar ketmar.no-ip.org> writes:

On Sun, 14 Jun 2015 12:26:52 +0000, rcorre wrote:

 Suppose I have a function defined like so:
=20
 void foo(int i) { }
=20
 intended to be called like:
=20
 5.foo
=20
 Should it be labeled with  property?
 Or is  property only for true member functions?

only if you plan to use it like `foo =3D 5;`. i.e. exactly like field/
variable. compiler will not complain, but putting ` property` here is=20
stylistically wrong.=

Timon Gehr <timon.gehr gmx.ch> writes:

On 06/14/2015 05:50 PM, ketmar wrote:
 On Sun, 14 Jun 2015 12:26:52 +0000, rcorre wrote:

 Suppose I have a function defined like so:

 void foo(int i) { }

 intended to be called like:

 5.foo

 Should it be labeled with  property?
 Or is  property only for true member functions?

 only if you plan to use it like `foo = 5;`.

You can use it like that anyway.

 i.e. exactly like field variable.

struct S{
     void delegate() dg;
}

int main(){
     S s;
     s.dg=(){ writeln("!"); };
     s.dg();
}

Now show me the UFCS way.

 compiler will not complain, but putting ` property` here is
 stylistically wrong.

It's neither wrong nor right.

ketmar <ketmar ketmar.no-ip.org> writes:

On Sun, 14 Jun 2015 18:21:39 +0200, Timon Gehr wrote:

 only if you plan to use it like `foo =3D 5;`.

=20
 You can use it like that anyway.

sure, but i'm talking about style, not about compiler demands.


 i.e. exactly like field variable.

=20
 struct S{
      void delegate() dg;
 }
=20
 int main(){
      S s;
      s.dg=3D(){ writeln("!"); };
      s.dg();
 }
=20
 Now show me the UFCS way.

i'm afraid i didn't understood you here.


 compiler will not complain, but putting ` property` here is
 stylistically wrong.

 It's neither wrong nor right.

yet i never saw this:

  struct S { int n; }

  S s; s.n(42);

the whole concept of properties (not bolted into the compiler yet) is to=20
emulate *fields*. so it's stylistically right to declare something as a=20
property if one wants to use it like `foo =3D 42;`. that means `mymodule.fo=
o=20
=3D 42;` actually. yet `42.foo` means `42.module.foo`, which even looks=20
wrong.=