www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DIP23 draft: Fixing properties redux

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Walter and I have had a discussion on how to finalize properties.

http://wiki.dlang.org/DIP23

We got input from DIP21 (which we didn't want to clobber, hence the new 
DIP) and the recent discussion.

The proposal probably won't be accepted in its current form because it 
breaks some code. We hope to bring it to good shape with everyone's help.

In brief:

* Optional parens stay.

* Just mentioning a function or method without parens does NOT 
automatically take its address. (This is a change from the current 
behavior.)

* Read properties (using  property) work as expected with the mention 
that they may NOT be called with the parens. Any parens would apply to 
the returned value.

* Write properties (using  property) may only be used in the assignment 
form (no function-style call allowed).

It is understood that the current proposal is just a draft and there 
must be quite a few corner cases it doesn't discuss. We also understand 
it's impossible to reconcile all viewpoints and please all tastes. Our 
hope is to get to a point where the rules are self-consistent, 
meaningful, and complete.


Destroy.

Andrei
Feb 03 2013
next sibling parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
--0015174c1caa0ba6e404d4cdc175
Content-Type: text/plain; charset=UTF-8

I always wondered if there's a good way to incorporate opOpAssign family of
operators with the write property syntax.
Currently, using anything but the direct assignment fails, so even if
eventually the support for defining specific opOpAssign for properties
won't be implemented, at least the automatic rewrite of them would be nice:

struct A
{
public:
    int i()
    {
        return _i;
    }

    int i(int i_)
    {
        return _i = i_;
    }

private:
    int _i;
}

unittest
{
    A a;
    a.i += 2; // a.i(a.i() + 2);
}


On Sun, Feb 3, 2013 at 12:16 PM, Andrei Alexandrescu <
SeeWebsiteForEmail erdani.org> wrote:

 Walter and I have had a discussion on how to finalize properties.

 http://wiki.dlang.org/DIP23

 We got input from DIP21 (which we didn't want to clobber, hence the new
 DIP) and the recent discussion.

 The proposal probably won't be accepted in its current form because it
 breaks some code. We hope to bring it to good shape with everyone's help.

 In brief:

 * Optional parens stay.

 * Just mentioning a function or method without parens does NOT
 automatically take its address. (This is a change from the current
 behavior.)

 * Read properties (using  property) work as expected with the mention that
 they may NOT be called with the parens. Any parens would apply to the
 returned value.

 * Write properties (using  property) may only be used in the assignment
 form (no function-style call allowed).

 It is understood that the current proposal is just a draft and there must
 be quite a few corner cases it doesn't discuss. We also understand it's
 impossible to reconcile all viewpoints and please all tastes. Our hope is
 to get to a point where the rules are self-consistent, meaningful, and
 complete.


 Destroy.

 Andrei

-- Bye, Gor Gyolchanyan. --0015174c1caa0ba6e404d4cdc175 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">I always wondered if there&#39;s a good way to incorporate= opOpAssign family of operators with the write property syntax.<div style>C= urrently, using anything but the direct assignment fails, so even if eventu= ally the support for defining specific opOpAssign for properties won&#39;t = be implemented, at least the automatic rewrite of them would be nice:</div> <div style><br></div><div style>struct A</div><div style>{</div><div style>= public:</div><div style>=C2=A0 =C2=A0 int i()</div><div style>=C2=A0 =C2=A0= {</div><div style>=C2=A0 =C2=A0 =C2=A0 =C2=A0 return _i;</div><div style>= =C2=A0 =C2=A0 }</div><div style><br></div><div style> =C2=A0 =C2=A0 int i(int i_)</div><div style>=C2=A0 =C2=A0 {</div><div style=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 return _i =3D i_;</div><div style>=C2=A0 =C2=

=C2=A0 =C2=A0 int _i;</div></div><div style>}</div><div style> <br></div><div style>unittest<br>{</div><div style>=C2=A0 =C2=A0 A a;</div>= <div style>=C2=A0 =C2=A0 a.i +=3D 2; // a.i(a.i() + 2);<br>}</div></div><di= v class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Sun, Feb 3, 2= 013 at 12:16 PM, Andrei Alexandrescu <span dir=3D"ltr">&lt;<a href=3D"mailt= o:SeeWebsiteForEmail erdani.org" target=3D"_blank">SeeWebsiteForEmail erdan= i.org</a>&gt;</span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex">Walter and I have had a discussion on how to= finalize properties.<br> <br> <a href=3D"http://wiki.dlang.org/DIP23" target=3D"_blank">http://wiki.dlang= .org/DIP23</a><br> <br> We got input from DIP21 (which we didn&#39;t want to clobber, hence the new= DIP) and the recent discussion.<br> <br> The proposal probably won&#39;t be accepted in its current form because it = breaks some code. We hope to bring it to good shape with everyone&#39;s hel= p.<br> <br> In brief:<br> <br> * Optional parens stay.<br> <br> * Just mentioning a function or method without parens does NOT automaticall= y take its address. (This is a change from the current behavior.)<br> <br> * Read properties (using property) work as expected with the mention that = they may NOT be called with the parens. Any parens would apply to the retur= ned value.<br> <br> * Write properties (using property) may only be used in the assignment for= m (no function-style call allowed).<br> <br> It is understood that the current proposal is just a draft and there must b= e quite a few corner cases it doesn&#39;t discuss. We also understand it&#3= 9;s impossible to reconcile all viewpoints and please all tastes. Our hope = is to get to a point where the rules are self-consistent, meaningful, and c= omplete.<br> <br> <br> Destroy.<span class=3D"HOEnZb"><font color=3D"#888888"><br> <br> Andrei<br> </font></span></blockquote></div><br><br clear=3D"all"><div><br></div>-- <b= r>Bye,<br>Gor Gyolchanyan. </div> --0015174c1caa0ba6e404d4cdc175--
Feb 03 2013
prev sibling next sibling parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
--001517588610331aff04d4cdc3cb
Content-Type: text/plain; charset=UTF-8

Sorry, forgot the  property.


On Sun, Feb 3, 2013 at 12:27 PM, Gor Gyolchanyan <
gor.f.gyolchanyan gmail.com> wrote:

 I always wondered if there's a good way to incorporate opOpAssign family
 of operators with the write property syntax.
 Currently, using anything but the direct assignment fails, so even if
 eventually the support for defining specific opOpAssign for properties
 won't be implemented, at least the automatic rewrite of them would be nice:

 struct A
 {
 public:
     int i()
     {
         return _i;
     }

     int i(int i_)
     {
         return _i = i_;
     }

 private:
     int _i;
 }

 unittest
 {
     A a;
     a.i += 2; // a.i(a.i() + 2);
 }


 On Sun, Feb 3, 2013 at 12:16 PM, Andrei Alexandrescu <
 SeeWebsiteForEmail erdani.org> wrote:

 Walter and I have had a discussion on how to finalize properties.

 http://wiki.dlang.org/DIP23

 We got input from DIP21 (which we didn't want to clobber, hence the new
 DIP) and the recent discussion.

 The proposal probably won't be accepted in its current form because it
 breaks some code. We hope to bring it to good shape with everyone's help.

 In brief:

 * Optional parens stay.

 * Just mentioning a function or method without parens does NOT
 automatically take its address. (This is a change from the current
 behavior.)

 * Read properties (using  property) work as expected with the mention
 that they may NOT be called with the parens. Any parens would apply to the
 returned value.

 * Write properties (using  property) may only be used in the assignment
 form (no function-style call allowed).

 It is understood that the current proposal is just a draft and there must
 be quite a few corner cases it doesn't discuss. We also understand it's
 impossible to reconcile all viewpoints and please all tastes. Our hope is
 to get to a point where the rules are self-consistent, meaningful, and
 complete.


 Destroy.

 Andrei

-- Bye, Gor Gyolchanyan.

-- Bye, Gor Gyolchanyan. --001517588610331aff04d4cdc3cb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Sorry, forgot the property.</div><div class=3D"gmail_extr= a"><br><br><div class=3D"gmail_quote">On Sun, Feb 3, 2013 at 12:27 PM, Gor = Gyolchanyan <span dir=3D"ltr">&lt;<a href=3D"mailto:gor.f.gyolchanyan gmail= .com" target=3D"_blank">gor.f.gyolchanyan gmail.com</a>&gt;</span> wrote:<b= r> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><div dir=3D"ltr">I always wondered if there&= #39;s a good way to incorporate opOpAssign family of operators with the wri= te property syntax.<div> Currently, using anything but the direct assignment fails, so even if event= ually the support for defining specific opOpAssign for properties won&#39;t= be implemented, at least the automatic rewrite of them would be nice:</div=

<div><br></div><div>struct A</div><div>{</div><div>public:</div><div>=C2=A0= =C2=A0 int i()</div><div>=C2=A0 =C2=A0 {</div><div>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 return _i;</div><div>=C2=A0 =C2=A0 }</div><div><br></div><div> =C2=A0 =C2=A0 int i(int i_)</div><div>=C2=A0 =C2=A0 {</div><div>=C2=A0 =C2= =A0 =C2=A0 =C2=A0 return _i =3D i_;</div><div>=C2=A0 =C2=A0 }</div><div><br=
</div><div>private:</div><div><div>=C2=A0 =C2=A0 int _i;</div></div><div>}=

<br></div><div>unittest<br>{</div><div>=C2=A0 =C2=A0 A a;</div><div>=C2=A0 = =C2=A0 a.i +=3D 2; // a.i(a.i() + 2);<br>}</div></div><div class=3D"gmail_e= xtra"><div><div class=3D"h5"><br><br><div class=3D"gmail_quote">On Sun, Feb= 3, 2013 at 12:16 PM, Andrei Alexandrescu <span dir=3D"ltr">&lt;<a href=3D"= mailto:SeeWebsiteForEmail erdani.org" target=3D"_blank">SeeWebsiteForEmail = erdani.org</a>&gt;</span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex">Walter and I have had a discussion on how to= finalize properties.<br> <br> <a href=3D"http://wiki.dlang.org/DIP23" target=3D"_blank">http://wiki.dlang= .org/DIP23</a><br> <br> We got input from DIP21 (which we didn&#39;t want to clobber, hence the new= DIP) and the recent discussion.<br> <br> The proposal probably won&#39;t be accepted in its current form because it = breaks some code. We hope to bring it to good shape with everyone&#39;s hel= p.<br> <br> In brief:<br> <br> * Optional parens stay.<br> <br> * Just mentioning a function or method without parens does NOT automaticall= y take its address. (This is a change from the current behavior.)<br> <br> * Read properties (using property) work as expected with the mention that = they may NOT be called with the parens. Any parens would apply to the retur= ned value.<br> <br> * Write properties (using property) may only be used in the assignment for= m (no function-style call allowed).<br> <br> It is understood that the current proposal is just a draft and there must b= e quite a few corner cases it doesn&#39;t discuss. We also understand it&#3= 9;s impossible to reconcile all viewpoints and please all tastes. Our hope = is to get to a point where the rules are self-consistent, meaningful, and c= omplete.<br> <br> <br> Destroy.<span><font color=3D"#888888"><br> <br> Andrei<br> </font></span></blockquote></div><br><br clear=3D"all"><div><br></div></div=
</div><span class=3D"HOEnZb"><font color=3D"#888888">-- <br>Bye,<br>Gor Gy=

</font></span></div> </blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>Bye,<br>Gor = Gyolchanyan. </div> --001517588610331aff04d4cdc3cb--
Feb 03 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Sunday, 3 February 2013 at 08:16:08 UTC, Andrei Alexandrescu 
wrote:
 * Just mentioning a function or method without parens does NOT 
 automatically take its address. (This is a change from the 
 current behavior.)

I don't understand.
 * Read properties (using  property) work as expected with the 
 mention that they may NOT be called with the parens. Any parens 
 would apply to the returned value.

Great !
 * Write properties (using  property) may only be used in the 
 assignment form (no function-style call allowed).

Awesome. Two things now : - free functions annotated properties with one argument ? (are they setter ? getters ? both ?) - order of evaluation.
Feb 03 2013
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, February 03, 2013 03:16:08 Andrei Alexandrescu wrote:
 Destroy.

Overall, it looks good. It sounds like it's basically arguing for fully implementing property as intended save for the fact that parenless function calls on normal functions are allowed. And that's pretty much what I've been arguing for during all of this latest property debate. However, one issue that I'm concerned about with regards to properties which hasn't really been discussed much and which doesn't have a whole lot to do with how they're declared (but rather the syntax of how they're used) is how to handle symbol clashes. For instance, if you have the free function auto prop(int[] arr) {...} in module a.b.c, and you have auto prop(int[] arr) {...} in module a.d.e, how do you deal with code that does import a.b.c; import a.d.e; auto var = arr.prop; Syntactically, there's no way to indicate which of the two functions you mean. It's a problem that only occurs with free functions and UFCS (since with member functions, the member function wins in any conflict with a free function, and member functions on the same type can't be in different modules), but it's definitely something that can happen. And we really should come up with a fix for it. The best that I can think of at the moment is something like auto var = arr.a.b.c.prop; where you're trying to use a.b.c.prop, but I don't know if that's a good syntax or not. It could certainly cause problems if arr were a user-defined type with a property called arr, so maybe adding parens would help auto var = arr.(a.b.c).prop; but that's still a bit ugly. I don't know if there's a good way that _isn't_ ugly though. I suppose that we could get away with arguing that symbol renaming would be required alias a.b.c.prop myprop; auto var = arr.myprop; but I don't know that that's a great solution either. AFAIK though, it's the only way that we have to deal with the problem right now. - Jonathan M Davis
Feb 03 2013
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/3/13 3:50 AM, Jonathan M Davis wrote:
 On Sunday, February 03, 2013 03:16:08 Andrei Alexandrescu wrote:
 Destroy.

Overall, it looks good. It sounds like it's basically arguing for fully implementing property as intended save for the fact that parenless function calls on normal functions are allowed. And that's pretty much what I've been arguing for during all of this latest property debate. However, one issue that I'm concerned about with regards to properties which hasn't really been discussed much and which doesn't have a whole lot to do with how they're declared (but rather the syntax of how they're used) is how to handle symbol clashes. For instance, if you have the free function auto prop(int[] arr) {...} in module a.b.c, and you have auto prop(int[] arr) {...} in module a.d.e, how do you deal with code that does import a.b.c; import a.d.e; auto var = arr.prop;

First off, defining a top-level property ought indeed to have an air of definitive-ness, so this is good. It also illustrates that defining top-level properties should be rare. To fix this, no need to add syntax: import a.b.c; import a.b.c : prop1 = prop; import a.d.e; import a.d.e : prop2 = prop; auto v1 = arr.prop1; // goes to a.b.c.prop auto v2 = arr.prop2; // gies to a.d.e.prop Andrei
Feb 03 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Sunday, 3 February 2013 at 08:51:58 UTC, Jonathan M Davis 
wrote:
 auto prop(int[] arr) {...}

 in module a.b.c, and you have

 auto prop(int[] arr) {...}

 in module a.d.e, how do you deal with code that does

 import a.b.c;
 import a.d.e;
 auto var = arr.prop;

 Syntactically, there's no way to indicate which of the two 
 functions you mean.

Couldn't an alias make it ? alias propFromA = a.b.c.prop; auto var = arr.propFromA;
Feb 03 2013
prev sibling next sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Sunday, 3 February 2013 at 08:16:08 UTC, Andrei Alexandrescu 
wrote:
 It is understood that the current proposal is just a draft and 
 there must be quite a few corner cases it doesn't discuss.

Here are some more test cases to think about: http://wiki.dlang.org/Property_Discussion_Wrap-up#Unified_test_suite Specifically, for ref-returning function, I assume the &-operator is meant to return the address of the callable for non- property function, but the address of the returned value for properties? David
Feb 03 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Sunday, 3 February 2013 at 09:04:59 UTC, David Nadlinger wrote:
 On Sunday, 3 February 2013 at 08:16:08 UTC, Andrei Alexandrescu 
 wrote:
 It is understood that the current proposal is just a draft and 
 there must be quite a few corner cases it doesn't discuss.

Here are some more test cases to think about: http://wiki.dlang.org/Property_Discussion_Wrap-up#Unified_test_suite Specifically, for ref-returning function, I assume the &-operator is meant to return the address of the callable for non- property function, but the address of the returned value for properties?

I wanted to avoid the topic as it is basically solved for properties. Andrei, is that possible to split the DIP in 2 : one for properties and one for other functions. It seems that the property part is agreed by most people, but the other one raise more questions.
Feb 03 2013
prev sibling next sibling parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Sunday, 3 February 2013 at 08:16:08 UTC, Andrei Alexandrescu 
wrote:
 In brief:

 * Optional parens stay.

 Andrei

Will we keep the optional -property (or similar) for those of us that *want* enforced parens, even with UFCS? Did a sensible reasons actually ever come up for allowing optional parens on non-UFCS?
Feb 03 2013
next sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
03-Feb-2013 13:11, monarch_dodra пишет:
 On Sunday, 3 February 2013 at 08:16:08 UTC, Andrei Alexandrescu wrote:
 In brief:

 * Optional parens stay.

 Andrei

Will we keep the optional -property (or similar) for those of us that *want* enforced parens, even with UFCS? Did a sensible reasons actually ever come up for allowing optional parens on non-UFCS?

Using verbs for actions and nouns for querying data and not being thrilled with useless parens everywhere? But let's not discus this again. -- Dmitry Olshansky
Feb 03 2013
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/3/13 4:11 AM, monarch_dodra wrote:
 On Sunday, 3 February 2013 at 08:16:08 UTC, Andrei Alexandrescu wrote:
 In brief:

 * Optional parens stay.

 Andrei

Will we keep the optional -property (or similar) for those of us that *want* enforced parens, even with UFCS?

No. Thanks for the reminder - I updated the DIP.
 Did a sensible reasons actually ever come up for allowing optional
 parens on non-UFCS?

This is a judgment call as reasonable people may disagree on it. Walter and I both believe optional parens are a good thing for D. At this point, we don't think one more pass through the pros and cons would change our opinion. Andrei
Feb 03 2013
prev sibling next sibling parent reply Johannes Pfau <nospam example.com> writes:
Am Sun, 03 Feb 2013 03:16:08 -0500
schrieb Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>:


 It is understood that the current proposal is just a draft and there 
 must be quite a few corner cases it doesn't discuss. We also
 understand it's impossible to reconcile all viewpoints and please all
 tastes. Our hope is to get to a point where the rules are
 self-consistent, meaningful, and complete.
 
 
 Destroy.
 
 Andrei

"If a function returns a reference, then assignment through the paren-less call should work: " This is the only part where I would disagree. Why is this special rule necessary if we have full property support? I think this would still allow too many false positives. One important aspect that this proposal doesn't cover yet is whether we want to allow "semantic rewriting" for properties: ---- Struct a; a.property++; //would this be legal? ---- for other corner cases this list is a good start: http://wiki.dlang.org/Property_Discussion_Wrap-up#Implementation_concerns * Can we get a reference to the property? What does &x.property mean? * How can we get the getter / setter functions? Do we need to get those? * What is the type of the property? Return type, setter function type or getter function type? How to get the other types? * What does x.property++ do? ([http://www.prowiki.org/wiki4d/wiki.cgi?DocComments/Property#Semanticrewritingofproperties Semantic rewriting]) * Is returning ref values from the getter OK? * Is taking ref values in the setter OK? * Should all properties be nothrow? pure? getter const? ** Probably better as a rule for style guide. * Are UFCS properties possible? How do they work exactly? * How do you disambiguate property functions when they're free functions which conflict? ** Normal UFCS functions can be force called by using their fully qualified name. That's not possible for properties if function call syntax is disallowed? * How many parameters are allowed for property functions? ** Are default parameters allowed? ** Especially consider the example about __FILE__ and __LINE__ * Are templated properties allowed? ** The access syntax for properties doesn't allow providing types
Feb 03 2013
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/3/13 5:14 AM, Johannes Pfau wrote:
 "If a function returns a reference, then assignment through the
 paren-less call should work: "

 This is the only part where I would disagree. Why is this special rule
 necessary if we have full  property support? I think this would still
 allow too many false positives.

(As a note, this is the current behavior.) The way I see it is this is a natural consequence of optional parens. The name of a function without a "&" prepended or a "()" after it will invoke the function, and that's that.
 One important aspect that this proposal doesn't cover yet is whether we
 want to allow "semantic rewriting" for properties:
 ----
 Struct a;
 a.property++; //would this be legal?
 ----

It's dangerous to get too clever about that. Anyhow, such rewrites are possible: ++a.p ----> { auto v = a.p; ++v; a.p = v; return v; }() a.p++ ----> { auto v = a.p; ++a.p; return v; }() and so on.
 for other corner cases this list is a good start:
 http://wiki.dlang.org/Property_Discussion_Wrap-up#Implementation_concerns

 * Can we get a reference to the property? What does
    &x.property mean?

We need to add this to the proposal. There are two schools of thought here: 1. Make properties emulate regular variables as much as possible. In that case &a.p is the same as &(a.p), i.e. it applies to the returned value. (One counter-argument here is that properties should seldom return a reference because that breaks encapsulation.) 2. Allow people to do whatever they need to do without much aggravation. In that case &a.p obeys the normal rules of taking a method's address, and &(a.p) applies to the returned value. I favor (2) and put it in http://wiki.dlang.org/DIP23. Will talk to Walter.
 * How can we get the getter / setter functions? Do we need to get those?

Per (2) above there is no need for special provisions.
 * What is the type of the property? Return type, setter function type
    or getter function type? How to get the other types?

typeof(r.front) is the return type of the property, typeof(&(r.front)) is the type of a pointer to the return type of the property where applicable, and typeof(&r.front) is the (possibly ambiguous) address of the method. (To disambiguate one would use the appropriate receiver type.)
 * What does x.property++ do?
    ([http://www.prowiki.org/wiki4d/wiki.cgi?DocComments/Property#Semanticrewritingofproperties
    Semantic rewriting])

Added to http://wiki.dlang.org/DIP23.
 * Is returning ref values from the getter OK?

I see no reason to disallow it at the language level.
 * Is taking ref values in the setter OK?

How do you mean that?
 * Should all properties be nothrow? pure? getter const?
 ** Probably better as a rule for style guide.

No restriction at language level.
 * Are UFCS properties possible? How do they work exactly?
 * How do you disambiguate property functions when they're free
    functions which conflict?

I think it would be best to simply disallow parameterless module-level properties. // at top level property int foo(); // error property int goo(int); // fine, assume a getter for int
 ** Normal UFCS functions can be force
    called by using their fully qualified name. That's not possible for
    properties if function call syntax is disallowed?

Correct. Writing property buys the writer into a constrained universe.
 * How many parameters are allowed for property functions?

One or two at top level, zero or one at member level.
 ** Are default parameters allowed?
 ** Especially consider the example about __FILE__ and __LINE__

I'd say no. Just keep it simple and focused on the goal.
 * Are templated properties allowed?
 ** The access syntax for properties doesn't allow providing types

No. Templated member variables are not allowed either. Andrei
Feb 03 2013
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 02/03/2013 05:11 PM, Andrei Alexandrescu wrote:
 ...

 2. Allow people to do whatever they need to do without much aggravation.
 In that case &a.p obeys the normal rules of taking a method's address,
 and &(a.p) applies to the returned value.

 I favor (2) and put it in http://wiki.dlang.org/DIP23. Will talk to Walter.

That is horrible! The entire language construct is necessarily a bit of a patchwork, but there is no reason to aggravate this gratuitously.
 ...
 * Are templated properties allowed?
 ** The access syntax for properties doesn't allow providing types

No.

Ditto.
 Templated member variables are not allowed either.

(Actually they are silently rewritten to static member variables. I do not like that.)
Feb 03 2013
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/3/13 11:34 AM, Johannes Pfau wrote:
 You have to consider cases though where you have both a setter and a
 getter returning a 'ref value'.

  property ref int value();
  property void value(int new);

For now I disallow 0-parameter top level properties. This is a good argument for keeping things that way.
 * Is it valid to define both at the same time?
 * Which one is used for assignment etc?

 * Is taking ref values in the setter OK?

How do you mean that?

property int value(ref int new); IIRC that was just meant to complement the "is returning ref OK". Usually nothing bad can happen. Although the ref parameter could be converted into a pointer with some nasty tricks it's probably not the job of the language to prevent that.

Yah, there should be no restrictions there. Andrei
Feb 03 2013
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/3/13 11:28 AM, Steven Schveighoffer wrote:
 This sounds good. It might be a bit confusing, but nice in the fact that
 &(a.b) always means address of whatever b returns, whether it is a field
 or property.

Yah, this is a good rule of thumb for generic code. Note that there's a subtlety in the expression "&expr.name". This is not precedence, just use of punctuation to express a unit. Attempting to decompose it by inserting parens yields different things altogether: &(expr.name) and (&expr).name are not mere redirections of precedence.
  property int foo(); // error
  property int goo(int); // fine, assume a getter for int

I think this is a possible solution, and I can live with that, I'm fairly certain that some people use global properties currently, so they will not be too happy.

Yah, let's see how this restriction pans out.
 No. Templated member variables are not allowed either.

Wait, what? I don't like this idea. Why should this not be allowed: property void x(T)(T t) {_x = to!(typeof(_x))(t);}

Yah, I misspoke. Properties can be templated subject to the other restrictions. Andrei
Feb 03 2013
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/3/13 11:28 AM, kenji hara wrote:
 2013/2/4 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org
 <mailto:SeeWebsiteForEmail erdani.org>>

     We need to add this to the proposal. There are two schools of
     thought here:

     1. Make properties emulate regular variables as much as possible. In
     that case &a.p is the same as &(a.p), i.e. it applies to the
     returned value. (One counter-argument here is that properties should
     seldom return a reference because that breaks encapsulation.)

     2. Allow people to do whatever they need to do without much
     aggravation. In that case &a.p obeys the normal rules of taking a
     method's address, and &(a.p) applies to the returned value.

     I favor (2) and put it in http://wiki.dlang.org/DIP23. Will talk to
     Walter.


 I have thought about the problem, and filed an enhancement.
 http://d.puremagic.com/issues/show_bug.cgi?id=9062

 But, Walter disagreed against it.
 http://d.puremagic.com/issues/show_bug.cgi?id=9062#c13

   Kenji Hara

Now that an overhaul is on the table, that warrants a second look. Andrei
Feb 03 2013
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
I'm glad Johannes brought up all these cases. They all need to go into the DIP.
Feb 03 2013
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-02-03 17:11, Andrei Alexandrescu wrote:

 It's dangerous to get too clever about that. Anyhow, such rewrites are
 possible:

 ++a.p ----> { auto v = a.p; ++v; a.p = v; return v; }()
 a.p++ ----> { auto v = a.p; ++a.p; return v; }()

 and so on.

Is that part of the proposal or not? -- /Jacob Carlborg
Feb 04 2013
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, February 04, 2013 09:22:56 Jacob Carlborg wrote:
 On 2013-02-03 17:11, Andrei Alexandrescu wrote:
 It's dangerous to get too clever about that. Anyhow, such rewrites are
 possible:
 
 ++a.p ----> { auto v = a.p; ++v; a.p = v; return v; }()
 a.p++ ----> { auto v = a.p; ++a.p; return v; }()
 
 and so on.

Is that part of the proposal or not?

It is now, though I don't think that it was intially. It's in the "Applying operators" section. - Jonathan M Davis
Feb 04 2013
prev sibling parent Chad Joan <chadjoan gmail.com> writes:
On 02/03/2013 11:11 AM, Andrei Alexandrescu wrote:
 On 2/3/13 5:14 AM, Johannes Pfau wrote:
 ...

 for other corner cases this list is a good start:
 http://wiki.dlang.org/Property_Discussion_Wrap-up#Implementation_concerns

 * Can we get a reference to the property? What does
 &x.property mean?

We need to add this to the proposal. There are two schools of thought here: 1. Make properties emulate regular variables as much as possible. In that case &a.p is the same as &(a.p), i.e. it applies to the returned value. (One counter-argument here is that properties should seldom return a reference because that breaks encapsulation.) 2. Allow people to do whatever they need to do without much aggravation. In that case &a.p obeys the normal rules of taking a method's address, and &(a.p) applies to the returned value. I favor (2) and put it in http://wiki.dlang.org/DIP23. Will talk to Walter.

I disagree with this. I think that allowing address-of on getters is potentially a big source of trouble. I've felt that getters should be forbidden from returning lvalues. So returning ref from a getter is not OK, but const ref should be fine. Anyone who wants to make the property behave like a reference should define an appropriate setter for it. There are a couple reasons for this: - It would be nice to allow variables/fields to have property as an annotation. This would forbid address-of to allow seamless transition into fully-implemented property functions later. To make the roundtrip possible, the property functions should also disallow address-of. - Allowing mutation of a getter's expression can create unwanted ambiguities when attempting to apply property rewrites. Without an lvalue getter it becomes unambiguous: any side-effectful operation on a property (that isn't direct assignment, or something requiring a read) will call both its getter and setter.
 ...

Andrei

Feb 04 2013
prev sibling next sibling parent kenji hara <k.hara.pg gmail.com> writes:
--f46d044306b0f1a91604d4d47754
Content-Type: text/plain; charset=UTF-8

2013/2/4 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>

 We need to add this to the proposal. There are two schools of thought here:

 1. Make properties emulate regular variables as much as possible. In that
 case &a.p is the same as &(a.p), i.e. it applies to the returned value.
 (One counter-argument here is that properties should seldom return a
 reference because that breaks encapsulation.)

 2. Allow people to do whatever they need to do without much aggravation.
 In that case &a.p obeys the normal rules of taking a method's address, and
 &(a.p) applies to the returned value.

 I favor (2) and put it in http://wiki.dlang.org/DIP23. Will talk to
 Walter.

I have thought about the problem, and filed an enhancement. http://d.puremagic.com/issues/show_bug.cgi?id=9062 But, Walter disagreed against it. http://d.puremagic.com/issues/show_bug.cgi?id=9062#c13 Kenji Hara --f46d044306b0f1a91604d4d47754 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">2013/2/4 Andrei Alexandrescu <span dir=3D"ltr">&lt;<a href= =3D"mailto:SeeWebsiteForEmail erdani.org" target=3D"_blank">SeeWebsiteForEm= ail erdani.org</a>&gt;</span><br><div class=3D"gmail_extra"><div class=3D"g= mail_quote"> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= adding-left:1ex"><div class=3D"im"><span style=3D"color:rgb(34,34,34)">We n= eed to add this to the proposal. There are two schools of thought here:</sp= an><br> </div> <br> 1. Make properties emulate regular variables as much as possible. In that c= ase &amp;a.p is the same as &amp;(a.p), i.e. it applies to the returned val= ue. (One counter-argument here is that properties should seldom return a re= ference because that breaks encapsulation.)<br> <br> 2. Allow people to do whatever they need to do without much aggravation. In= that case &amp;a.p obeys the normal rules of taking a method&#39;s address= , and &amp;(a.p) applies to the returned value.<br> <br> I favor (2) and put it in <a href=3D"http://wiki.dlang.org/DIP23" target=3D= "_blank">http://wiki.dlang.org/DIP23</a>. Will talk to Walter.</blockquote>= <div><br></div><div style>I have thought about the problem, and filed an en= hancement.</div> <div style><a href=3D"http://d.puremagic.com/issues/show_bug.cgi?id=3D9062"=
http://d.puremagic.com/issues/show_bug.cgi?id=3D9062</a><br></div><div><br=
</div><div style>But, Walter disagreed against it.</div><div style><a href=

magic.com/issues/show_bug.cgi?id=3D9062#c13</a><br> </div><div style><br></div><div style>=C2=A0Kenji Hara</div></div></div></d= iv> --f46d044306b0f1a91604d4d47754--
Feb 03 2013
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sun, 03 Feb 2013 11:11:05 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 On 2/3/13 5:14 AM, Johannes Pfau wrote:
 "If a function returns a reference, then assignment through the
 paren-less call should work: "

 This is the only part where I would disagree. Why is this special rule
 necessary if we have full  property support? I think this would still
 allow too many false positives.

(As a note, this is the current behavior.) The way I see it is this is a natural consequence of optional parens. The name of a function without a "&" prepended or a "()" after it will invoke the function, and that's that.
 One important aspect that this proposal doesn't cover yet is whether we
 want to allow "semantic rewriting" for properties:
 ----
 Struct a;
 a.property++; //would this be legal?
 ----

It's dangerous to get too clever about that. Anyhow, such rewrites are possible: ++a.p ----> { auto v = a.p; ++v; a.p = v; return v; }() a.p++ ----> { auto v = a.p; ++a.p; return v; }() and so on.
 for other corner cases this list is a good start:
 http://wiki.dlang.org/Property_Discussion_Wrap-up#Implementation_concerns

 * Can we get a reference to the property? What does
    &x.property mean?

We need to add this to the proposal. There are two schools of thought here: 1. Make properties emulate regular variables as much as possible. In that case &a.p is the same as &(a.p), i.e. it applies to the returned value. (One counter-argument here is that properties should seldom return a reference because that breaks encapsulation.) 2. Allow people to do whatever they need to do without much aggravation. In that case &a.p obeys the normal rules of taking a method's address, and &(a.p) applies to the returned value. I favor (2) and put it in http://wiki.dlang.org/DIP23. Will talk to Walter.

This sounds good. It might be a bit confusing, but nice in the fact that &(a.b) always means address of whatever b returns, whether it is a field or property.
 * Are UFCS properties possible? How do they work exactly?
 * How do you disambiguate property functions when they're free
    functions which conflict?

I think it would be best to simply disallow parameterless module-level properties. // at top level property int foo(); // error property int goo(int); // fine, assume a getter for int

I think this is a possible solution, and I can live with that, I'm fairly certain that some people use global properties currently, so they will not be too happy. But having to set global properties using a function call (global getters can simply be paren-less functions) isn't horrible.
 * Are templated properties allowed?
 ** The access syntax for properties doesn't allow providing types

No. Templated member variables are not allowed either.

Wait, what? I don't like this idea. Why should this not be allowed: property void x(T)(T t) {_x = to!(typeof(_x))(t);} As for templates that return a templated type, it should be allowed, although the calling syntax would have to be for the explicit template call, since you can't do IFTI on return values. In other words: template x(T) { property T x(){return to!(T)(_x);} } // could be shortened to normal property T x(T)() auto xcopy = obj.x!(string).x; Certainly, we need templated getters and setters at module levels: property T front(T)(T[] r) { return r[0];} -Steve
Feb 03 2013
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sun, 03 Feb 2013 11:28:52 -0500, Steven Schveighoffer  
<schveiguy yahoo.com> wrote:


 As for templates that return a templated type, it should be allowed,  
 although the calling syntax would have to be for the explicit template  
 call, since you can't do IFTI on return values.  In other words:

 template x(T) {  property T x(){return to!(T)(_x);} }  // could be  
 shortened to normal  property T x(T)()

 auto xcopy = obj.x!(string).x;

Hm... I actually am changing my mind on this, you should be able to do: auto xcopy = obj.x!(string); For the simple reason that if property is omitted, this would work (simple lack of parens). It makes no sense to make properties not have this ability. -Steve
Feb 03 2013
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sun, 03 Feb 2013 14:42:17 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 On 2/3/13 11:34 AM, Johannes Pfau wrote:
 You have to consider cases though where you have both a setter and a
 getter returning a 'ref value'.

  property ref int value();
  property void value(int new);

For now I disallow 0-parameter top level properties. This is a good argument for keeping things that way.

I think Johannes' argument applies to non-global properties. struct X { private int _val; property ref int value() { return _val;} property void value(int newv) { _val = newv; writeln("in setter!");} } So should setting 'value' call the specific setter, or call the getter and just write it? My vote would be to call the setter, since it wouldn't exist if the user didn't want to hook that call. However, it certainly begs the question, why would anyone return ref if they want to hook setting? One could always do this: void foo(ref int v) {v = 5;} X x; foo(x.value); I think it's still too early to make any assumptions at this point. Someone may find a good reason for that, and it's certainly just easier to allow code that is already valid than it is to come up with a reason to have an error. -Steve
Feb 03 2013
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sun, 03 Feb 2013 03:16:08 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 Walter and I have had a discussion on how to finalize properties.

 http://wiki.dlang.org/DIP23

I agree with everything in this. This looks exactly like what I wanted a few days ago. Thank you! One aspect not addressed is free-function properties: property int foo(int x) {return x * 5;} could be interpreted as: foo = 2; // not correct (for this example) int x = 2.foo; // correct Note that: property int foo(); property void foo(int x, int y); are both unambiguous. ================== I have a possible suggestion to fix this within your proposal: property on single-arg free functions ONLY enables a setter mode, it does not work as a UFCS getter. Therefore, if you wish to write a UFCS getter, omit the property designation. int foo(int x) {return x * 5;} foo = 2; // illegal int x = 2.foo; // OK, sets x to 10 int x = foo(2); // same as above property int foo(int x) {_foo = x;} foo = 2; // OK, sets _foo to 2 int x = 2.foo; // illegal int x = foo(2); // illegal I know this is not a complete solution, and can be confusing, but we have little options at this point, given existing code. Also note that we already have a way to specify a getter property on a user-defined type, UFCS isn't entirely necessary for that. This will break SOME declarations, but removing property should result in compiling code I think. -Steve
Feb 03 2013
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 02/03/2013 01:49 PM, Steven Schveighoffer wrote:
 On Sun, 03 Feb 2013 07:16:17 -0500, Steven Schveighoffer
 <schveiguy yahoo.com> wrote:

 On Sun, 03 Feb 2013 03:16:08 -0500, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 Walter and I have had a discussion on how to finalize properties.

 http://wiki.dlang.org/DIP23

I agree with everything in this. This looks exactly like what I wanted a few days ago. Thank you! One aspect not addressed is free-function properties:

I thought of one other problem with this proposal. You can no longer get a delegate of a property. Like it or not, there will be existing code that does get a delegate to properties (it is allowed now). I think we should provide a __traits accessor for this. Otherwise, there is no way to port said code to the new style. -Steve

T delegate() f = &a.prop -> auto f = ()=>a.prop; T delegate(T) f = &a.prop -> auto f = (T x)=>a.prop=x;
Feb 03 2013
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 02/03/2013 04:04 PM, Steven Schveighoffer wrote:
 On Sun, 03 Feb 2013 08:04:10 -0500, Timon Gehr <timon.gehr gmx.ch> wrote:

 T delegate() f = &a.prop -> auto f = ()=>a.prop;
 T delegate(T) f = &a.prop -> auto f = (T x)=>a.prop=x;

I don't like this solution. You are creating a dummy delegate function, and moving the stack frame into the heap, just so you can get a delegate to an already existing function. -Steve

The spec could be updated to allow/mandate eta-reduction where applicable.
Feb 03 2013
prev sibling parent Artur Skawina <art.08.09 gmail.com> writes:
On 02/03/13 16:04, Steven Schveighoffer wrote:
 On Sun, 03 Feb 2013 08:04:10 -0500, Timon Gehr <timon.gehr gmx.ch> wrote:
 
 T delegate() f = &a.prop -> auto f = ()=>a.prop;
 T delegate(T) f = &a.prop -> auto f = (T x)=>a.prop=x;

I don't like this solution. You are creating a dummy delegate function, and moving the stack frame into the heap, just so you can get a delegate to an already existing function.

Not really, it just needs to be specced properly. There's already a similar issue with lazy args, and the natural solution is the same. A trivial "{ return any_kind_of_hidden_delegate; }" lambda is functionally equivalent to a "cast(delegate)any_kind_of_hidden_delegate" expression. The "optimization" just needs to be mandated, so that you can rely on the "real" delegate being forwarded (ie the .funcptr should be the real one and such lambda shouldn't trigger heap allocation). artur
Feb 03 2013
prev sibling next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 02/03/2013 02:00 PM, kenji hara wrote:
 2013/2/3 Steven Schveighoffer <schveiguy yahoo.com
 <mailto:schveiguy yahoo.com>>
     ...

     I thought of one other problem with this proposal.  You can no
     longer get a delegate of a property.  Like it or not, there will be
     existing code that does get a delegate to properties (it is allowed
     now).

     I think we should provide a __traits accessor for this.  Otherwise,
     there is no way to port said code to the new style.


 On the contrary with you, I was read that we no longer get an address of
 ref returned value by address-op.

  property ref int foo();
 static assert(is(typeof(&foo) == ref int function()));  // typeof does
 not return int*

 If I am correct, there is no need for special enhancement like __traits.

The DIP actually misses to address this case.
Feb 03 2013
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/3/13 7:40 AM, kenji hara wrote:
 2013/2/3 Steven Schveighoffer <schveiguy yahoo.com
 <mailto:schveiguy yahoo.com>>

     I have a possible suggestion to fix this within your proposal:

      property on single-arg free functions ONLY enables a setter mode,
     it does not work as a UFCS getter.

   [snip]

 I was thinking the exact same thing.

Then we can't make this work: property ref T front(T[] array) { return array[0]; } unittest { auto a = [ 1, 2, 3]; auto b = a.front; } Andrei
Feb 03 2013
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 02/03/2013 06:47 PM, Steven Schveighoffer wrote:
 On Sun, 03 Feb 2013 12:36:10 -0500, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 On 2/3/13 7:40 AM, kenji hara wrote:
 2013/2/3 Steven Schveighoffer <schveiguy yahoo.com
 <mailto:schveiguy yahoo.com>>

     I have a possible suggestion to fix this within your proposal:

      property on single-arg free functions ONLY enables a setter mode,
     it does not work as a UFCS getter.

   [snip]

 I was thinking the exact same thing.

Then we can't make this work: property ref T front(T[] array) { return array[0]; } unittest { auto a = [ 1, 2, 3]; auto b = a.front; }

ref T front(T[] array) { return array[0]; } // same unittest

different unittest: unittest{ auto a = [()=>2, ()=>3, ()=>4]; assert(a.front()==2); }
 But I also can agree with the idea you currently have to make UFCS
 properties require a 'this' initial parameter.

 -Steve

Feb 03 2013
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/3/13 7:49 AM, Steven Schveighoffer wrote:
 On Sun, 03 Feb 2013 07:16:17 -0500, Steven Schveighoffer
 <schveiguy yahoo.com> wrote:

 On Sun, 03 Feb 2013 03:16:08 -0500, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 Walter and I have had a discussion on how to finalize properties.

 http://wiki.dlang.org/DIP23

I agree with everything in this. This looks exactly like what I wanted a few days ago. Thank you! One aspect not addressed is free-function properties:

I thought of one other problem with this proposal. You can no longer get a delegate of a property. Like it or not, there will be existing code that does get a delegate to properties (it is allowed now). I think we should provide a __traits accessor for this. Otherwise, there is no way to port said code to the new style.

In the proposal &a.b gets the delegate of a property. Andrei
Feb 03 2013
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 02/03/2013 06:38 PM, deadalnix wrote:
 On Sunday, 3 February 2013 at 17:37:03 UTC, Andrei Alexandrescu wrote:
 In the proposal &a.b gets the delegate of a property.

:facepalm:

+1.
Feb 03 2013
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/3/13 10:16 AM, Steven Schveighoffer wrote:
 Let's go with the current proposal, and I will address the __traits
 mechanism separately.

Yes, __traits is a nice hatch if we discover we find we can't do something. Hopefully we won't find any, or just one. Andrei
Feb 03 2013
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 02/03/2013 06:44 PM, Andrei Alexandrescu wrote:
 On 2/3/13 10:16 AM, Steven Schveighoffer wrote:
 Let's go with the current proposal, and I will address the __traits
 mechanism separately.

Yes, __traits is a nice hatch if we discover we find we can't do something. Hopefully we won't find any, or just one. Andrei

__traits is a lot cleaner than assigning meaning to parentheses.
Feb 03 2013
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-02-03 09:16, Andrei Alexandrescu wrote:
 Walter and I have had a discussion on how to finalize properties.

 http://wiki.dlang.org/DIP23

What about: writeln = "asd"; Allowed or not? -- /Jacob Carlborg
Feb 03 2013
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, February 03, 2013 13:34:14 Jacob Carlborg wrote:
 On 2013-02-03 09:16, Andrei Alexandrescu wrote:
 Walter and I have had a discussion on how to finalize properties.
 
 http://wiki.dlang.org/DIP23

What about: writeln = "asd"; Allowed or not?

I take it that you didn't read the DIP. At the very beginning of its section on "Write properties:" ----------- In order to use the assignment operator "=" property-style, the property annotation MUST be used. ----------- - Jonathan M Davis
Feb 03 2013
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-02-03 13:40, Jonathan M Davis wrote:

 I take it that you didn't read the DIP. At the very beginning of its section
 on "Write properties:"

 -----------
 In order to use the assignment operator "=" property-style, the  property
 annotation MUST be used.
 -----------

Right, I guess I missed that. -- /Jacob Carlborg
Feb 03 2013
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/3/13 10:48 AM, Johannes Pfau wrote:
 Am Sun, 03 Feb 2013 04:40:44 -0800
 schrieb Jonathan M Davis<jmdavisProg gmx.com>:

 On Sunday, February 03, 2013 13:34:14 Jacob Carlborg wrote:
 On 2013-02-03 09:16, Andrei Alexandrescu wrote:
 Walter and I have had a discussion on how to finalize properties.

 http://wiki.dlang.org/DIP23

What about: writeln = "asd"; Allowed or not?

I take it that you didn't read the DIP. At the very beginning of its section on "Write properties:" ----------- In order to use the assignment operator "=" property-style, the property annotation MUST be used. -----------

There's a example on the page though which contradicts this: static int x; ref int fun1() { return x; } fun1 = 42;

This introduces no contradiction. It's simple assignment to the result of fun1. Andrei
Feb 03 2013
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/3/13 7:34 AM, Jacob Carlborg wrote:
 On 2013-02-03 09:16, Andrei Alexandrescu wrote:
 Walter and I have had a discussion on how to finalize properties.

 http://wiki.dlang.org/DIP23

What about: writeln = "asd"; Allowed or not?

No because writeln is not a property. For non-properties there's no lowering of assignment. Andrei
Feb 03 2013
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/3/13 10:49 AM, Johannes Pfau wrote:
 Am Sun, 03 Feb 2013 10:37:45 -0500
 schrieb Andrei Alexandrescu<SeeWebsiteForEmail erdani.org>:

 On 2/3/13 7:34 AM, Jacob Carlborg wrote:
 On 2013-02-03 09:16, Andrei Alexandrescu wrote:
 Walter and I have had a discussion on how to finalize properties.

 http://wiki.dlang.org/DIP23

What about: writeln = "asd"; Allowed or not?

No because writeln is not a property. For non-properties there's no lowering of assignment. Andrei

Then this should be removed in the proposal: If a function returns a reference, then assignment through the paren-less call should work: unittest { static int x; ref int fun1() { return x; } fun1 = 42; }

No. That's not a lowering. Andrei
Feb 03 2013
prev sibling parent "TommiT" <tommitissari hotmail.com> writes:
On Sunday, 3 February 2013 at 15:48:00 UTC, Johannes Pfau wrote:
 -----------
 In order to use the assignment operator "=" property-style, the
  property annotation MUST be used.
 -----------

There's a example on the page though which contradicts this: static int x; ref int fun1() { return x; } fun1 = 42;

That example has nothing to do with properties. It's just: static int x; ref int fun1() { return x; } fun1() = 42; ...except that the empty parens were omitted (which is allowed there).
Feb 03 2013
prev sibling next sibling parent reply kenji hara <k.hara.pg gmail.com> writes:
--14dae93405dd1ea01304d4d13dec
Content-Type: text/plain; charset=UTF-8

2013/2/3 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>

 Walter and I have had a discussion on how to finalize properties.

 http://wiki.dlang.org/DIP23

Awesome!! After reading it, I thought that there is some consistent rules. 1. When a function is annotated with property, it cannot be called with parenthesis syntax. 2. 0-arg functions which not annotated with property can be called without parentheses. 3. Ref return getter can make "auxiliary setter", if formal getter is missing. 4. `typeof(exp)` never returns "function type". In other words, the actual type of `exp` and `typeof(exp)` should be same. 5. Both `&prop` and `&func` should return function pointer / delegate object 6. UFCS CAN NOT call global setter by getter syntax. I think that 4 to 6 are important points of this DIP. Based on the rules, I could write an exhaustive test case. alias Type = int; unittest { struct S { property Type foo(); // formal getter property void bar(Type); // formal setter property ref Type baz(); // ref return getter == auxiliary setter } S s; static assert( __traits(compiles, { s.foo; })); static assert(!__traits(compiles, { s.foo(); })); static assert(is(typeof(s.foo) == Type)); static assert(is(typeof(&s.foo) == Type delegate())); static assert( __traits(compiles, { s.bar = 1; })); static assert(!__traits(compiles, { s.bar(1); })); static assert(is(typeof(s.bar)) == false); static assert(is(typeof(&s.bar) == void delegate(Type))); static assert( __traits(compiles, { s.baz; })); static assert(!__traits(compiles, { s.baz(); })); static assert( __traits(compiles, { s.baz = 1; })); static assert(is(typeof(s.baz) == Type)); static assert(is(typeof(&s.foo) == ref Type delegate())); } unittest { struct S { Type foo(); // 0-arg function void bar(Type n); // 1-arg function ref Type baz(); // 0-arg ref return function } S s; static assert( __traits(compiles, { s.foo; })); static assert( __traits(compiles, { s.foo(); })); static assert(is(typeof(s.foo) == Type)); static assert(is(typeof(&s.foo) == Type delegate())); static assert(!__traits(compiles, { s.bar = 1; })); static assert( __traits(compiles, { s.bar(1); })); static assert(is(typeof(s.bar)) == false); static assert(is(typeof(&s.bar) == void delegate(Type))); static assert( __traits(compiles, { s.baz; })); static assert( __traits(compiles, { s.baz = 1; })); static assert( __traits(compiles, { s.baz(); })); static assert(is(typeof(s.baz) == Type)); static assert(is(typeof(&s.baz) == ref Type delegate())); } property Type foo(); property void bar(Type); property ref Type baz(); unittest { static assert( __traits(compiles, { foo; })); static assert(!__traits(compiles, { foo(); })); static assert(is(typeof(foo) == Type)); static assert(is(typeof(&foo) == Type function())); static assert( __traits(compiles, { bar = 1; })); static assert(!__traits(compiles, { bar(1); })); static assert(is(typeof(bar)) == false); static assert(is(typeof(&bar) == Type function())); static assert( __traits(compiles, { baz; })); static assert(!__traits(compiles, { baz(); })); static assert( __traits(compiles, { baz = 1; })); static assert(!__traits(compiles, { baz() = 1; })); static assert(is(typeof(baz) == Type)); static assert(is(typeof(&baz) == ref Type function())); } property Type foh(Type); property void bah(Type n, Type m); property ref Type bas(Type); Type hoo(Type); void var(Type, Type); ref Type vaz(Type); unittest { static assert( __traits(compiles, { foh = 1; }) && !__traits(compiles, { hoo = 1; })); static assert(!__traits(compiles, { foh(1); }) && __traits(compiles, { hoo(1); })); static assert(!__traits(compiles, { 1.foh; }) && __traits(compiles, { 1.hoo; })); static assert(!__traits(compiles, { 1.foh(); }) && __traits(compiles, { 1.hoo(); })); static assert(!__traits(compiles, { bah(1, 2); }) && __traits(compiles, { var(1, 2); })); static assert( __traits(compiles, { 1.bah = 2; }) && !__traits(compiles, { 1.var = 2; })); static assert(!__traits(compiles, { 1.bah(2); }) && __traits(compiles, { 1.var(2); })); static assert( __traits(compiles, { bas = 1; }) && !__traits(compiles, { vaz = 1; })); static assert(!__traits(compiles, { bas(1); }) && __traits(compiles, { vaz(1); })); static assert(!__traits(compiles, { bas(1) = 2; }) && __traits(compiles, { vaz(1) = 2; })); static assert(!__traits(compiles, { 1.bas; }) && __traits(compiles, { 1.vaz; })); static assert(!__traits(compiles, { 1.bas = 2; }) && __traits(compiles, { 1.vaz = 2; })); static assert(!__traits(compiles, { 1.bas(); }) && __traits(compiles, { 1.vaz(); })); static assert(!__traits(compiles, { 1.bas() = 2; }) && __traits(compiles, { 1.vaz() = 2; })); } Is this correct? Kenji Hara --14dae93405dd1ea01304d4d13dec Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">2013/2/3 Andrei Alexandrescu <span dir=3D"ltr">&lt;<a href= =3D"mailto:SeeWebsiteForEmail erdani.org" target=3D"_blank">SeeWebsiteForEm= ail erdani.org</a>&gt;</span><br><div class=3D"gmail_extra"><div class=3D"g= mail_quote"> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= adding-left:1ex">Walter and I have had a discussion on how to finalize prop= erties.<br> <br> <a href=3D"http://wiki.dlang.org/DIP23" target=3D"_blank">http://wiki.dlang= .org/DIP23</a></blockquote><div><br></div><div style>Awesome!!</div><div st= yle><br></div><div style>After reading it, I thought that there is some con= sistent rules.</div> <div style><br></div><div style><div>1. When a function is annotated with = property, it cannot be called with parenthesis syntax.</div><div>2. 0-arg f= unctions which not annotated with property can be called without parenthes= es.</div> <div>3. Ref return getter can make &quot;auxiliary setter&quot;, if formal = getter is missing.</div><div>4. `typeof(exp)` never returns &quot;function = type&quot;. In other words, the actual type of `exp` and `typeof(exp)` shou= ld be same.</div> <div>5. Both `&amp;prop` and `&amp;func` should return function pointer / d= elegate object</div><div>6. UFCS CAN NOT call global setter by getter synta= x.</div><div><br></div><div style>I think that 4 to 6 are important points = of this DIP. Based on the rules, I could write an exhaustive test case.</di= v> <div style><br></div><div style><div>alias Type =3D int;</div><div><br></di= v><div>unittest</div><div>{</div><div>=C2=A0 =C2=A0 struct S</div><div>=C2= =A0 =C2=A0 {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 property Type foo(); = =C2=A0 =C2=A0 =C2=A0 // formal getter</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0= property void bar(Type); =C2=A0 // formal setter</div> <div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 property ref Type baz(); =C2=A0 // ref re= turn getter =3D=3D auxiliary setter</div><div>=C2=A0 =C2=A0 }</div><div>=C2= =A0 =C2=A0 S s;</div><div>=C2=A0 =C2=A0 static assert( __traits(compiles, {= s.foo; =C2=A0 =C2=A0 }));</div><div>=C2=A0 =C2=A0 static assert(!__traits(= compiles, { s.foo(); =C2=A0 }));</div> <div>=C2=A0 =C2=A0 static assert(is(typeof(s.foo) =3D=3D Type));</div><div>= =C2=A0 =C2=A0 static assert(is(typeof(&amp;s.foo) =3D=3D Type delegate()));= </div><div><br></div><div>=C2=A0 =C2=A0 static assert( __traits(compiles, {= s.bar =3D 1; }));</div><div>=C2=A0 =C2=A0 static assert(!__traits(compiles= , { s.bar(1); =C2=A0}));</div> <div>=C2=A0 =C2=A0 static assert(is(typeof(s.bar)) =3D=3D false);</div><div=
=C2=A0 =C2=A0 static assert(is(typeof(&amp;s.bar) =3D=3D void delegate(Typ=

es, { s.baz; =C2=A0 =C2=A0 }));</div><div>=C2=A0 =C2=A0 static assert(!__tr= aits(compiles, { s.baz(); =C2=A0 }));</div> <div>=C2=A0 =C2=A0 static assert( __traits(compiles, { s.baz =3D 1; }));</d= iv><div>=C2=A0 =C2=A0 static assert(is(typeof(s.baz) =3D=3D Type));</div><d= iv>=C2=A0 =C2=A0 static assert(is(typeof(&amp;s.foo) =3D=3D ref Type delega= te()));</div><div>}</div><div>unittest</div> <div>{</div><div>=C2=A0 =C2=A0 struct S</div><div>=C2=A0 =C2=A0 {</div><div=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Type foo(); =C2=A0 =C2=A0 =C2=A0 =C2=A0 // 0-a=

// 1-arg function</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 ref Type baz(); =C2= =A0 =C2=A0 // 0-arg ref return function</div> <div>=C2=A0 =C2=A0 }</div><div>=C2=A0 =C2=A0 S s;</div><div>=C2=A0 =C2=A0 s= tatic assert( __traits(compiles, { s.foo; =C2=A0 =C2=A0 }));</div><div>=C2= =A0 =C2=A0 static assert( __traits(compiles, { s.foo(); =C2=A0 }));</div><d= iv>=C2=A0 =C2=A0 static assert(is(typeof(s.foo) =3D=3D Type));</div> <div>=C2=A0 =C2=A0 static assert(is(typeof(&amp;s.foo) =3D=3D Type delegate= ()));</div><div><br></div><div>=C2=A0 =C2=A0 static assert(!__traits(compil= es, { s.bar =3D 1; }));</div><div>=C2=A0 =C2=A0 static assert( __traits(com= piles, { s.bar(1); =C2=A0}));</div><div> =C2=A0 =C2=A0 static assert(is(typeof(s.bar)) =3D=3D false);</div><div>=C2= =A0 =C2=A0 static assert(is(typeof(&amp;s.bar) =3D=3D void delegate(Type)))= ;</div><div><br></div><div>=C2=A0 =C2=A0 static assert( __traits(compiles, = { s.baz; =C2=A0 =C2=A0 }));</div><div>=C2=A0 =C2=A0 static assert( __traits= (compiles, { s.baz =3D 1; }));</div> <div>=C2=A0 =C2=A0 static assert( __traits(compiles, { s.baz(); =C2=A0 }));= </div><div>=C2=A0 =C2=A0 static assert(is(typeof(s.baz) =3D=3D Type));</div=
<div>=C2=A0 =C2=A0 static assert(is(typeof(&amp;s.baz) =3D=3D ref Type del=

<div> property Type foo();</div><div> property void bar(Type);</div><div> p= roperty ref Type baz();</div><div><br></div><div>unittest</div><div>{</div>= <div>=C2=A0 =C2=A0 static assert( __traits(compiles, { foo; =C2=A0 =C2=A0 }= ));</div><div>=C2=A0 =C2=A0 static assert(!__traits(compiles, { foo(); =C2= =A0 }));</div> <div>=C2=A0 =C2=A0 static assert(is(typeof(foo) =3D=3D Type));</div><div>= =C2=A0 =C2=A0 static assert(is(typeof(&amp;foo) =3D=3D Type function()));</= div><div><br></div><div>=C2=A0 =C2=A0 static assert( __traits(compiles, { b= ar =3D 1; }));</div><div>=C2=A0 =C2=A0 static assert(!__traits(compiles, { = bar(1); =C2=A0}));</div> <div>=C2=A0 =C2=A0 static assert(is(typeof(bar)) =3D=3D false);</div><div>= =C2=A0 =C2=A0 static assert(is(typeof(&amp;bar) =3D=3D Type function()));</= div><div><br></div><div>=C2=A0 =C2=A0 static assert( __traits(compiles, { b= az; =C2=A0 =C2=A0 =C2=A0 }));</div><div>=C2=A0 =C2=A0 static assert(!__trai= ts(compiles, { baz(); =C2=A0 =C2=A0 }));</div> <div>=C2=A0 =C2=A0 static assert( __traits(compiles, { baz =3D 1; =C2=A0 })= );</div><div>=C2=A0 =C2=A0 static assert(!__traits(compiles, { baz() =3D 1;= }));</div><div>=C2=A0 =C2=A0 static assert(is(typeof(baz) =3D=3D Type));</= div><div>=C2=A0 =C2=A0 static assert(is(typeof(&amp;baz) =3D=3D ref Type fu= nction()));</div> <div>}</div><div><br></div><div> property Type foh(Type);</div><div> proper= ty void bah(Type n, Type m);</div><div> property ref Type bas(Type);</div><= div><br></div><div>Type hoo(Type);</div><div>void var(Type, Type);</div> <div>ref Type vaz(Type);</div><div><br></div><div>unittest</div><div>{</div=
<div>=C2=A0 =C2=A0 static assert( __traits(compiles, { foh =3D 1; }) =C2=

=A0 =C2=A0 static assert(!__traits(compiles, { foh(1); =C2=A0}) =C2=A0 =C2= =A0 &amp;&amp; =C2=A0__traits(compiles, { hoo(1); =C2=A0}));</div> <div>=C2=A0 =C2=A0 static assert(!__traits(compiles, { 1.foh; =C2=A0 }) =C2= =A0 =C2=A0 &amp;&amp; =C2=A0__traits(compiles, { 1.hoo; =C2=A0 }));</div><d= iv>=C2=A0 =C2=A0 static assert(!__traits(compiles, { 1.foh(); }) =C2=A0 =C2= =A0 &amp;&amp; =C2=A0__traits(compiles, { 1.hoo(); }));</div> <div><br></div><div>=C2=A0 =C2=A0 static assert(!__traits(compiles, { bah(1= , 2); }) =C2=A0 &amp;&amp; =C2=A0__traits(compiles, { var(1, 2); }));</div>= <div>=C2=A0 =C2=A0 static assert( __traits(compiles, { 1.bah =3D 2; }) =C2= =A0 &amp;&amp; !__traits(compiles, { 1.var =3D 2; }));</div> <div>=C2=A0 =C2=A0 static assert(!__traits(compiles, { 1.bah(2); =C2=A0}) = =C2=A0 &amp;&amp; =C2=A0__traits(compiles, { 1.var(2); =C2=A0}));</div><div=
<br></div><div>=C2=A0 =C2=A0 static assert( __traits(compiles, { bas =3D 1=

=A0 }));</div> <div>=C2=A0 =C2=A0 static assert(!__traits(compiles, { bas(1); =C2=A0 =C2= =A0 =C2=A0}) &amp;&amp; =C2=A0__traits(compiles, { vaz(1); =C2=A0 =C2=A0 = =C2=A0}));</div><div>=C2=A0 =C2=A0 static assert(!__traits(compiles, { bas(= 1) =3D 2; =C2=A0}) &amp;&amp; =C2=A0__traits(compiles, { vaz(1) =3D 2; =C2= =A0}));</div> <div>=C2=A0 =C2=A0 static assert(!__traits(compiles, { 1.bas; =C2=A0 =C2=A0= =C2=A0 }) &amp;&amp; =C2=A0__traits(compiles, { 1.vaz; =C2=A0 =C2=A0 =C2= =A0 }));</div><div>=C2=A0 =C2=A0 static assert(!__traits(compiles, { 1.bas = =3D 2; =C2=A0 }) &amp;&amp; =C2=A0__traits(compiles, { 1.vaz =3D 2; =C2=A0 = }));</div> <div>=C2=A0 =C2=A0 static assert(!__traits(compiles, { 1.bas(); =C2=A0 =C2= =A0 }) &amp;&amp; =C2=A0__traits(compiles, { 1.vaz(); =C2=A0 =C2=A0 }));</d= iv><div>=C2=A0 =C2=A0 static assert(!__traits(compiles, { 1.bas() =3D 2; })= &amp;&amp; =C2=A0__traits(compiles, { 1.vaz() =3D 2; }));</div> <div>}</div><div><br></div><div style>Is this correct?</div><div style><br>= </div><div style>Kenji Hara</div></div></div></div></div></div> --14dae93405dd1ea01304d4d13dec--
Feb 03 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/3/13 7:37 AM, kenji hara wrote:
 1. When a function is annotated with  property, it cannot be called with
 parenthesis syntax.
 2. 0-arg functions which not annotated with  property can be called
 without parentheses.
 3. Ref return getter can make "auxiliary setter", if formal getter is
 missing.
 4. `typeof(exp)` never returns "function type". In other words, the
 actual type of `exp` and `typeof(exp)` should be same.
 5. Both `&prop` and `&func` should return function pointer / delegate object
 6. UFCS CAN NOT call global setter by getter syntax.

Yah. There is still some inconsistency, but I think there's no way to be 100% consistent. For properties &a.prop is not the same as &(a.prop), which is unlike other expressions.
 I think that 4 to 6 are important points of this DIP. Based on the
 rules, I could write an exhaustive test case.

I'll insert comments inline.
 alias Type = int;

 unittest
 {
      struct S
      {
           property Type foo();       // formal getter
           property void bar(Type);   // formal setter
           property ref Type baz();   // ref return getter == auxiliary
 setter
      }
      S s;
      static assert( __traits(compiles, { s.foo;     }));
      static assert(!__traits(compiles, { s.foo();   }));
      static assert(is(typeof(s.foo) == Type));
      static assert(is(typeof(&s.foo) == Type delegate()));

Yes, great. You may want to also add: static assert(!__traits(compiles, { auto p = &(s.foo); })); because that would apply & to the Type rvalue returned by s.foo.
      static assert( __traits(compiles, { s.bar = 1; }));
      static assert(!__traits(compiles, { s.bar(1);  }));
      static assert(is(typeof(s.bar)) == false);
      static assert(is(typeof(&s.bar) == void delegate(Type)));

Yes. Also: static assert(is(typeof(s.bar = 1) == void));
      static assert( __traits(compiles, { s.baz;     }));
      static assert(!__traits(compiles, { s.baz();   }));
      static assert( __traits(compiles, { s.baz = 1; }));
      static assert(is(typeof(s.baz) == Type));
      static assert(is(typeof(&s.foo) == ref Type delegate()));

Yes, assuming you meant "baz" on the last line, too.
 }
 unittest
 {
      struct S
      {
          Type foo();         // 0-arg function
          void bar(Type n);   // 1-arg function
          ref Type baz();     // 0-arg ref return function
      }
      S s;
      static assert( __traits(compiles, { s.foo;     }));
      static assert( __traits(compiles, { s.foo();   }));
      static assert(is(typeof(s.foo) == Type));
      static assert(is(typeof(&s.foo) == Type delegate()));

Correct. Also add: static assert(!is(typeof(&(s.foo))));
      static assert(!__traits(compiles, { s.bar = 1; }));
      static assert( __traits(compiles, { s.bar(1);  }));
      static assert(is(typeof(s.bar)) == false);
      static assert(is(typeof(&s.bar) == void delegate(Type)));

Correct. Also: static assert(!is(typeof(&(s.bar)))); because the expression s.bar is meaningless. (This is NEW BEHAVIOR.) The basic idea here is to disallow expressions that can't be typed.
      static assert( __traits(compiles, { s.baz;     }));
      static assert( __traits(compiles, { s.baz = 1; }));
      static assert( __traits(compiles, { s.baz();   }));
      static assert(is(typeof(s.baz) == Type));
      static assert(is(typeof(&s.baz) == ref Type delegate()));
 }

Correct. Also: static assert(is(typeof(&(s.baz)) == Type*));
  property Type foo();

I'm not sure we should allow this at module level. (And there is no way to write a corresponding setter.)
  property void bar(Type);
  property ref Type baz();

I think we should disallow this as well.
 unittest
 {
      static assert( __traits(compiles, { foo;     }));
      static assert(!__traits(compiles, { foo();   }));
      static assert(is(typeof(foo) == Type));
      static assert(is(typeof(&foo) == Type function()));

If we disallow top-level global properties neither of these will compile. If we do allow them, then the asserts would pass.
      static assert( __traits(compiles, { bar = 1; }));
      static assert(!__traits(compiles, { bar(1);  }));
      static assert(is(typeof(bar)) == false);
      static assert(is(typeof(&bar) == Type function()));

Nope, all of these are getters for int. The following should compile instead: static assert( __traits(compiles, { 1.bar; })); static assert(!__traits(compiles, { bar(1); })); static assert(is(typeof(bar)) == false); static assert(is(typeof(&bar) == void function(int)));
      static assert( __traits(compiles, { baz;       }));
      static assert(!__traits(compiles, { baz();     }));
      static assert( __traits(compiles, { baz = 1;   }));
      static assert(!__traits(compiles, { baz() = 1; }));
      static assert(is(typeof(baz) == Type));
      static assert(is(typeof(&baz) == ref Type function()));

If we allow top-level properties with 0 parameters, these should inded compile.
 }

  property Type foh(Type);

This is always a getter for Type returning a Type.
  property void bah(Type n, Type m);

This is always a setter having Type on the left-hand side and Type on the right-hand side.
  property ref Type bas(Type);

This is always a getter for Type.
 Type hoo(Type);
 void var(Type, Type);
 ref Type vaz(Type);

 unittest
 {
      static assert( __traits(compiles, { foh = 1; }) &&
 !__traits(compiles, { hoo = 1; }));

No, replace with: static assert( __traits(compiles, { 1.foh; }) && !__traits(compiles, { hoo = 1; }));
      static assert(!__traits(compiles, { foh(1);  }) &&
   __traits(compiles, { hoo(1);  }));

Correct.
      static assert(!__traits(compiles, { 1.foh;   }) &&
   __traits(compiles, { 1.hoo;   }));

Incorrect, foh is a getter for Type so the first should work. static assert(__traits(compiles, { 1.foh; }) && __traits(compiles, { 1.hoo; }));
      static assert(!__traits(compiles, { 1.foh(); }) &&
   __traits(compiles, { 1.hoo(); }));

This is identical to the one above.
      static assert(!__traits(compiles, { bah(1, 2); }) &&
   __traits(compiles, { var(1, 2); }));

Correct.
      static assert( __traits(compiles, { 1.bah = 2; }) &&
 !__traits(compiles, { 1.var = 2; }));

Correct.
      static assert(!__traits(compiles, { 1.bah(2);  }) &&
   __traits(compiles, { 1.var(2);  }));

First expression fails.
      static assert( __traits(compiles, { bas = 1;     }) &&
 !__traits(compiles, { vaz = 1;     }));

Both branches fail.
      static assert(!__traits(compiles, { bas(1);      }) &&
   __traits(compiles, { vaz(1);      }));

Correct.
      static assert(!__traits(compiles, { bas(1) = 2;  }) &&
   __traits(compiles, { vaz(1) = 2;  }));

Correct.
      static assert(!__traits(compiles, { 1.bas;       }) &&
   __traits(compiles, { 1.vaz;       }));

The first branch fails because 1.bas is legit.
      static assert(!__traits(compiles, { 1.bas = 2;   }) &&
   __traits(compiles, { 1.vaz = 2;   }));

First branch fails because 1.bas is legit and yields a ref int. Second branch passes.
      static assert(!__traits(compiles, { 1.bas();     }) &&
   __traits(compiles, { 1.vaz();     }));

Correct.
      static assert(!__traits(compiles, { 1.bas() = 2; }) &&
   __traits(compiles, { 1.vaz() = 2; }));
 }

Correct.
 Is this correct?

As noted above, I might have missed some. I will update the doc with a copy of your unittests. Thanks! Andrei
Feb 03 2013
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/3/13 12:34 PM, Andrei Alexandrescu wrote:
 On 2/3/13 7:37 AM, kenji hara wrote:

Copied your unittests with changes and explanations: http://wiki.dlang.org/DIP23#unittest. Please take a look and let me know of what you think! For now I conservatively disallow top-level properties with 0 parameters. I think we can allow them later if there's a strong need. Top-level properties with 1 argument are always getters. We need a bunch more with unittests that return callable entities. Andrei
Feb 03 2013
prev sibling next sibling parent kenji hara <k.hara.pg gmail.com> writes:
--14dae93405f365d96604d4d148a2
Content-Type: text/plain; charset=UTF-8

2013/2/3 Steven Schveighoffer <schveiguy yahoo.com>

 I have a possible suggestion to fix this within your proposal:

  property on single-arg free functions ONLY enables a setter mode, it does
 not work as a UFCS getter.

[snip]

Kenji Hara --14dae93405f365d96604d4d148a2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">2013/2/3 Steven Schveighoffer <span dir=3D"ltr">&lt;<a hre= f=3D"mailto:schveiguy yahoo.com" target=3D"_blank">schveiguy yahoo.com</a>&= gt;</span><br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockq= uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-wi= dth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-= left:1ex"> <div class=3D"im"><span style=3D"color:rgb(34,34,34)">I have a possible sug= gestion to fix this within your proposal:</span><br></div> <br> property on single-arg free functions ONLY enables a setter mode, it does = not work as a UFCS getter.</blockquote><div>=C2=A0[snip]</div><blockquote c= lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1p= x;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1= ex"> </blockquote><div>=C2=A0</div><div><div>I was thinking the exact same thing= .</div></div><div><br></div><div style>Kenji Hara</div></div></div></div> --14dae93405f365d96604d4d148a2--
Feb 03 2013
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sun, 03 Feb 2013 07:16:17 -0500, Steven Schveighoffer  
<schveiguy yahoo.com> wrote:

 On Sun, 03 Feb 2013 03:16:08 -0500, Andrei Alexandrescu  
 <SeeWebsiteForEmail erdani.org> wrote:

 Walter and I have had a discussion on how to finalize properties.

 http://wiki.dlang.org/DIP23

I agree with everything in this. This looks exactly like what I wanted a few days ago. Thank you! One aspect not addressed is free-function properties:

I thought of one other problem with this proposal. You can no longer get a delegate of a property. Like it or not, there will be existing code that does get a delegate to properties (it is allowed now). I think we should provide a __traits accessor for this. Otherwise, there is no way to port said code to the new style. -Steve
Feb 03 2013
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 02/03/2013 09:16 AM, Andrei Alexandrescu wrote:
 Walter and I have had a discussion on how to finalize properties.

 http://wiki.dlang.org/DIP23
 ...

Looks good. Two things: What about eg: property T front(T)(T[] arr){ return arr[0]; } And: "Avoid embarrassing situations such as expressions with unexpressible types or no-op address-of operator (as is the case with C functions)." The DIP does not fix the first issue. pragma(msg, typeof(*(int x)=>x)); // pure nothrow safe int(int x)
Feb 03 2013
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/3/13 7:59 AM, Timon Gehr wrote:
 On 02/03/2013 09:16 AM, Andrei Alexandrescu wrote:
 Walter and I have had a discussion on how to finalize properties.

 http://wiki.dlang.org/DIP23
 ...

Looks good. Two things: What about eg: property T front(T)(T[] arr){ return arr[0]; }

I updated the doc to clarify that one-parameter properties are ALWAYS getters and two-parameter properties are ALWAYS setters.
 And:

 "Avoid embarrassing situations such as expressions with unexpressible
 types or no-op address-of operator (as is the case with C functions)."

 The DIP does not fix the first issue.

 pragma(msg, typeof(*(int x)=>x)); // pure nothrow  safe int(int x)

I see. I think dereferencing a function or delegate type should never work. Andrei
Feb 03 2013
prev sibling next sibling parent kenji hara <k.hara.pg gmail.com> writes:
--14dae9340cf3cb18f204d4d18f83
Content-Type: text/plain; charset=UTF-8

2013/2/3 Steven Schveighoffer <schveiguy yahoo.com>

 On Sun, 03 Feb 2013 07:16:17 -0500, Steven Schveighoffer <
 schveiguy yahoo.com> wrote:

  On Sun, 03 Feb 2013 03:16:08 -0500, Andrei Alexandrescu <
 SeeWebsiteForEmail erdani.org**> wrote:

  Walter and I have had a discussion on how to finalize properties.
 http://wiki.dlang.org/DIP23

I agree with everything in this. This looks exactly like what I wanted a few days ago. Thank you! One aspect not addressed is free-function properties:

I thought of one other problem with this proposal. You can no longer get a delegate of a property. Like it or not, there will be existing code that does get a delegate to properties (it is allowed now). I think we should provide a __traits accessor for this. Otherwise, there is no way to port said code to the new style.

On the contrary with you, I was read that we no longer get an address of ref returned value by address-op. property ref int foo(); static assert(is(typeof(&foo) == ref int function())); // typeof does not return int* If I am correct, there is no need for special enhancement like __traits. Kenji Hara --14dae9340cf3cb18f204d4d18f83 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">2013/2/3 Steven Schveighoffer <span dir=3D"ltr">&lt;<a hre= f=3D"mailto:schveiguy yahoo.com" target=3D"_blank">schveiguy yahoo.com</a>&= gt;</span><br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockq= uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-wi= dth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-= left:1ex"> <div class=3D"im">On Sun, 03 Feb 2013 07:16:17 -0500, Steven Schveighoffer = &lt;<a href=3D"mailto:schveiguy yahoo.com" target=3D"_blank">schveiguy yaho= o.com</a>&gt; wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= adding-left:1ex"> On Sun, 03 Feb 2013 03:16:08 -0500, Andrei Alexandrescu &lt;<a href=3D"mail= to:SeeWebsiteForEmail erdani.org" target=3D"_blank">SeeWebsiteForEmail erda= ni.org</a><u></u>&gt; wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= adding-left:1ex"> Walter and I have had a discussion on how to finalize properties.<br> <br> <a href=3D"http://wiki.dlang.org/DIP23" target=3D"_blank">http://wiki.dlang= .org/DIP23</a><br> </blockquote> <br> I agree with everything in this. =C2=A0This looks exactly like what I wante= d a few days ago. =C2=A0Thank you!<br> <br> One aspect not addressed is free-function properties:<br> </blockquote> <br></div> I thought of one other problem with this proposal. =C2=A0You can no longer = get a delegate of a property. =C2=A0Like it or not, there will be existing = code that does get a delegate to properties (it is allowed now).<br> <br> I think we should provide a __traits accessor for this. =C2=A0Otherwise, th= ere is no way to port said code to the new style.<br></blockquote><div><br>= </div><div style>On the contrary with you, I was read that we no longer get= an address of ref returned value by address-op.=C2=A0</div> <div style><br></div><div style> property ref int foo();</div><div style>st= atic assert(is(typeof(&amp;foo) =3D=3D ref int function())); =C2=A0// typeo= f does not return int*</div><div style><br></div><div style>If I am correct= , there is no need for special enhancement like __traits.</div> <div style><br></div><div style>Kenji Hara</div></div></div></div> --14dae9340cf3cb18f204d4d18f83--
Feb 03 2013
prev sibling next sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Sunday, 3 February 2013 at 08:16:08 UTC, Andrei Alexandrescu 
wrote:

 We also understand it's impossible to reconcile all viewpoints 
 and please all tastes. Our hope is to get to a point where the 
 rules are self-consistent, meaningful, and complete.

Should we add also non ambiguous ? I think everyone should agree upon your last paragraph.
Feb 03 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Sunday, 3 February 2013 at 12:49:00 UTC, Steven Schveighoffer 
wrote:
 I thought of one other problem with this proposal.  You can no 
 longer get a delegate of a property.  Like it or not, there 
 will be existing code that does get a delegate to properties 
 (it is allowed now).

This isn't a problem.
Feb 03 2013
prev sibling next sibling parent reply FG <home fgda.pl> writes:
On 2013-02-03 09:16, Andrei Alexandrescu wrote:
 Walter and I have had a discussion on how to finalize properties.

Very reasonable in the majority of the proposal. I can't, however, get my head around 2-arg property functions: int a_; property void a(int v, bool rev=false) { a_ = rev ? -v : v; } a = 10; // fine 10.a = true; // this feels backwards, true is just an extra flag The boolean flag is optional and making it the rhs of the assignment suggests it is the value which will be set. On the other hand switching argument positions, resulting in true.a = 10 also feels very strange. I'd say: allow only 0 or 1 argument in properties. If you need more arguments, write a normal function for it.
Feb 03 2013
next sibling parent FG <home fgda.pl> writes:
On 2013-02-03 14:33, kenji hara wrote:
 Two arguments  property function would be declared only in module level,
 and just be called with UFCS.
 I think that functions annotated with  property must not have default
 parameters. As you show, it would introduce not little ambiguity.

With such constraints two argument property functions are fine, as long as it is their second argument that is most significant in the assignment. The DIP's 42.fun = 43 is the ideal counter-example of that. :)
Feb 03 2013
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/3/13 8:16 AM, FG wrote:
 On 2013-02-03 09:16, Andrei Alexandrescu wrote:
 Walter and I have had a discussion on how to finalize properties.

Very reasonable in the majority of the proposal. I can't, however, get my head around 2-arg property functions: int a_; property void a(int v, bool rev=false) { a_ = rev ? -v : v; }

I'd say never allow defaulted arguments with property.
 a = 10; // fine
 10.a = true; // this feels backwards, true is just an extra flag

 The boolean flag is optional and making it the rhs of the assignment
 suggests it is the value which will be set. On the other hand switching
 argument positions, resulting in true.a = 10 also feels very strange.

 I'd say: allow only 0 or 1 argument in properties.
 If you need more arguments, write a normal function for it.

Two-argument properties are always setters. Andrei
Feb 03 2013
prev sibling next sibling parent kenji hara <k.hara.pg gmail.com> writes:
--20cf307cfecc2ef6dc04d4d207ce
Content-Type: text/plain; charset=UTF-8

2013/2/3 FG <home fgda.pl>

 On 2013-02-03 09:16, Andrei Alexandrescu wrote:

 Walter and I have had a discussion on how to finalize properties.

Very reasonable in the majority of the proposal. I can't, however, get my head around 2-arg property functions: int a_; property void a(int v, bool rev=false) { a_ = rev ? -v : v; } a = 10; // fine 10.a = true; // this feels backwards, true is just an extra flag The boolean flag is optional and making it the rhs of the assignment suggests it is the value which will be set. On the other hand switching argument positions, resulting in true.a = 10 also feels very strange. I'd say: allow only 0 or 1 argument in properties. If you need more arguments, write a normal function for it.

Two arguments property function would be declared only in module level, and just be called with UFCS. I think that functions annotated with property must not have default parameters. As you show, it would introduce not little ambiguity. Kenji Hara --20cf307cfecc2ef6dc04d4d207ce Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">2013/2/3 FG <span dir=3D"ltr">&lt;<a href=3D"mailto:home f= gda.pl" target=3D"_blank">home fgda.pl</a>&gt;</span><br><div class=3D"gmai= l_extra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style= =3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(20= 4,204,204);border-left-style:solid;padding-left:1ex"> <div class=3D"im">On 2013-02-03 09:16, Andrei Alexandrescu wrote:<br> </div><div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0= px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);b= order-left-style:solid;padding-left:1ex"> Walter and I have had a discussion on how to finalize properties.<br> </blockquote> <br></div> Very reasonable in the majority of the proposal.<br> I can&#39;t, however, get my head around 2-arg property functions:<br> <br> =C2=A0 =C2=A0 int a_;<br> =C2=A0 =C2=A0 property void a(int v, bool rev=3Dfalse) { a_ =3D rev ? -v := v; }<br> =C2=A0 =C2=A0 a =3D 10; =C2=A0 =C2=A0 =C2=A0 // fine<br> =C2=A0 =C2=A0 10.a =3D true; =C2=A0// this feels backwards, true is just an= extra flag<br> <br> The boolean flag is optional and making it the rhs of the assignment sugges= ts it is the value which will be set. On the other hand switching argument = positions, resulting in true.a =3D 10 also feels very strange.<br> <br> I&#39;d say: allow only 0 or 1 argument in properties.<br> If you need more arguments, write a normal function for it.<br> </blockquote></div><br></div><div class=3D"gmail_extra" style>Two arguments= property function would be declared only in module level, and just be cal= led with UFCS.</div><div class=3D"gmail_extra" style>I think that functions= annotated with=C2=A0 property=C2=A0must not have default parameters. As yo= u show, it would introduce not little ambiguity.</div> <div class=3D"gmail_extra" style><br></div><div class=3D"gmail_extra" style=
Kenji Hara</div></div>

--20cf307cfecc2ef6dc04d4d207ce--
Feb 03 2013
prev sibling next sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Sunday, 3 February 2013 at 14:40:30 UTC, Andrei Alexandrescu 
wrote:
 On 2/3/13 4:11 AM, monarch_dodra wrote:
 On Sunday, 3 February 2013 at 08:16:08 UTC, Andrei 
 Alexandrescu wrote:
 In brief:

 * Optional parens stay.

 Andrei

Will we keep the optional -property (or similar) for those of us that *want* enforced parens, even with UFCS?

No. Thanks for the reminder - I updated the DIP.
 Did a sensible reasons actually ever come up for allowing 
 optional
 parens on non-UFCS?

This is a judgment call as reasonable people may disagree on it. Walter and I both believe optional parens are a good thing for D. At this point, we don't think one more pass through the pros and cons would change our opinion. Andrei

Thank you for the answers. I didn't follow all 500 posts in the other thread, so it was really just to have more vision on the DIP. I don't want to try to change anybody's opinion. Just trying to get a clear status on where we currently stand.
Feb 03 2013
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sun, 03 Feb 2013 08:04:10 -0500, Timon Gehr <timon.gehr gmx.ch> wrote:

 T delegate() f = &a.prop -> auto f = ()=>a.prop;
 T delegate(T) f = &a.prop -> auto f = (T x)=>a.prop=x;

I don't like this solution. You are creating a dummy delegate function, and moving the stack frame into the heap, just so you can get a delegate to an already existing function. -Steve
Feb 03 2013
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sun, 03 Feb 2013 08:00:32 -0500, kenji hara <k.hara.pg gmail.com> wrote:

 2013/2/3 Steven Schveighoffer <schveiguy yahoo.com>

 On Sun, 03 Feb 2013 07:16:17 -0500, Steven Schveighoffer <
 schveiguy yahoo.com> wrote:

  On Sun, 03 Feb 2013 03:16:08 -0500, Andrei Alexandrescu <
 SeeWebsiteForEmail erdani.org**> wrote:

  Walter and I have had a discussion on how to finalize properties.
 http://wiki.dlang.org/DIP23

I agree with everything in this. This looks exactly like what I wanted a few days ago. Thank you! One aspect not addressed is free-function properties:

I thought of one other problem with this proposal. You can no longer get a delegate of a property. Like it or not, there will be existing code that does get a delegate to properties (it is allowed now). I think we should provide a __traits accessor for this. Otherwise, there is no way to port said code to the new style.

On the contrary with you, I was read that we no longer get an address of ref returned value by address-op. property ref int foo(); static assert(is(typeof(&foo) == ref int function())); // typeof does not return int* If I am correct, there is no need for special enhancement like __traits.

You are right, it does not specify this, I was somewhat mistaken. But the spirit of the proposal seems to suggest that for all intents and purposes, a property's type is the type of it's return value. For the most part, taking the address of an rvalue is an error anyway, so it makes sense to make this type of function return a delegate with the & operator. However, in the case of ref returns for properties, I think it may be too limiting if it is impossible to get the address of a ref return: property ref int foo(); int *x = &foo; // error returns delegate? int *y = &foo(); // error, using parens illegal? Somewhat glaring here is that you can't make ref local variables. I suppose in this case, the such a function could have property removed on it, but that is little help to the user of such a function who has no control over the API. A potential workaround could be a la Timon's suggestion: ref int foowrap() { return foo;} int *x = &foowrap(); Let's go with the current proposal, and I will address the __traits mechanism separately. -Steve
Feb 03 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Sunday, 3 February 2013 at 15:04:15 UTC, Steven Schveighoffer 
wrote:
 On Sun, 03 Feb 2013 08:04:10 -0500, Timon Gehr 
 <timon.gehr gmx.ch> wrote:

 T delegate() f = &a.prop -> auto f = ()=>a.prop;
 T delegate(T) f = &a.prop -> auto f = (T x)=>a.prop=x;

I don't like this solution. You are creating a dummy delegate function, and moving the stack frame into the heap, just so you can get a delegate to an already existing function. -Steve

Unless you escape the delegate, it should allocate on the heap. And any inlining compiler should remove the delegate completely anyway.
Feb 03 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Sunday, 3 February 2013 at 15:16:30 UTC, Steven Schveighoffer 
wrote:
 But the spirit of the proposal seems to suggest that for all 
 intents and purposes, a property's type is the type of it's 
 return value.

If you want a function, then just don't annotate with property. The whole point of property is that it doesn't behave like a function.
Feb 03 2013
prev sibling next sibling parent reply "TommiT" <tommitissari hotmail.com> writes:
On Sunday, 3 February 2013 at 08:16:08 UTC, Andrei Alexandrescu 
wrote:
 Walter and I have had a discussion on how to finalize 
 properties.

 http://wiki.dlang.org/DIP23
 [..]

What happens here? struct S { int _n; property ref int prop() { return _n; } } property void prop(ref S s, int n) { s._n = 42; } void main() { S s; s.prop = 10; }
Feb 03 2013
next sibling parent FG <home fgda.pl> writes:
On 2013-02-03 16:35, TommiT wrote:
 What happens here?

 struct S
 {
      int _n;

       property ref int prop()
      {
          return _n;
      }
 }

  property void prop(ref S s, int n)
 {
      s._n = 42;
 }

 void main()
 {
      S s;
      s.prop = 10;
 }

This is an interesting problem. 1) I think setters should outrank getters when there's an assignment. 2) Also actual methods outrank UFCS free functions with same arguments. It's a question which rule has higher precedence. I think no.2 does and then _n becomes 10.
Feb 03 2013
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/3/13 10:35 AM, TommiT wrote:
 On Sunday, 3 February 2013 at 08:16:08 UTC, Andrei Alexandrescu wrote:
 Walter and I have had a discussion on how to finalize properties.

 http://wiki.dlang.org/DIP23
 [..]

What happens here? struct S { int _n; property ref int prop() { return _n; } } property void prop(ref S s, int n) { s._n = 42; } void main() { S s; s.prop = 10; }

The member is chosen. Andrei
Feb 03 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/3/13 1:14 PM, TommiT wrote:
 Example 1:

 struct S
 {
 int _n;

  property ref const(int) prop() const
 {
 return _n;
 }
 }

  property void prop(ref S s, int n)
 {
 s._n = 42;
 }

 void main()
 {
 S s;
 s.prop = 10;
 }

This is a matter of visibility. The presence of a member precludes any UFCS. Won't compile. Same for the 2nd example. Andrei
Feb 03 2013
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/3/13 1:32 PM, TommiT wrote:
 On Sunday, 3 February 2013 at 18:28:06 UTC, Andrei Alexandrescu wrote:
 [..]
 This is a matter of visibility. The presence of a member precludes any
 UFCS. Won't compile. Same for the 2nd example.

Just to be perfectly clear, it must be that this wouldn't compile either, right? struct S { int _n; property int prop() const { return _n; } } property void prop(ref S s, int n) { s._n = 42; } void main() { S s; s.prop = 10; }

Nope. Andrei
Feb 03 2013
prev sibling next sibling parent Johannes Pfau <nospam example.com> writes:
Am Sun, 03 Feb 2013 04:40:44 -0800
schrieb Jonathan M Davis <jmdavisProg gmx.com>:

 On Sunday, February 03, 2013 13:34:14 Jacob Carlborg wrote:
 On 2013-02-03 09:16, Andrei Alexandrescu wrote:
 Walter and I have had a discussion on how to finalize properties.
 
 http://wiki.dlang.org/DIP23

What about: writeln = "asd"; Allowed or not?

I take it that you didn't read the DIP. At the very beginning of its section on "Write properties:" ----------- In order to use the assignment operator "=" property-style, the property annotation MUST be used. -----------

There's a example on the page though which contradicts this: static int x; ref int fun1() { return x; } fun1 = 42;
Feb 03 2013
prev sibling next sibling parent Johannes Pfau <nospam example.com> writes:
Am Sun, 03 Feb 2013 10:37:45 -0500
schrieb Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>:

 On 2/3/13 7:34 AM, Jacob Carlborg wrote:
 On 2013-02-03 09:16, Andrei Alexandrescu wrote:
 Walter and I have had a discussion on how to finalize properties.

 http://wiki.dlang.org/DIP23

What about: writeln = "asd"; Allowed or not?

No because writeln is not a property. For non-properties there's no lowering of assignment. Andrei

Then this should be removed in the proposal: If a function returns a reference, then assignment through the paren-less call should work: unittest { static int x; ref int fun1() { return x; } fun1 = 42; }
Feb 03 2013
prev sibling next sibling parent kenji hara <k.hara.pg gmail.com> writes:
--f46d0442899844de1604d4d4061e
Content-Type: text/plain; charset=UTF-8

2013/2/4 Steven Schveighoffer <schveiguy yahoo.com>

 On Sun, 03 Feb 2013 08:00:32 -0500, kenji hara <k.hara.pg gmail.com>
 wrote:

 On the contrary with you, I was read that we no longer get an address of
 ref returned value by address-op.

  property ref int foo();
 static assert(is(typeof(&foo) == ref int function()));  // typeof does not
 return int*

 If I am correct, there is no need for special enhancement like __traits.

You are right, it does not specify this, I was somewhat mistaken. But the spirit of the proposal seems to suggest that for all intents and purposes, a property's type is the type of it's return value.

It is already satisfied. Inside typeof, all use of property makes its return type. I think the case of getting address of ref value returned from a property is much rare. If you really want to do it, we can write short workaround. A potential workaround could be a la Timon's suggestion:
 ref int foowrap() { return foo;}
 int *x = &foowrap();

One liner version: int* x = ((ref x) => &x)(foo); Let's go with the current proposal, and I will address the __traits
 mechanism separately.

It seems to me that is an overkill. Kenji Hara --f46d0442899844de1604d4d4061e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">2013/2/4 Steven Schveighoffer <span dir=3D"ltr">&lt;<a hre= f=3D"mailto:schveiguy yahoo.com" target=3D"_blank">schveiguy yahoo.com</a>&= gt;</span><br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockq= uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-wi= dth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-= left:1ex"> <div class=3D"im">On Sun, 03 Feb 2013 08:00:32 -0500, kenji hara &lt;<a hre= f=3D"mailto:k.hara.pg gmail.com" target=3D"_blank">k.hara.pg gmail.com</a>&= gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0= px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);borde= r-left-style:solid;padding-left:1ex"> <div class=3D"im"> On the contrary with you, I was read that we no longer get an address of<br=

<br> property ref int foo();<br> static assert(is(typeof(&amp;foo) =3D=3D ref int function())); =C2=A0// typ= eof does not<br> return int*<br> <br> If I am correct, there is no need for special enhancement like __traits.<br=

<br> You are right, it does not specify this, I was somewhat mistaken.<br> <br> But the spirit of the proposal seems to suggest that for all intents and pu= rposes, a property&#39;s type is the type of it&#39;s return value.<br></bl= ockquote><div style>[snip]</div><div style><br></div><div style>It is alrea= dy satisfied. Inside typeof, all use of property makes its return type.</di= v> <div style>I think the case of getting address of ref value returned from a= property is much rare.=C2=A0</div><div>=C2=A0</div><div>If you really want= to do it, we can write short workaround.</div><div style><br></div><blockq= uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-wi= dth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-= left:1ex"> A potential workaround could be a la Timon&#39;s suggestion:<br> <br> ref int foowrap() { return foo;}<br> int *x =3D &amp;foowrap();<br></blockquote><div><br></div><div style>One li= ner version:</div><div>=C2=A0</div><div><div>int* x =3D ((ref x) =3D&gt; &a= mp;x)(foo);</div></div><div><br></div><blockquote class=3D"gmail_quote" sty= le=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(= 204,204,204);border-left-style:solid;padding-left:1ex"> Let&#39;s go with the current proposal, and I will address the __traits mec= hanism separately.<br></blockquote><div><br></div><div style>It seems to me= that is an overkill.</div><div style><br></div><div style>Kenji Hara=C2=A0= </div> </div></div></div> --f46d0442899844de1604d4d4061e--
Feb 03 2013
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sun, 03 Feb 2013 10:31:31 -0500, deadalnix <deadalnix gmail.com> wrote:

 On Sunday, 3 February 2013 at 15:16:30 UTC, Steven Schveighoffer wrote:
 But the spirit of the proposal seems to suggest that for all intents  
 and purposes, a property's type is the type of it's return value.

If you want a function, then just don't annotate with property. The whole point of property is that it doesn't behave like a function.

That is not the point of properties. The point of properties is to have hooks for field setting and getting. They necessarily behave like functions. -Steve
Feb 03 2013
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sun, 03 Feb 2013 10:56:50 -0500, kenji hara <k.hara.pg gmail.com> wrote:

 2013/2/4 Steven Schveighoffer <schveiguy yahoo.com>
 ref int foowrap() { return foo;}
 int *x = &foowrap();

One liner version: int* x = ((ref x) => &x)(foo);

That looks better than mine, it takes a bit to understand it :) It can be written into a global function: T *addressOf(T)(ref T t) {return &t;} I think this should actually work: int *x = foo.addressOf;
 Let's go with the current proposal, and I will address the __traits
 mechanism separately.

It seems to me that is an overkill.

I have other ideas for such a feature, which map into something I've wished for a long time. You will see. -Steve
Feb 03 2013
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sun, 03 Feb 2013 10:35:29 -0500, TommiT <tommitissari hotmail.com>  
wrote:

 On Sunday, 3 February 2013 at 08:16:08 UTC, Andrei Alexandrescu wrote:
 Walter and I have had a discussion on how to finalize properties.

 http://wiki.dlang.org/DIP23
 [..]

What happens here? struct S { int _n; property ref int prop() { return _n; } } property void prop(ref S s, int n) { s._n = 42; } void main() { S s; s.prop = 10; }

I would expect it to call S.prop, not the global prop. If not, that should be a bug (Kenji, you should add this case to the tests if not already there) With UFCS, you cannot override type-specified methods and properties. -Steve
Feb 03 2013
prev sibling next sibling parent "TommiT" <tommitissari hotmail.com> writes:
On Sunday, 3 February 2013 at 16:03:50 UTC, Steven Schveighoffer 
wrote:
 On Sun, 03 Feb 2013 10:31:31 -0500, deadalnix 
 <deadalnix gmail.com> wrote:
 If you want a function, then just don't annotate with 
  property. The whole point of property is that it doesn't 
 behave like a function.

That is not the point of properties. The point of properties is to have hooks for field setting and getting. They necessarily behave like functions. -Steve

That is not the point of properties. The point of setter and getter methods is to have hooks for field setting and getting. The point or properties is to have clearer semantics than what regular setter and getter methods would have.
Feb 03 2013
prev sibling next sibling parent Johannes Pfau <nospam example.com> writes:
Am Sun, 03 Feb 2013 17:01:59 +0100
schrieb "TommiT" <tommitissari hotmail.com>:

 On Sunday, 3 February 2013 at 15:48:00 UTC, Johannes Pfau wrote:
 -----------
 In order to use the assignment operator "=" property-style, the
  property annotation MUST be used.
 -----------

There's a example on the page though which contradicts this: static int x; ref int fun1() { return x; } fun1 = 42;

That example has nothing to do with properties. It's just: static int x; ref int fun1() { return x; } fun1() = 42; ...except that the empty parens were omitted (which is allowed there).

OK, but then 'In order to use the assignment operator "=" property-style, the property annotation MUST be used.' is wrong or a least misleading. IMHO "fun1 = 42;" is using "=" 'property style'. But if you think of it as a parentheses-less call that indeed makes sense.
Feb 03 2013
prev sibling next sibling parent Johannes Pfau <nospam example.com> writes:
Am Sun, 03 Feb 2013 11:11:05 -0500
schrieb Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>:

 On 2/3/13 5:14 AM, Johannes Pfau wrote:
 "If a function returns a reference, then assignment through the
 paren-less call should work: "

 This is the only part where I would disagree. Why is this special
 rule necessary if we have full  property support? I think this
 would still allow too many false positives.

(As a note, this is the current behavior.) The way I see it is this is a natural consequence of optional parens. The name of a function without a "&" prepended or a "()" after it will invoke the function, and that's that.

I didn't think of it as a call without parentheses but it indeed makes sense.
 
 * Is returning ref values from the getter OK?

I see no reason to disallow it at the language level.

You have to consider cases though where you have both a setter and a getter returning a 'ref value'. property ref int value(); property void value(int new); * Is it valid to define both at the same time? * Which one is used for assignment etc?
 * Is taking ref values in the setter OK?

How do you mean that?

property int value(ref int new); IIRC that was just meant to complement the "is returning ref OK". Usually nothing bad can happen. Although the ref parameter could be converted into a pointer with some nasty tricks it's probably not the job of the language to prevent that.
Feb 03 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Sunday, 3 February 2013 at 17:37:03 UTC, Andrei Alexandrescu 
wrote:
 In the proposal &a.b gets the delegate of a property.

:facepalm:
Feb 03 2013
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sun, 03 Feb 2013 12:36:10 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 On 2/3/13 7:40 AM, kenji hara wrote:
 2013/2/3 Steven Schveighoffer <schveiguy yahoo.com
 <mailto:schveiguy yahoo.com>>

     I have a possible suggestion to fix this within your proposal:

      property on single-arg free functions ONLY enables a setter mode,
     it does not work as a UFCS getter.

   [snip]

 I was thinking the exact same thing.

Then we can't make this work: property ref T front(T[] array) { return array[0]; } unittest { auto a = [ 1, 2, 3]; auto b = a.front; }

ref T front(T[] array) { return array[0]; } // same unittest But I also can agree with the idea you currently have to make UFCS properties require a 'this' initial parameter. -Steve
Feb 03 2013
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 2/3/13, Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:
 For properties &a.prop is not the same as &(a.prop),
 which is unlike other expressions.

I have an idea. The DIP says that property cannot return a property function. Therefore we could introduce a new built-in property (pardon the pun) that only property functions have, ala: a.prop.addrOf Similar to how we have .funcPtr for other types. This field would only exist for propery functions and therefore it's never ambiguous on whether it applies to the function or to the function call (it *has* to apply to the function since it cannot return a property. So instead of having behavior based on whether there are any parens involved, you would have: &a.prop; // address of return value &(a.prop) // ditto a.prop.addrOf // address of property function
Feb 03 2013
prev sibling next sibling parent "TommiT" <tommitissari hotmail.com> writes:
On Sunday, 3 February 2013 at 17:46:00 UTC, Andrei Alexandrescu 
wrote:
 On 2/3/13 10:35 AM, TommiT wrote:
 On Sunday, 3 February 2013 at 08:16:08 UTC, Andrei 
 Alexandrescu wrote:
 Walter and I have had a discussion on how to finalize 
 properties.

 http://wiki.dlang.org/DIP23
 [..]

What happens here? struct S { int _n; property ref int prop() { return _n; } } property void prop(ref S s, int n) { s._n = 42; } void main() { S s; s.prop = 10; }

The member is chosen. Andrei

What happens in these examples? Example 1: struct S { int _n; property ref const(int) prop() const { return _n; } } property void prop(ref S s, int n) { s._n = 42; } void main() { S s; s.prop = 10; } -------------------------------------------- Example 2: struct T { int _n; disable void opAssign(T rhs) { } } struct S { T _t; property ref T prop() { return _t; } } property void prop(ref S s, T t) { s._t._n = t._n; } void main() { S s; s.prop = T.init; }
Feb 03 2013
prev sibling next sibling parent "TommiT" <tommitissari hotmail.com> writes:
On Sunday, 3 February 2013 at 18:28:06 UTC, Andrei Alexandrescu 
wrote:
 [..]
 This is a matter of visibility. The presence of a member 
 precludes any UFCS. Won't compile. Same for the 2nd example.

Just to be perfectly clear, it must be that this wouldn't compile either, right? struct S { int _n; property int prop() const { return _n; } } property void prop(ref S s, int n) { s._n = 42; } void main() { S s; s.prop = 10; }
Feb 03 2013
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sun, 03 Feb 2013 12:58:21 -0500, Timon Gehr <timon.gehr gmx.ch> wrote:

 On 02/03/2013 06:47 PM, Steven Schveighoffer wrote:
 On Sun, 03 Feb 2013 12:36:10 -0500, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 On 2/3/13 7:40 AM, kenji hara wrote:
 2013/2/3 Steven Schveighoffer <schveiguy yahoo.com
 <mailto:schveiguy yahoo.com>>

     I have a possible suggestion to fix this within your proposal:

      property on single-arg free functions ONLY enables a setter mode,
     it does not work as a UFCS getter.

   [snip]

 I was thinking the exact same thing.

Then we can't make this work: property ref T front(T[] array) { return array[0]; } unittest { auto a = [ 1, 2, 3]; auto b = a.front; }

ref T front(T[] array) { return array[0]; } // same unittest

different unittest: unittest{ auto a = [()=>2, ()=>3, ()=>4]; assert(a.front()==2); }

OK, so that is not good. I think the current DIP23 idea should be sufficient, no global properties. -Steve
Feb 03 2013
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sun, 03 Feb 2013 13:42:57 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 On 2/3/13 1:32 PM, TommiT wrote:
 On Sunday, 3 February 2013 at 18:28:06 UTC, Andrei Alexandrescu wrote:
 [..]
 This is a matter of visibility. The presence of a member precludes any
 UFCS. Won't compile. Same for the 2nd example.

Just to be perfectly clear, it must be that this wouldn't compile either, right? struct S { int _n; property int prop() const { return _n; } } property void prop(ref S s, int n) { s._n = 42; } void main() { S s; s.prop = 10; }

Nope.

He means "Nope it wouldn't compile" in case that was confusing ;) In general, functions must be overloaded within the same visibility level/scope. If there is one overload at a level, ALL overloads must exist at that level, or they are not seen. -Steve
Feb 03 2013
prev sibling next sibling parent reply "eles" <eles eles.com> writes:
On Sunday, 3 February 2013 at 08:16:08 UTC, Andrei Alexandrescu 
wrote:
 In brief:

 * Optional parens stay.

This syntax sugar only helps in chained-UFCS calling. Why allowing it everywhere, that is even if the function's name is not followed by a dot? like this: Obj1.action1.action2.action3(); It is clearer than Obj1.action1().action2().action3(); and, still, does not allow something like Obj1.action1; requiring an Obj1.action1(); instead.
 * Just mentioning a function or method without parens does NOT 
 automatically take its address. (This is a change from the 
 current behavior.)

If you stick to the above "optional only if followed by a dot"-paradigm, you could maintain the behavior, except in that UFCS-chains, where it doesn't matter anyway what mentioning a function or method without parens returns, since one assumes invocation in this kind of chains.
 * Read properties (using  property) work as expected with the 
 mention that they may NOT be called with the parens. Any parens 
 would apply to the returned value.

And if the returned value is a parameterless function, shouldn't that be callable without parens?
 * Write properties (using  property) may only be used in the 
 assignment form (no function-style call allowed).

Feb 03 2013
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 02/03/2013 11:24 PM, eles wrote:
 On Sunday, 3 February 2013 at 08:16:08 UTC, Andrei Alexandrescu wrote:
 In brief:

 * Optional parens stay.

This syntax sugar only helps in chained-UFCS calling. ...

Nope. a.map!(a=>2*a);
 ...
 * Read properties (using  property) work as expected with the mention
 that they may NOT be called with the parens. Any parens would apply to
 the returned value.

And if the returned value is a parameterless function, shouldn't that be callable without parens? ...

No, it shouldn't. The rewrite is (rightfully) not applicable to expressions of first class function types. The only reason why the implicit calling and property approaches are workable is because the language also supports non first class functions (inherited directly from C).
Feb 03 2013
prev sibling next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 02/03/2013 09:16 AM, Andrei Alexandrescu wrote:
 ...

 * Just mentioning a function or method without parens does NOT
 automatically take its address. (This is a change from the current
 behavior.)

(No, it is not.) From the DIP: "This proposal sustains that optional parentheses should stay in. That means, if a function or method may be called without arguments, the trailing parens may be omitted. [...] The same goes about methods: [...] However, that's not the case with function objects, delegate objects, or objects that implement the function call operator. [...]" Should also mention static opCall. The section does not mention what happens with first class callables that are invoked via UFCS. In particular, the validity of eg. the following code (which currently is valid) is not specified: enum foo = (int x)=>x; static assert(2==2.foo);
Feb 03 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, Feb 03, 2013 at 03:16:08AM -0500, Andrei Alexandrescu wrote:
 Walter and I have had a discussion on how to finalize properties.
 
 http://wiki.dlang.org/DIP23

+1. I think this proposal (1) addresses the most important issues with the current implementation of property, and (2) is probably one of the simplest ways to fix current issues without introducing too many changes and new features. I vote for this. T -- Having a smoking section in a restaurant is like having a peeing section in a swimming pool. -- Edward Burr
Feb 03 2013
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 2/3/13, Andrej Mitrovic <andrej.mitrovich gmail.com> wrote:
 So instead of having behavior based on whether there are any parens
 involved, you would have:

 &a.prop;  // address of return value
 &(a.prop)  // ditto
 a.prop.addrOf  // address of property function

So, thoughts on this?
Feb 03 2013
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/3/13 3:16 AM, Andrei Alexandrescu wrote:
[snip]

Some more thinking got me to three simple principles that guide the 
proposed property design:

http://wiki.dlang.org/DIP23#In_a_nutshell

I think most, if not all, detailed rules derive from these.


Andrei
Feb 03 2013
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, February 03, 2013 20:30:48 Andrei Alexandrescu wrote:
 On 2/3/13 3:16 AM, Andrei Alexandrescu wrote:
 [snip]
 
 Some more thinking got me to three simple principles that guide the
 proposed property design:
 
 http://wiki.dlang.org/DIP23#In_a_nutshell
 
 I think most, if not all, detailed rules derive from these.

Technically, the bit about having exactly one or exactly two parameters is wrong, unless you're counting the invisible this pointer/reference in that. Member property functions end up with exactly zero or exactly one parameters. - Jonathan M Davis
Feb 03 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-02-04 02:56, Jonathan M Davis wrote:

 Technically, the bit about having exactly one or exactly two parameters is
 wrong, unless you're counting the invisible this pointer/reference in that.
 Member property functions end up with exactly zero or exactly one parameters.

I don't know if the text has been update since you read it but it says: "counting the implicit this parameter if at all". -- /Jacob Carlborg
Feb 04 2013
prev sibling next sibling parent reply "David Nadlinger" <see klickverbot.at> writes:
On Monday, 4 February 2013 at 01:30:49 UTC, Andrei Alexandrescu 
wrote:
 I think most, if not all, detailed rules derive from these.

One does not, the strange special case for taking the address of a property. I'd REALLY urge you to explore alternative solutions, such as the one proposed by Andrej, before introducing an abomination like distinguishing between "&a" and "&(a)". There is no way such strange behavior could be explained in a way that is coherent with the rest of the language. I found that when you are working on a complex problem and have a solution that seems to work for everything except a little detail, the best approach often is to step back a bit and have an entirely fresh look at that area again, but now taking the rest of your design as a given. Introducing a rule by which parenthesizing an expression in a way that does not change precedence suddenly causes a difference in behavior certainly wouldn't be among the first ideas coming to my mind this way. David
Feb 03 2013
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 02/04/2013 03:28 AM, deadalnix wrote:
 On Monday, 4 February 2013 at 02:18:08 UTC, David Nadlinger wrote:
 On Monday, 4 February 2013 at 01:30:49 UTC, Andrei Alexandrescu wrote:
 I think most, if not all, detailed rules derive from these.

One does not, the strange special case for taking the address of a property. I'd REALLY urge you to explore alternative solutions, such as the one proposed by Andrej, before introducing an abomination like distinguishing between "&a" and "&(a)". There is no way such strange behavior could be explained in a way that is coherent with the rest of the language. I found that when you are working on a complex problem and have a solution that seems to work for everything except a little detail, the best approach often is to step back a bit and have an entirely fresh look at that area again, but now taking the rest of your design as a given.

The problem we are dealing with here isn't complex. It is made complex artificially.

It is not even made complex. It is quite obvious how things should work. (and &a vs &(a) is not it.)
 We are trying to make  properties behave like fields,

(Syntactically.)
 but hey in this  case I want it to behave like a function . . .

This is the step that must be reconsidered.
 oh yeah so in this
 special case, I have to workaround, ho and here and here as well, oh
 damn, that is complicated.

 Same goes when conflating the function with it's return value (which
 optional () is about).

Certainly not! & is the syntactic element distinguishing functions from return values, not (). Optional & would be about conflating the function with its return value. (Scala basically does this, but instead of prefix & they use suffix _.)
 Introducing a rule by which parenthesizing an expression in a way that
 does not change precedence suddenly causes a difference in behavior
 certainly wouldn't be among the first ideas coming to my mind this way.

By trying to make things easy, we miss that the important point is to make them simple.

Most of this stuff is simple enough. Have you implemented optional parens already?
Feb 03 2013
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/3/13 9:17 PM, David Nadlinger wrote:
 On Monday, 4 February 2013 at 01:30:49 UTC, Andrei Alexandrescu wrote:
 I think most, if not all, detailed rules derive from these.

One does not, the strange special case for taking the address of a property. I'd REALLY urge you to explore alternative solutions, such as the one proposed by Andrej, before introducing an abomination like distinguishing between "&a" and "&(a)".

Andrej's proposal is nice, but I think you're wrong about this. We're already there - &a.b means something (a delegate) which is not decomposable into smaller parts.
 There is no way such strange behavior could be explained in a way that
 is coherent with the rest of the language.

I disagree.
 I found that when you are working on a complex problem and have a
 solution that seems to work for everything except a little detail, the
 best approach often is to step back a bit and have an entirely fresh
 look at that area again, but now taking the rest of your design as a given.

I agree with the general thought.
 Introducing a rule by which parenthesizing an expression in a way that
 does not change precedence suddenly causes a difference in behavior
 certainly wouldn't be among the first ideas coming to my mind this way.

I really think you are wrong about this. Parenthesizing has nothing to do with this. &a.b is punctuation that creates an indivizible unit. Andrei
Feb 03 2013
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/3/13 11:00 PM, David Nadlinger wrote:
 The problem I see is that usually, one can insert grouping pairs of
 parentheses into an expression according to the operator
 precedence/associativity rules at will without changing the result. This
 isn't merely a theoretical exercise, but the way (well, in the form of
 trees) I tend to reason about source code intuitively.

Well this is going to sound bad, but you either use reason or intuition. I don't see how one can reason intuitively.
 Now, grouping the expression »&a.b« according to the precedence rules
 yields »&(a.b)« – but in your proposal, they mean completely different
 things.

I agree they mean different things. I'm unclear that's a problem. All your examples stop here, there's no propagation of the issue. To take the address of a property, one writes &obj.prop. To take the address of a property's result, one writes &(obj.prop). And that's that. It all works with typeof.
 You could argue that &<expression>.<identifier> is a special construct
 different from the normal address-of operator. But where do you mentally
 draw the line? What about &a.b.c <-> &(a.b).c <-> &((a.b).c)? &(a + b).c
 <-> &((a + b).c)?

That argument is easily destroyed. In a.b.c, a.b is the expression and c is the property name.
 Again, from an user's perspective the change in behavior seems to be
 completely at odds with the usual rule in C-family languages that
 grouping parens can be added without changing the meaning of an
 expression.

I think we avoid much more bizarre things that way, such that expr and &expr meaning sometimes the same exact thing. Or that we have expressions without a type. And nobody blinks an eye. I just think we're better off.
 Thus, this part of the proposed syntax strikes me as being
 extremely misleading, which is especially bad because the situation with
 the two possible meanings is confusing enough to start out with already.
 And how often do you think you'll find yourself in the situation of
 needing to get a delegate from a property anyway? Can't we just make
 » property getter expressions are always equivalent to their return
 value« a hard (simple!) rule and add something like
 __traits(propertyGetter, ...) for the rare cases where you really need
 to get hold of the underlying function?

I don't see where the trouble is. If I thought the trait is necessary, I'd make it part of the proposal. Currently I don't see it as necessary, but I definitely can be convinced. Andrei
Feb 03 2013
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/4/13 2:10 AM, monarch_dodra wrote:
 It was my understanding that once a function is declared a property, it
 is meant to emulate a field. In such circumstance, there were talks
 about plain and simply not allowing taking the address of an  property
 function.

 2 questions:

 1. Was this proposal rejected, or have we just forgotten about it?

Well I at least haven't forgotten. Generally in D we don't want to 100% disallow doing something sensible.
 2. What are the actual use cases for taking the address of a property
 function?

 Unless I'm mistaken, the "entire mess" of &a.b would be solved if we
 simply recognized it as "but you aren't allowed to take the address of
 the function b, so why have a syntax to support it anyways"? In such
 circumstance, "&a.b" == "&(a.b)" == "the address of the thing obtaining
 by running a.b"

Yes, if we disallowed address taking things would get a bit simpler. Andrei
Feb 04 2013
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/4/13 11:01 AM, Steven Schveighoffer wrote:
  property int foo();

 auto x = &foo; // error
 int delegate() x = &foo; // ok

That's an interesting idea. I'm a bit weary about it though. At least for properties I'm inclined toward starting real tight with address-of disabled and relax the rules later. Andrei
Feb 04 2013
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/4/13 12:53 AM, kenji hara wrote:
 If the expression is generated from string mixin, might have a problem.

 // This is much simple case. Real example might be more complicated.
 template AddressOf(string exp)
 {
      enum AddressOf = "&" ~ exp;
 }
 struct S {
       property int prop() { return 1; }
 }
 void main() {
      S s;
      assert(s.prop == 1);
      int* p = mixin(AddressOf!("s.prop"));  // &s.prop returns delegate
 }

 I think that parenthesis-dependent syntax is not good.

 Kenji Hara

Couldn't AddressOf use "&(" + exp + ")"? I thought more about this. The problem remains even without property, due to optional parens in function invocation. Consider: ref int fun() { ... } auto p1 = &fun; auto p2 = &(fun); auto p3 = &(fun()); What are the types of the three? The optional parens in invocation require some disambiguation. I think the sensible disambiguation is to have &fun take the address of fun and the other two take the address of fun's result. I would agree restricting the properties, but requiring a __trait to take the address of a regular function or method seems overkill. Andrei
Feb 04 2013
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 02/04/2013 03:05 PM, Andrei Alexandrescu wrote:
 ...
 Couldn't AddressOf use "&(" + exp + ")"?

 I thought more about this. The problem remains even without  property,
 due to optional parens in function invocation. Consider:

 ref int fun() { ... }
 auto p1 = &fun;
 auto p2 = &(fun);
 auto p3 = &(fun());

 What are the types of the three? The optional parens in invocation
 require some disambiguation.

The obvious rule is not to give significance to redundant parentheses.
 I think the sensible disambiguation is to
 have &fun take the address of fun and the other two take the address of
 fun's result.

No! &fun and &(fun) are the same thing. Functions that get their address taken are not implicitly invoked. (Again, Scala agrees.) The rules are straightforward: A non- property function name 'foo' denotes a function invocation without arguments iff it does not occur in one of the following contexts: 1. foo(...) // explicitly called 2. &foo // address taken 3. ...!(...,foo,...) // template argument (well, that's what DMD currently does) 4. alias ... = foo; // aliased
 I would agree restricting the properties, but requiring a __trait to
 take the address of a regular function or method seems overkill.

I have no idea how the conclusion would be reached that this is necessary under any of the discussed schemes.
Feb 04 2013
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 02/04/2013 04:02 PM, deadalnix wrote:
 On Monday, 4 February 2013 at 14:25:10 UTC, Timon Gehr wrote:
 On 02/04/2013 03:05 PM, Andrei Alexandrescu wrote:
 ...
 Couldn't AddressOf use "&(" + exp + ")"?

 I thought more about this. The problem remains even without  property,
 due to optional parens in function invocation. Consider:

 ref int fun() { ... }
 auto p1 = &fun;
 auto p2 = &(fun);
 auto p3 = &(fun());

 What are the types of the three? The optional parens in invocation
 require some disambiguation.

The obvious rule is not to give significance to redundant parentheses.
 I think the sensible disambiguation is to
 have &fun take the address of fun and the other two take the address of
 fun's result.

No! &fun and &(fun) are the same thing. Functions that get their address taken are not implicitly invoked. (Again, Scala agrees.)

Scala don't really agree. fun is the function pointer. It is evaluated if the function pointer is a NOOP, but that's it.

Of course Scala agrees. scala> def foo() = 2 foo: ()Int scala> foo res0: Int = 2 scala> foo _ res1: () => Int = <function0> scala> (foo) _ res2: () => Int = <function0> scala> def bar[A](arg : A) = arg bar: [A](arg: A)A scala> bar(foo) res3: Int = 2
 Here is scala semantic
 with D syntax :

 void bar() {}
 bar; // execute bar. Is an exception because taking the function pointer
 is a NOOP.

No, it is the rule.
 void foo(void function() bar) {}
 foo(bar); // OK, bar is not evaluated.

This is the exception. (That nobody has argued in favour of so far.)
Feb 04 2013
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/4/13 9:25 AM, Timon Gehr wrote:
 On 02/04/2013 03:05 PM, Andrei Alexandrescu wrote:
 I think the sensible disambiguation is to
 have &fun take the address of fun and the other two take the address of
 fun's result.

No! &fun and &(fun) are the same thing. Functions that get their address taken are not implicitly invoked. (Again, Scala agrees.) The rules are straightforward: A non- property function name 'foo' denotes a function invocation without arguments iff it does not occur in one of the following contexts: 1. foo(...) // explicitly called 2. &foo // address taken 3. ...!(...,foo,...) // template argument (well, that's what DMD currently does) 4. alias ... = foo; // aliased

The problem with (3) is that it creates a rule that gives different meaning of expressions inside &(...) and outside it. Consider: &foo -> fine, takes the address of foo &(foo) -> parens don't matter, sweet, still takes the address of foo &( condition ? foo : bar ) -> hum, I guess takes the address of foo or bar &( { auto a = foo; ... return c ? foo : bar; }() ) -> what??? So this is essentially a rule that makes the same give expression have a meaning inside &( ... ) and a different meaning outside. In &expr.name and &(expr.name), that's it - expr may be arbitrarily complicated, but the construct must always end with a method name. In &name and &(name), it's even simpler - it's just punctuation. Andrei
Feb 04 2013
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 02/04/2013 03:38 PM, kenji hara wrote:
 2013/2/4 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org
 <mailto:SeeWebsiteForEmail erdani.org>>


     Couldn't AddressOf use "&(" + exp + ")"?


 Yes. It's enough. I wanted to explain that "we should treat
 address-expression carefully".

     I thought more about this. The problem remains even without
      property, due to optional parens in function invocation. Consider:

     ref int fun() { ... }
     auto p1 = &fun;
     auto p2 = &(fun);
     auto p3 = &(fun());

     What are the types of the three? The optional parens in invocation
     require some disambiguation. I think the sensible disambiguation is
     to have &fun take the address of fun and the other two take the
     address of fun's result.


 Agreed.

Why?
     I would agree restricting the properties, but requiring a __trait to
     take the address of a regular function or method seems overkill.


 Fully agreed.

It is not an interesting point. It is not necessary anyway.
 Although it looks strange and unstable, adding new distinction of
 semantics between &foo and &(foo) has no ambiguity.

It _is_ strange.
 I think this is necessary feature for the D's function and property
 semantics.

Why?
Feb 04 2013
next sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
04-Feb-2013 19:15, Andrej Mitrovic пишет:
 On 2/4/13, kenji hara <k.hara.pg gmail.com> wrote:
 This is not correct."m.s & m.s" is always parsed as binary bitwise AND
expression.
 So there is no address expression.

Fantastic, more special casing. I don't think you guys realize what a mess you would introduce. Basically: s & s; // fine, they're binary operators &s; // oops, doesn't work even if property returns a type with a unary operator

Unary & is not overloadable, precisely due to confusing mess it can create (see C++). -- Dmitry Olshansky
Feb 04 2013
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 02/04/2013 04:08 PM, kenji hara wrote:
 2013/2/4 Timon Gehr <timon.gehr gmx.ch <mailto:timon.gehr gmx.ch>>

     On 02/04/2013 03:38 PM, kenji hara wrote:

         I think this is necessary feature for the D's function and property
         semantics.


     Why?


 Because, "property" is one of D-specific feature.

 In D, "property" is directly translated to function call. So, we should
 get balance between two requirements:
 1. property should be treated as its returned type.
 2. property should be distinguished from raw field. (For example,
 serialization library should recognize it)

This is what __traits are for.
 Address expression is _only_one_ built-in feature to make a callable
 object from function symbol.

Property symbols are not to be treated like function symbols syntactically. That is the point. Otherwise we may as well get rid of properties.
 So this "special feature" is enough reasonable to me.

 ...

"special features" are usually not reasonable.
Feb 04 2013
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/4/2013 6:05 AM, Andrei Alexandrescu wrote:
 Couldn't AddressOf use "&(" + exp + ")"?

 I thought more about this. The problem remains even without  property, due to
 optional parens in function invocation. Consider:

 ref int fun() { ... }
 auto p1 = &fun;
 auto p2 = &(fun);
 auto p3 = &(fun());

 What are the types of the three? The optional parens in invocation require some
 disambiguation. I think the sensible disambiguation is to have &fun take the
 address of fun and the other two take the address of fun's result.

The only time it is valid to take the address of a function's return value is if the function returns a ref. But I also would think that it's a suspicious practice to take the address of a ref. We've disallowed it in other circumstances, why allow it here? If a function intends for someone to take the address of the return ref, shouldn't the function return a pointer instead? If taking the address of a ref is disallowed, then the above problem goes away. &fun, in all its variants, takes the address of the function.
Feb 04 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/5/13 11:44 AM, Steven Schveighoffer wrote:
 On Mon, 04 Feb 2013 18:18:16 -0500, Walter Bright
 <newshound2 digitalmars.com> wrote:

 On 2/4/2013 6:05 AM, Andrei Alexandrescu wrote:
 Couldn't AddressOf use "&(" + exp + ")"?

 I thought more about this. The problem remains even without
  property, due to
 optional parens in function invocation. Consider:

 ref int fun() { ... }
 auto p1 = &fun;
 auto p2 = &(fun);
 auto p3 = &(fun());

 What are the types of the three? The optional parens in invocation
 require some
 disambiguation. I think the sensible disambiguation is to have &fun
 take the
 address of fun and the other two take the address of fun's result.

The only time it is valid to take the address of a function's return value is if the function returns a ref. But I also would think that it's a suspicious practice to take the address of a ref. We've disallowed it in other circumstances, why allow it here? If a function intends for someone to take the address of the return ref, shouldn't the function return a pointer instead?

I'd agree with you if we could have ref variables. In some cases, taking the address is the ONLY option.

Walter and I reviewed the discussion and had a long talk. We are very seriously considering banning the use of & against a ref result from a function (and actually ref parameters and even struct members in safe code). One would still be able to take the address of a field in a class because that's assumed to live on the GC heap. To get the address of an object in system code without resorting to operator& at all, we're considering adding a stdlib function implemented like this (there are several other ways, this is just for illustration): system T* addressOf(T)(ref T obj) { static T* id(T* p) { return p; } auto idr = cast(T* function(ref T)) id; return idr(obj); } I have a DIP in the making that makes "ref" entirely sealed, i.e. it makes it impossible to have a dangling ref in safe code. If that DIP gets approved, then DIP23 gets considerably simplified because operator& won't be applicable to the result of a function anymore. Andrei
Feb 05 2013
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/5/13 2:05 PM, Steven Schveighoffer wrote:
 On Tue, 05 Feb 2013 13:33:35 -0500, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 Walter and I reviewed the discussion and had a long talk. We are very
 seriously considering banning the use of & against a ref result from a
 function (and actually ref parameters and even struct members in  safe
 code). One would still be able to take the address of a field in a
 class because that's assumed to live on the GC heap.

What about structs that live on the heap? e.g. a struct element of an array, or a struct member of a class instance.

In that case we'll disallow it conservatively.
 I think the point about  safe code is moot, aren't pointers disallowed
 in safe code anyway?

Yah, time to start enforcing it more seriously. But we want to ban some uses of & in all code.
 To get the address of an object in  system code without resorting to
 operator& at all, we're considering adding a stdlib function
 implemented like this (there are several other ways, this is just for
 illustration):

  system T* addressOf(T)(ref T obj)
 {
 static T* id(T* p) { return p; }
 auto idr = cast(T* function(ref T)) id;
 return idr(obj);
 }

I think a cast would be sufficient: cast(int *)(&refparam); // understood that a cast is required To jump through this machinery to turn a reference into a, um... reference, seems like a huge waste of code space and resources.

The whole point was to avoid using operator &. Andrei
Feb 05 2013
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/5/13 4:45 PM, Steven Schveighoffer wrote:
 On Tue, 05 Feb 2013 15:15:05 -0500, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 On 2/5/13 2:05 PM, Steven Schveighoffer wrote:
 I think a cast would be sufficient:

 cast(int *)(&refparam); // understood that a cast is required

 To jump through this machinery to turn a reference into a, um...
 reference, seems like a huge waste of code space and resources.

The whole point was to avoid using operator &.

The mechanism to avoid it seems overly extravagant (and prone to low performance). If you want actually avoid using operator &, then make a compiler special function or something.

As I said, there are various solutions. I wrote one that's reasonably portable.
 Also, the use of & can still be hidden inside a function.

My point was to not need & such that the function itself can be compiled. Overall I think this is not the focal issue, the consequences are. Andrei
Feb 05 2013
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 02/05/2013 09:15 PM, Andrei Alexandrescu wrote:
 ...
 The whole point was to avoid using operator &.
 ...

Well, that is completely unnecessary.
Feb 05 2013
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/5/13 2:11 PM, H. S. Teoh wrote:
 On Tue, Feb 05, 2013 at 02:05:24PM -0500, Steven Schveighoffer wrote:
 On Tue, 05 Feb 2013 13:33:35 -0500, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org>  wrote:

 Walter and I reviewed the discussion and had a long talk. We are
 very seriously considering banning the use of&  against a ref
 result from a function (and actually ref parameters and even
 struct members in  safe code). One would still be able to take the
 address of a field in a class because that's assumed to live on
 the GC heap.

What about structs that live on the heap? e.g. a struct element of an array, or a struct member of a class instance. I think the point about safe code is moot, aren't pointers disallowed in safe code anyway?

AFAIK, pointers are allowed in safe code as long as no type casts or pointer arithmetic are performed.

Yah, apparently that's not sufficient. We must make sure pointers don't escape. Andrei
Feb 05 2013
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/5/13 2:21 PM, Steven Schveighoffer wrote:
 On Tue, 05 Feb 2013 13:33:35 -0500, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 Walter and I reviewed the discussion and had a long talk. We are very
 seriously considering banning the use of & against a ref result from a
 function (and actually ref parameters and even struct members in  safe
 code). One would still be able to take the address of a field in a
 class because that's assumed to live on the GC heap.

Back to the problem I stated, how does one do this: ref A foo(); ref A bar(); A *a; if(condition) a = &foo(); else a = &bar(); // use a for a few lines I can see a possible solution but it's not pretty: void processA(ref A a) { // lines that deal with a here } if(condition) processA(foo()); else processA(bar()); But this kind of seems hacky. Why should I have to declare a function just to keep a persistent reference to a return value for the scope of my function? Not only is is awkward, there is a performance hit in that I have to call another function.

You define the function in situ. We understand some valid code will be disallowed by the change,
 Note also that this doesn't fix memory issues:

 struct S
 {
 ref S self() {return this;}
 }

 ref S bad()
 {
 S s;
 return s.self();
 }

 Which I believe would be valid still with your rules.

Also consider the simpler: ref int id(ref int x) { return x; } ref int id1(ref int x) { return id(x); } ref int id2(ref int x) { return id1(x); } ref int oops(int x) { return id2(x); } DIP24 addresses that and other similar cases at their core. Andrei
Feb 05 2013
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 02/05/2013 09:21 PM, Andrei Alexandrescu wrote:
  ...
  Also consider the simpler:

 ref int id(ref int x) { return x; }
 ref int id1(ref int x) { return id(x); }
 ref int id2(ref int x) { return id1(x); }
 ref int oops(int x) { return id2(x); }

 DIP24 addresses that and other similar cases at their core.
 ...

Given a noticeable tendency of your latest design proposals, I guess it does so by disallowing the 'ref' keyword in the lexer stage. :o)
Feb 05 2013
parent reply <address_is invalid.invalid> writes:
Timon Gehr <timon.gehr gmx.ch> wrote:
 On 02/05/2013 09:21 PM, Andrei Alexandrescu wrote:
  ...
  Also consider the simpler:
 
 ref int id(ref int x) { return x; }
 ref int id1(ref int x) { return id(x); }
 ref int id2(ref int x) { return id1(x); }
 ref int oops(int x) { return id2(x); }
 
 DIP24 addresses that and other similar cases at their core.
 ...

Given a noticeable tendency of your latest design proposals, I guess it does so by disallowing the 'ref' keyword in the lexer stage. :o)

What is the noticeable tendency of my latest design proposals? Andrei
Feb 05 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdan.org> writes:
<address_is invalid.invalid> wrote:
 Timon Gehr <timon.gehr gmx.ch> wrote:
 On 02/05/2013 09:21 PM, Andrei Alexandrescu wrote:
  ...
  Also consider the simpler:
 
 ref int id(ref int x) { return x; }
 ref int id1(ref int x) { return id(x); }
 ref int id2(ref int x) { return id1(x); }
 ref int oops(int x) { return id2(x); }
 
 DIP24 addresses that and other similar cases at their core.
 ...

Given a noticeable tendency of your latest design proposals, I guess it does so by disallowing the 'ref' keyword in the lexer stage. :o)

What is the noticeable tendency of my latest design proposals? Andrei

That was me on the misconfigured phone. Andrei
Feb 05 2013
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 02/05/2013 11:58 PM, Andrei Alexandrescu wrote:
 <address_is invalid.invalid> wrote:
 Timon Gehr <timon.gehr gmx.ch> wrote:
 On 02/05/2013 09:21 PM, Andrei Alexandrescu wrote:
   ...
   Also consider the simpler:

 ref int id(ref int x) { return x; }
 ref int id1(ref int x) { return id(x); }
 ref int id2(ref int x) { return id1(x); }
 ref int oops(int x) { return id2(x); }

 DIP24 addresses that and other similar cases at their core.
 ...

Given a noticeable tendency of your latest design proposals, I guess it does so by disallowing the 'ref' keyword in the lexer stage. :o)

What is the noticeable tendency of my latest design proposals? Andrei


They were mostly about banning stuff.
Feb 05 2013
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/5/13 2:25 PM, Steven Schveighoffer wrote:
 On Tue, 05 Feb 2013 13:33:35 -0500, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 Walter and I reviewed the discussion and had a long talk. We are very
 seriously considering banning the use of & against a ref result from a
 function (and actually ref parameters and even struct members in  safe
 code). One would still be able to take the address of a field in a
 class because that's assumed to live on the GC heap.

Thinking about this some more, would this be allowed: trusted T *getAddr(T)(ref T obj) { return &obj; } // allowed? You said only safe code would disallow address of ref parameters

We hope to be able to disallow it. Andrei
Feb 05 2013
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/5/13 2:44 PM, Zach the Mystic wrote:
 On Tuesday, 5 February 2013 at 18:33:36 UTC, Andrei Alexandrescu wrote:
 I have a DIP in the making that makes "ref" entirely sealed, i.e. it
 makes it impossible to have a dangling ref in safe code. If that DIP
 gets approved, then DIP23 gets considerably simplified because
 operator& won't be applicable to the result of a function anymore.


 Andrei

I hope it at least considers my proposal with regard to 'out' return values. 'out' implies ref and guarantees that the result is as good as global: out int foo(ref int a) { return a; } // Error, 'out' return may not return ref parameter out int goo(ref int a) { return new int; } // Fine My impression was that this would solve 98% of problems, the other 2% requiring scope parameters, which also imply ref: ref int haa(ref int a, scope int b) { return b; } // Error, may not return scope parameter ref int gaa(ref int a, scope int b) { return a; } // Fine

I'm sorry, I didn't know of that proposal. Generally we're aiming for economy of means i.e. we want to clarify semantics of existing syntax instead of adding new syntax and semantics. Andrei
Feb 05 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/5/13 4:35 PM, Zach the Mystic wrote:
 On Tuesday, 5 February 2013 at 20:24:16 UTC, Andrei Alexandrescu wrote:
 I hope it at least considers my proposal with regard to 'out' return
 values. 'out' implies ref and guarantees that the result is as good as
 global:

 out int foo(ref int a) { return a; } // Error, 'out' return may not
 return ref parameter
 out int goo(ref int a) { return new int; } // Fine

 My impression was that this would solve 98% of problems, the other 2%
 requiring scope parameters, which also imply ref:

 ref int haa(ref int a, scope int b) { return b; } // Error, may not
 return scope parameter
 ref int gaa(ref int a, scope int b) { return a; } // Fine

I'm sorry, I didn't know of that proposal. Generally we're aiming for economy of means i.e. we want to clarify semantics of existing syntax instead of adding new syntax and semantics. Andrei

It's not a new syntax, just new semantics. Also, the reason for adding these semantics to the function signature was so that the compiler would never have to leave the function in order to compile it. It's a natural complement to ref returns' scope being the most local of the ref parameters, which you suggested in your proposal. It keeps that too.

Just to make sure: this is about http://forum.dlang.org/thread/ririagrqecshjljcdubd forum.dlang.org. Language design is a subjective topic. With time I have learned it's best to not comment very much about it. I have created dozens, maybe hundreds of tidbits of language design and invariably I believe they had obvious merits and negligible drawbacks. The confidence in the quality of my own language designs has decayed exponentially over the years. I'm telling this to put in perspective my following comment. I think it's awesome that work like yours is discussed and refined in this group. At the same time my opinion is that the design is not appropriate for us. It changes semantics of existing code and fosters a cross-talk between subcomponents that has not been time tested. It is complicated in implementation for a benefit that's not properly motivated. At the top level it solves the wrong problem. As stated: "The challenge is to do better, both in terms of functionality and in terms of syntax, than his proposal: ..." The actual challenge is to make properties work with maximum backward compatibility, minimal surprise, best integration with the rest of the language, and maximum of benefits. Andrei
Feb 05 2013
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/5/13 7:15 PM, Zach the Mystic wrote:
 Okay. But I just want to be clear that you are saying what I am reading,
 which is that I came to this language too late to really make a
 difference in it.

Depends on how you look at it. Among languages of any note, I suspect D is one of the more open to language design discussions. Also, there is plenty of fun to be had with library enhancements, proving properties of language constructs, tightening the screws all around, writing articles, tutorials, and documentation, and more. We're just at the beginning of a vast expansion. If by making a difference you mean strictly adding a language feature to D, you're not late even for that but you have to come up with something pretty darn interesting. Your proposal is not that; it does hold water, it is likely implementable, and it is possibly useful (though I have some doubts about the latter). It's just not compelling enough to make the A list, and we can't afford anything but the A+ list. Note that most people tend to vastly overestimate their few first language designs, and that there are much more people who think are good at language design than those actually are. (Note I'm only passing opinion on what I saw; You may as well be an awesome language designer, but the spark is not visible in this particular proposal.) Though I've had an idea or two that stuck, I confess without any false modesty that I don't consider myself to be a noted language designer. Andrei
Feb 05 2013
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/5/13 3:08 PM, TommiT wrote:
 On Tuesday, 5 February 2013 at 18:33:36 UTC, Andrei Alexandrescu wrote:
 [..]
 Walter and I reviewed the discussion and had a long talk. We are very
 seriously considering banning the use of & against a ref result from a
 function (and actually ref parameters and even struct members in  safe
 code). [..]

Did you consider using Rust's idea of 'Named lifetimes' in order to make ref parameters memory-safe. I haven't given much thought to it, but since Rust's borrowed pointers are effectively isomorphic to D's ref variables, it should work. Here's a Rust borrowed pointer tutorial: http://static.rust-lang.org/doc/tutorial-borrowed-ptr.html

Thanks, I'll give that a read. We're very careful at this point about spending much "complexity budget" (as a friend calls it) on new features. Andrei
Feb 05 2013
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday, February 05, 2013 14:05:24 Steven Schveighoffer wrote:
 I think the point about  safe code is moot, aren't pointers disallowed in
 safe code anyway?

Goodness no. It's pointer arithmetic which is disallowed. Pointers themselves are perfectly safe as long as you just pass them around or dereference them (which would include calling functions on them). For instance, the result of in on an AA is a pointer to the object, and that's safe. - Jonathan M Davis
Feb 05 2013
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 05 Feb 2013 16:43:39 -0500, Jonathan M Davis <jmdavisProg gmx.com>  
wrote:

 On Tuesday, February 05, 2013 14:05:24 Steven Schveighoffer wrote:
 I think the point about  safe code is moot, aren't pointers disallowed  
 in
 safe code anyway?

Goodness no. It's pointer arithmetic which is disallowed. Pointers themselves are perfectly safe as long as you just pass them around or dereference them (which would include calling functions on them). For instance, the result of in on an AA is a pointer to the object, and that's safe.

Well, it would seem setting all kinds of extra rules on ref (in addition to the restrictions we have now), when pointers are more useful even in safe code, will simply result in people using pointers more than ref. I'm not sure that's the right message, but I'm afraid that will be what it is. For example, I have to use pointers for my linked list implementation in dcollections, because ref is forbidden to be used as a class or struct member (my nodes are structs because classes are too heavy). Also, ref is not rebindable, whereas a pointer is. -Steve
Feb 05 2013
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/3/13 11:17 PM, BLM768 wrote:
 On Monday, 4 February 2013 at 04:00:28 UTC, David Nadlinger wrote:
 On Monday, 4 February 2013 at 03:15:51 UTC, David Nadlinger wrote:

 And how often do you think you'll find yourself in the situation of
 needing to get a delegate from a property anyway? Can't we just make
 » property getter expressions are always equivalent to their return
 value« a hard (simple!) rule and add something like
 __traits(propertyGetter, ...) for the rare cases where you really need
 to get hold of the underlying function?

 David

I like this solution; it follows the Principle of Least Surprise quite well. The syntax may be a bit longer, but it's immediately obvious even to a beginning/intermediate D user what's going on without having to worry about too many nuances.

This is a good point, and __traits make all possible syntactic confusion go away. Andrei
Feb 03 2013
prev sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Feb 05, 2013 at 02:05:24PM -0500, Steven Schveighoffer wrote:
 On Tue, 05 Feb 2013 13:33:35 -0500, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 
Walter and I reviewed the discussion and had a long talk. We are
very seriously considering banning the use of & against a ref
result from a function (and actually ref parameters and even
struct members in  safe code). One would still be able to take the
address of a field in a class because that's assumed to live on
the GC heap.

What about structs that live on the heap? e.g. a struct element of an array, or a struct member of a class instance. I think the point about safe code is moot, aren't pointers disallowed in safe code anyway?

AFAIK, pointers are allowed in safe code as long as no type casts or pointer arithmetic are performed. T -- There is no gravity. The earth sucks.
Feb 05 2013
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/3/13 9:58 PM, David Nadlinger wrote:
 My point is precisely that. I think there are much simpler solutions
 than adding some magic properties to a pair of parentheses in the right
 position, even if it might look like a convenient hack.

I don't think it's a hack at all. Think it over, and compare it with the language semantics even today. Andrei
Feb 03 2013
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 02/04/2013 05:21 AM, deadalnix wrote:
 On Monday, 4 February 2013 at 03:13:07 UTC, Andrei Alexandrescu wrote:
 On 2/3/13 9:58 PM, David Nadlinger wrote:
 My point is precisely that. I think there are much simpler solutions
 than adding some magic properties to a pair of parentheses in the right
 position, even if it might look like a convenient hack.

I don't think it's a hack at all. Think it over, and compare it with the language semantics even today.

Going from complete crap to bearable don't make bearable good.

In what way is this bearable?
Feb 04 2013
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 02/04/2013 04:13 AM, Andrei Alexandrescu wrote:
 On 2/3/13 9:58 PM, David Nadlinger wrote:
 My point is precisely that. I think there are much simpler solutions
 than adding some magic properties to a pair of parentheses in the right
 position, even if it might look like a convenient hack.

I don't think it's a hack at all.

It is a horrible hack. Why is this not obvious?
 Think it over, and compare it with the language semantics even today.

I am intimately familiar with today's language semantics as I am writing a D compiler front end. Please be more explicit.
Feb 04 2013
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/4/13 9:34 AM, Timon Gehr wrote:
 On 02/04/2013 04:13 AM, Andrei Alexandrescu wrote:
 On 2/3/13 9:58 PM, David Nadlinger wrote:
 My point is precisely that. I think there are much simpler solutions
 than adding some magic properties to a pair of parentheses in the right
 position, even if it might look like a convenient hack.

I don't think it's a hack at all.

It is a horrible hack. Why is this not obvious?

I think it's because it's a matter in which reasonable people may disagree. Andrei
Feb 04 2013
prev sibling next sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Monday, 4 February 2013 at 02:18:08 UTC, David Nadlinger wrote:
 On Monday, 4 February 2013 at 01:30:49 UTC, Andrei Alexandrescu 
 wrote:
 I think most, if not all, detailed rules derive from these.

One does not, the strange special case for taking the address of a property. I'd REALLY urge you to explore alternative solutions, such as the one proposed by Andrej, before introducing an abomination like distinguishing between "&a" and "&(a)". There is no way su<ch strange behavior could be explained in a way that is coherent with the rest of the language.

As another data point, Walter wrote a while ago himself: »I'm just arguing against the e and (e) solution as (perhaps) causing more ambiguity problems«. David
Feb 03 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Monday, 4 February 2013 at 02:18:08 UTC, David Nadlinger wrote:
 On Monday, 4 February 2013 at 01:30:49 UTC, Andrei Alexandrescu 
 wrote:
 I think most, if not all, detailed rules derive from these.

One does not, the strange special case for taking the address of a property. I'd REALLY urge you to explore alternative solutions, such as the one proposed by Andrej, before introducing an abomination like distinguishing between "&a" and "&(a)". There is no way such strange behavior could be explained in a way that is coherent with the rest of the language. I found that when you are working on a complex problem and have a solution that seems to work for everything except a little detail, the best approach often is to step back a bit and have an entirely fresh look at that area again, but now taking the rest of your design as a given.

The problem we are dealing with here isn't complex. It is made complex artificially. We are trying to make properties behave like fields, but hey in this case I want it to behave like a function . . . oh yeah so in this special case, I have to workaround, ho and here and here as well, oh damn, that is complicated. Same goes when conflating the function with it's return value (which optional () is about).
 Introducing a rule by which parenthesizing an expression in a 
 way that does not change precedence suddenly causes a 
 difference in behavior certainly wouldn't be among the first 
 ideas coming to my mind this way.

By trying to make things easy, we miss that the important point is to make them simple.
Feb 03 2013
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 02/04/2013 03:23 AM, kenji hara wrote:
 2013/2/4 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org
 <mailto:SeeWebsiteForEmail erdani.org>>

     On 2/3/13 3:16 AM, Andrei Alexandrescu wrote:
     [snip]

     Some more thinking got me to three simple principles that guide the
     proposed property design:

     http://wiki.dlang.org/DIP23#__In_a_nutshell
     <http://wiki.dlang.org/DIP23#In_a_nutshell>


  > 2. A  property may have EXACTLY ONE or EXACTLY TWO parameters,
 counting the implicit this parameter if at all. The ONE-parameter
 version is ALWAYS a getter, and the TWO-parameter version is ALWAYS a
 setter. There's no variadics, defaulted parameters, and such.

 Unfortunately, I can present a counterexample.

 struct S {
      static int value;
      static  property int foo() { return value; }
      static  property void foo(int n) { value = n; }

 }
 void main() {
      int n = S.foo;
      S.foo = 1;
 }

 Should they be disallowed, as like module level properties?

 Kenji Hara

Probably. (static essentially means module-level, but in a potentially nested name space.)
Feb 03 2013
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 02/04/2013 04:24 AM, TommiT wrote:
 On Monday, 4 February 2013 at 02:36:41 UTC, Timon Gehr wrote:
 On 02/04/2013 03:23 AM, kenji hara wrote:
 Unfortunately, I can present a counterexample.

 struct S {
     static int value;
     static  property int foo() { return value; }
     static  property void foo(int n) { value = n; }

 }
 void main() {
     int n = S.foo;
     S.foo = 1;
 }

 Should they be disallowed, as like module level properties?

 Kenji Hara

Probably. (static essentially means module-level, but in a potentially nested name space.)

I disagree.

Well, it is what the proposal says.
 Static properties can be allowed because they're not
 ambiguous. The problem with module-level:
  property void foo(int n) {}
 ...are the two interpretations of foo as either a setter taking an int
 or a getter property of int type. So, one of those interpretations must
 be disallowed. But, with static member properties, there aren't multiple
 interpretations.

You are right.
Feb 04 2013
prev sibling next sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Monday, 4 February 2013 at 02:28:39 UTC, deadalnix wrote:
 On Monday, 4 February 2013 at 02:18:08 UTC, David Nadlinger 
 wrote:
 On Monday, 4 February 2013 at 01:30:49 UTC, Andrei 
 Alexandrescu wrote:
 I think most, if not all, detailed rules derive from these.

One does not, the strange special case for taking the address of a property. I'd REALLY urge you to explore alternative solutions, such as the one proposed by Andrej, before introducing an abomination like distinguishing between "&a" and "&(a)". There is no way such strange behavior could be explained in a way that is coherent with the rest of the language. I found that when you are working on a complex problem and have a solution that seems to work for everything except a little detail, the best approach often is to step back a bit and have an entirely fresh look at that area again, but now taking the rest of your design as a given.

The problem we are dealing with here isn't complex. It is made complex artificially. We are trying to make properties behave like fields, but hey in this case I want it to behave like a function . . . oh yeah so in this special case, I have to workaround, ho and here and here as well, oh damn, that is complicated. Same goes when conflating the function with it's return value (which optional () is about).

Not sure I'm following – you are arguing that the whole endeavor is futile as long as we keep parens-less function calls? I actually think that DIP23 is a big step in the right direction, given that parens-less function calls are *very* unlikely to go away. Contrary to some of the previous proposals, it's actually a principled approach, like Adam and others (including me) have asked for. Now it's just a matter of getting the details right.
 Introducing a rule by which parenthesizing an expression in a 
 way that does not change precedence suddenly causes a 
 difference in behavior certainly wouldn't be among the first 
 ideas coming to my mind this way.

By trying to make things easy, we miss that the important point is to make them simple.

My point is precisely that. I think there are much simpler solutions than adding some magic properties to a pair of parentheses in the right position, even if it might look like a convenient hack. David
Feb 03 2013
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/3/13 9:23 PM, kenji hara wrote:
 2013/2/4 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org
 <mailto:SeeWebsiteForEmail erdani.org>>

     On 2/3/13 3:16 AM, Andrei Alexandrescu wrote:
     [snip]

     Some more thinking got me to three simple principles that guide the
     proposed property design:

     http://wiki.dlang.org/DIP23#__In_a_nutshell
     <http://wiki.dlang.org/DIP23#In_a_nutshell>


  > 2. A  property may have EXACTLY ONE or EXACTLY TWO parameters,
 counting the implicit this parameter if at all. The ONE-parameter
 version is ALWAYS a getter, and the TWO-parameter version is ALWAYS a
 setter. There's no variadics, defaulted parameters, and such.

 Unfortunately, I can present a counterexample.

 struct S {
      static int value;
      static  property int foo() { return value; }
      static  property void foo(int n) { value = n; }

 }
 void main() {
      int n = S.foo;
      S.foo = 1;
 }

 Should they be disallowed, as like module level properties?

Yes. No static properties. Andrei
Feb 03 2013
prev sibling next sibling parent reply "David Nadlinger" <see klickverbot.at> writes:
On Monday, 4 February 2013 at 03:11:25 UTC, Andrei Alexandrescu 
wrote:
 There is no way such strange behavior could be explained in a 
 way that
 is coherent with the rest of the language.

I disagree.

Then I'm eager to hear your explanation. Parentheses in an expression usually change precedence. Here they do something entirely different.
 Introducing a rule by which parenthesizing an expression in a 
 way that
 does not change precedence suddenly causes a difference in 
 behavior
 certainly wouldn't be among the first ideas coming to my mind 
 this way.

I really think you are wrong about this. Parenthesizing has nothing to do with this. &a.b is punctuation that creates an indivizible unit.

a.b already is an indivisible unit, the result of the function call. David
Feb 03 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/3/13 11:31 PM, Jonathan M Davis wrote:
 I tend to agree that making the parens change the nature of the expression is
 a bad idea.

I think there's some misunderstanding here. Parens change the nature of expressions ALL the time. There is a weird rule in C++11 that makes sometimes typeof(expr) and typeof((expr)) mean different things. That is arguably an example to avoid. But introducing parens among parts of an expression is expected to affect meaning. Andrei
Feb 03 2013
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 02/04/2013 06:36 AM, Andrei Alexandrescu wrote:
 On 2/3/13 11:31 PM, Jonathan M Davis wrote:
 I tend to agree that making the parens change the nature of the
 expression is a bad idea.

I think there's some misunderstanding here.

Agreed.
 Parens change the nature of expressions ALL the time.

In D? No way. Precedence rules are introduced in order to make parens _implicit_. In a language with unary & and binary ., There are two possible interpretations for &a.b: (&a).b &(a.b) In the case of D, &a.b is just a shortcut for &(a.b). How can they denote different things?
 There is a weird rule in C++11 that makes sometimes typeof(expr) and
 typeof((expr)) mean different things.

There is also the argument-dependent name lookup thing namespace bar{ struct S{} baz; S foo(S x){ return x; } } int main(){ foo(bar::baz); // Koenig lookup finds bar::foo (foo)(bar::baz); // no Koenig lookup, foo undefined } Not examples to follow.
 That is arguably an example to
 avoid. But introducing parens among parts of an expression is expected
 to affect meaning.

Sure, but that is not what happens here at all. The parens are introduced around ONE part of the expression.
Feb 04 2013
prev sibling next sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Monday, 4 February 2013 at 03:13:07 UTC, Andrei Alexandrescu 
wrote:
 On 2/3/13 9:58 PM, David Nadlinger wrote:
 My point is precisely that. I think there are much simpler 
 solutions
 than adding some magic properties to a pair of parentheses in 
 the right
 position, even if it might look like a convenient hack.

I don't think it's a hack at all. Think it over, […]

I've done that. What about *you* thinking it over? :P
 and compare it with the language semantics even today.

I thought we agreed that today's semantics are hopelessly broken. Actually, we might already have some of the &a vs. &(a) stuff, I remember Kenji opening a pull request about that at some point, but don't know if it went in OTOH. David
Feb 03 2013
prev sibling next sibling parent "TommiT" <tommitissari hotmail.com> writes:
On Monday, 4 February 2013 at 02:36:41 UTC, Timon Gehr wrote:
 On 02/04/2013 03:23 AM, kenji hara wrote:
 Unfortunately, I can present a counterexample.

 struct S {
     static int value;
     static  property int foo() { return value; }
     static  property void foo(int n) { value = n; }

 }
 void main() {
     int n = S.foo;
     S.foo = 1;
 }

 Should they be disallowed, as like module level properties?

 Kenji Hara

Probably. (static essentially means module-level, but in a potentially nested name space.)

I disagree. Static properties can be allowed because they're not ambiguous. The problem with module-level: property void foo(int n) {} ...are the two interpretations of foo as either a setter taking an int or a getter property of int type. So, one of those interpretations must be disallowed. But, with static member properties, there aren't multiple interpretations.
Feb 03 2013
prev sibling next sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Monday, 4 February 2013 at 03:15:51 UTC, David Nadlinger wrote:
 On Monday, 4 February 2013 at 03:11:25 UTC, Andrei Alexandrescu 
 wrote:
 I really think you are wrong about this. Parenthesizing has 
 nothing to do with this. &a.b is punctuation that creates an 
 indivizible unit.

a.b already is an indivisible unit, the result of the function call.

Actually, let me illustrate this point a bit further, sorry for the hasty reply. The problem I see is that usually, one can insert grouping pairs of parentheses into an expression according to the operator precedence/associativity rules at will without changing the result. This isn't merely a theoretical exercise, but the way (well, in the form of trees) I tend to reason about source code intuitively. Now, grouping the expression »&a.b« according to the precedence rules yields »&(a.b)« – but in your proposal, they mean completely different things. You could argue that &<expression>.<identifier> is a special construct different from the normal address-of operator. But where do you mentally draw the line? What about &a.b.c <-> &(a.b).c <-> &((a.b).c)? &(a + b).c <-> &((a + b).c)? Again, from an user's perspective the change in behavior seems to be completely at odds with the usual rule in C-family languages that grouping parens can be added without changing the meaning of an expression. Thus, this part of the proposed syntax strikes me as being extremely misleading, which is especially bad because the situation with the two possible meanings is confusing enough to start out with already. And how often do you think you'll find yourself in the situation of needing to get a delegate from a property anyway? Can't we just make » property getter expressions are always equivalent to their return value« a hard (simple!) rule and add something like __traits(propertyGetter, ...) for the rare cases where you really need to get hold of the underlying function? David
Feb 03 2013
prev sibling next sibling parent "BLM768" <blm768 gmail.com> writes:
On Monday, 4 February 2013 at 04:00:28 UTC, David Nadlinger wrote:
 On Monday, 4 February 2013 at 03:15:51 UTC, David Nadlinger 
 wrote:

 And how often do you think you'll find yourself in the 
 situation of needing to get a delegate from a property anyway? 
 Can't we just make » property getter expressions are always 
 equivalent to their return value« a hard (simple!) rule and add 
 something like __traits(propertyGetter, ...) for the rare cases 
 where you really need to get hold of the underlying function?

 David

I like this solution; it follows the Principle of Least Surprise quite well. The syntax may be a bit longer, but it's immediately obvious even to a beginning/intermediate D user what's going on without having to worry about too many nuances.
Feb 03 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Monday, 4 February 2013 at 02:58:55 UTC, David Nadlinger wrote:
 Not sure I'm following – you are arguing that the whole 
 endeavor is futile as long as we keep parens-less function 
 calls?

 I actually think that DIP23 is a big step in the right 
 direction, given that parens-less function calls are *very* 
 unlikely to go away. Contrary to some of the previous 
 proposals, it's actually a principled approach, like Adam and 
 others (including me) have asked for. Now it's just a matter of 
 getting the details right.

My point is that we try to pack fundamentally different concept into one. Which is doomed to produce a three headed monster.
 My point is precisely that. I think there are much simpler 
 solutions than adding some magic properties to a pair of 
 parentheses in the right position, even if it might look like a 
 convenient hack.

Convenient hack is not good design.
Feb 03 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Monday, 4 February 2013 at 03:13:07 UTC, Andrei Alexandrescu 
wrote:
 On 2/3/13 9:58 PM, David Nadlinger wrote:
 My point is precisely that. I think there are much simpler 
 solutions
 than adding some magic properties to a pair of parentheses in 
 the right
 position, even if it might look like a convenient hack.

I don't think it's a hack at all. Think it over, and compare it with the language semantics even today.

Going from complete crap to bearable don't make bearable good.
Feb 03 2013
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sun, 03 Feb 2013 22:06:27 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 On 2/3/13 9:23 PM, kenji hara wrote:
 2013/2/4 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org
 <mailto:SeeWebsiteForEmail erdani.org>>

     On 2/3/13 3:16 AM, Andrei Alexandrescu wrote:
     [snip]

     Some more thinking got me to three simple principles that guide the
     proposed property design:

     http://wiki.dlang.org/DIP23#__In_a_nutshell
     <http://wiki.dlang.org/DIP23#In_a_nutshell>


  > 2. A  property may have EXACTLY ONE or EXACTLY TWO parameters,
 counting the implicit this parameter if at all. The ONE-parameter
 version is ALWAYS a getter, and the TWO-parameter version is ALWAYS a
 setter. There's no variadics, defaulted parameters, and such.

 Unfortunately, I can present a counterexample.

 struct S {
      static int value;
      static  property int foo() { return value; }
      static  property void foo(int n) { value = n; }

 }
 void main() {
      int n = S.foo;
      S.foo = 1;
 }

 Should they be disallowed, as like module level properties?

Yes. No static properties.

Hm... can't see the reason why. Static properties play no part in UFCS (which is what makes global properties confusing). I hope it's not because you like your new nutshell rules too much... Then again, properties are for syntax, easy enough to make functions instead. -Steve
Feb 03 2013
prev sibling next sibling parent kenji hara <k.hara.pg gmail.com> writes:
--f46d043c07d4ffd09e04d4dfb495
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

2013/2/4 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>

 On 2/3/13 11:00 PM, David Nadlinger wrote:

  Now, grouping the expression =C2=BB&a.b=C2=AB according to the preceden=


 yields =C2=BB&(a.b)=C2=AB =E2=80=93 but in your proposal, they mean comp=


 things.

I agree they mean different things. I'm unclear that's a problem. All you=

 examples stop here, there's no propagation of the issue. To take the
 address of a property, one writes &obj.prop. To take the address of a
 property's result, one writes &(obj.prop). And that's that. It all works
 with typeof.

If the expression is generated from string mixin, might have a problem. // This is much simple case. Real example might be more complicated. template AddressOf(string exp) { enum AddressOf =3D "&" ~ exp; } struct S { property int prop() { return 1; } } void main() { S s; assert(s.prop =3D=3D 1); int* p =3D mixin(AddressOf!("s.prop")); // &s.prop returns delegate } I think that parenthesis-dependent syntax is not good. Kenji Hara --f46d043c07d4ffd09e04d4dfb495 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">2013= /2/4 Andrei Alexandrescu <span dir=3D"ltr">&lt;<a href=3D"mailto:SeeWebsite= ForEmail erdani.org" target=3D"_blank">SeeWebsiteForEmail erdani.org</a>&gt= ;</span><br> <blockquote class=3D"gmail_quote" style=3D"margin-top:0px;margin-right:0px;= margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color= :rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=3D"i= m"> On 2/3/13 11:00 PM, David Nadlinger wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin-top:0px;margin-right:0px;= margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color= :rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br></blockquot= e> </div><div class=3D"im"> <blockquote class=3D"gmail_quote" style=3D"margin-top:0px;margin-right:0px;= margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color= :rgb(204,204,204);border-left-style:solid;padding-left:1ex"> Now, grouping the expression =C2=BB&amp;a.b=C2=AB according to the preceden= ce rules<br> yields =C2=BB&amp;(a.b)=C2=AB =E2=80=93 but in your proposal, they mean com= pletely different<br> things.<br> </blockquote> <br></div> I agree they mean different things. I&#39;m unclear that&#39;s a problem. A= ll your examples stop here, there&#39;s no propagation of the issue. To tak= e the address of a property, one writes &amp;obj.prop. To take the address = of a property&#39;s result, one writes &amp;(obj.prop). And that&#39;s that= . It all works with typeof.</blockquote> <div><br></div><div>If the expression is generated from string mixin, might= have a problem.</div><div><br></div><div>// This is much simple case. Real= example might be more complicated.</div><div>template AddressOf(string exp= )</div> <div>{</div><div>=C2=A0 =C2=A0 enum AddressOf =3D &quot;&amp;&quot; ~ exp;<= /div><div>}</div><div>struct S {</div><div>=C2=A0 =C2=A0 property int prop= () { return 1; }</div><div>}</div><div>void main() {</div><div>=C2=A0 =C2= =A0 S s;</div><div>=C2=A0 =C2=A0 assert(s.prop =3D=3D 1);</div> <div>=C2=A0 =C2=A0 int* p =3D mixin(AddressOf!(&quot;s.prop&quot;)); =C2=A0= // &amp;s.prop returns delegate</div><div>}</div><div><br></div><div>I thin= k that parenthesis-dependent syntax is not good.</div><div><br></div><div>K= enji Hara</div> </div></div></div> --f46d043c07d4ffd09e04d4dfb495--
Feb 03 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Monday, 4 February 2013 at 05:32:39 UTC, Andrei Alexandrescu
wrote:
 On 2/3/13 11:00 PM, David Nadlinger wrote:
 The problem I see is that usually, one can insert grouping 
 pairs of
 parentheses into an expression according to the operator
 precedence/associativity rules at will without changing the 
 result. This
 isn't merely a theoretical exercise, but the way (well, in the 
 form of
 trees) I tend to reason about source code intuitively.

Well this is going to sound bad, but you either use reason or intuition. I don't see how one can reason intuitively.

Yes, that is why, ideally, you want to close the gap as much as possible.
Feb 03 2013
prev sibling next sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Monday, 4 February 2013 at 05:32:39 UTC, Andrei Alexandrescu 
wrote:
 On 2/3/13 11:00 PM, David Nadlinger wrote:
 The problem I see is that usually, one can insert grouping 
 pairs of
 parentheses into an expression according to the operator
 precedence/associativity rules at will without changing the 
 result. This
 isn't merely a theoretical exercise, but the way (well, in the 
 form of
 trees) I tend to reason about source code intuitively.

Well this is going to sound bad, but you either use reason or intuition. I don't see how one can reason intuitively.
 Now, grouping the expression »&a.b« according to the 
 precedence rules
 yields »&(a.b)« – but in your proposal, they mean completely 
 different
 things.

I agree they mean different things. I'm unclear that's a problem. All your examples stop here, there's no propagation of the issue. To take the address of a property, one writes &obj.prop. To take the address of a property's result, one writes &(obj.prop). And that's that. It all works with typeof. [SNIP] Andrei

It was my understanding that once a function is declared a property, it is meant to emulate a field. In such circumstance, there were talks about plain and simply not allowing taking the address of an property function. 2 questions: 1. Was this proposal rejected, or have we just forgotten about it? 2. What are the actual use cases for taking the address of a property function? Unless I'm mistaken, the "entire mess" of &a.b would be solved if we simply recognized it as "but you aren't allowed to take the address of the function b, so why have a syntax to support it anyways"? In such circumstance, "&a.b" == "&(a.b)" == "the address of the thing obtaining by running a.b"
Feb 03 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Monday, 4 February 2013 at 13:12:54 UTC, Timon Gehr wrote:
 On 02/04/2013 05:21 AM, deadalnix wrote:
 On Monday, 4 February 2013 at 03:13:07 UTC, Andrei 
 Alexandrescu wrote:
 On 2/3/13 9:58 PM, David Nadlinger wrote:
 My point is precisely that. I think there are much simpler 
 solutions
 than adding some magic properties to a pair of parentheses 
 in the right
 position, even if it might look like a convenient hack.

I don't think it's a hack at all. Think it over, and compare it with the language semantics even today.

Going from complete crap to bearable don't make bearable good.

In what way is this bearable?

The proposal is a big improvement over current behavior. Still it has major flaws, like the way & and property interact.
Feb 04 2013
prev sibling next sibling parent kenji hara <k.hara.pg gmail.com> writes:
--f46d044306b0a10b3c04d4e70a7f
Content-Type: text/plain; charset=UTF-8

2013/2/4 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>

 Couldn't AddressOf use "&(" + exp + ")"?

Yes. It's enough. I wanted to explain that "we should treat address-expression carefully".
 I thought more about this. The problem remains even without  property, due
 to optional parens in function invocation. Consider:

 ref int fun() { ... }
 auto p1 = &fun;
 auto p2 = &(fun);
 auto p3 = &(fun());

 What are the types of the three? The optional parens in invocation require
 some disambiguation. I think the sensible disambiguation is to have &fun
 take the address of fun and the other two take the address of fun's result.

Agreed.
 I would agree restricting the properties, but requiring a __trait to take
 the address of a regular function or method seems overkill.

Fully agreed. Although it looks strange and unstable, adding new distinction of semantics between &foo and &(foo) has no ambiguity. I think this is necessary feature for the D's function and property semantics. Kenji Hara --f46d044306b0a10b3c04d4e70a7f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">2013/2/4 Andrei Alexandrescu <span dir=3D"ltr">&lt;<a href= =3D"mailto:SeeWebsiteForEmail erdani.org" target=3D"_blank">SeeWebsiteForEm= ail erdani.org</a>&gt;</span><br><div class=3D"gmail_extra"><div class=3D"g= mail_quote"> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= adding-left:1ex"><div class=3D"im"><br></div> Couldn&#39;t AddressOf use &quot;&amp;(&quot; + exp + &quot;)&quot;?<br></b= lockquote><div><br></div><div>Yes. It&#39;s enough. I wanted to explain tha= t &quot;we should treat address-expression carefully&quot;.</div><div> =C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0= px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-le= ft-style:solid;padding-left:1ex"> I thought more about this. The problem remains even without property, due = to optional parens in function invocation. Consider:<br> <br> ref int fun() { ... }<br> auto p1 =3D &amp;fun;<br> auto p2 =3D &amp;(fun);<br> auto p3 =3D &amp;(fun());<br> <br> What are the types of the three? The optional parens in invocation require = some disambiguation. I think the sensible disambiguation is to have &amp;fu= n take the address of fun and the other two take the address of fun&#39;s r= esult.<br> </blockquote><div><br></div><div style>Agreed.</div><div style>=C2=A0</div>= <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= adding-left:1ex"> I would agree restricting the properties, but requiring a __trait to take t= he address of a regular function or method seems overkill.</blockquote><div=
<br></div><div style>Fully agreed.</div><div style><br></div><div style>

between &amp;foo and &amp;(foo) has no ambiguity.</div><div style><br></di= v><div style>I think this is necessary feature for the D&#39;s function and= property semantics.</div> <div style><br></div><div style>Kenji Hara</div></div></div></div> --f46d044306b0a10b3c04d4e70a7f--
Feb 04 2013
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 2/4/13, Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:
 I'm unclear that's a problem.

The problem is you cannot replace a field with a property function without breaking user-code when you take into account operator overloading. Consider: struct S { S opBinary(string op : "&", S)(S s) { return this; } } struct M { S s; } void main() { M m; auto s = m.s & m.s; // ok } Suppose you want to turn 's' into a read-only property, so you write: struct S { S opBinary(string op : "&", S)(S s) { return this; } } struct M { property S s() { return _s; } private S _s; } void main() { M m; auto s = m.s & m.s; // fail } Now the user-code fails. I really don't understand the benefit of semantics based on whether there are parens involved. It's especially odd when we're arguing that functions can be called with or without parens (no semantic difference), yet getting an address depends on any parens involved. Requiring an address of a property function should be rare, therefore we shouldn't have to introduce special syntax rules for such a rare action. I'd argue we should introduce a trait or an .addrOf property.
Feb 04 2013
prev sibling next sibling parent kenji hara <k.hara.pg gmail.com> writes:
--089e01493bd08d13f104d4e74dd8
Content-Type: text/plain; charset=UTF-8

2013/2/4 Andrej Mitrovic <andrej.mitrovich gmail.com>

 On 2/4/13, Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:
 I'm unclear that's a problem.

The problem is you cannot replace a field with a property function without breaking user-code when you take into account operator overloading. Consider:

As an essential question, how often occurs rewriting fields to property? As far as I thought, such rewriting will cause: 1. compile error by type mismatch (if you use &obj.field), 2. or, success of compilation *without any semantic breaking* (if you don't use &obj.field). I think the result is not so harmful.
 struct S
 {
     S opBinary(string op : "&", S)(S s)
     {
         return this;
     }
 }

 struct M
 {
     S s;
 }

 void main()
 {
     M m;
     auto s = m.s & m.s;  // ok
 }

 Suppose you want to turn 's' into a read-only property, so you write:

 struct S
 {
     S opBinary(string op : "&", S)(S s)
     {
         return this;
     }
 }

 struct M
 {
      property S s() { return _s; }
     private S _s;
 }

 void main()
 {
     M m;
     auto s = m.s & m.s;  // fail
 }

 Now the user-code fails.

This is not correct."m.s & m.s" is always parsed as binary bitwise AND expression. So there is no address expression. Kenji Hara --089e01493bd08d13f104d4e74dd8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">2013/2/4 Andrej Mitrovic <span dir=3D"ltr">&lt;<a href=3D"= mailto:andrej.mitrovich gmail.com" target=3D"_blank">andrej.mitrovich gmail= .com</a>&gt;</span><br><div class=3D"gmail_extra"><div class=3D"gmail_quote= "><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde= r-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid= ;padding-left:1ex"> <div class=3D"im">On 2/4/13, Andrei Alexandrescu &lt;<a href=3D"mailto:SeeW= ebsiteForEmail erdani.org">SeeWebsiteForEmail erdani.org</a>&gt; wrote:<br> &gt; I&#39;m unclear that&#39;s a problem.<br> <br> </div>The problem is you cannot replace a field with a property function<b= r> without breaking user-code when you take into account operator<br> overloading. Consider:<br></blockquote><div><br></div><div style>As an esse= ntial question, how often occurs rewriting fields to property?</div><div st= yle><br></div><div style>As far as I thought, such rewriting will cause:</d= iv> <div style>1. compile error by type mismatch (if you use &amp;obj.field),</= div><div style>2. or, success of compilation *without any semantic breaking= *=C2=A0(if you don&#39;t use &amp;obj.field).</div><div style><br></div><di= v style> <div>I think the result is not so harmful.</div><div>=C2=A0<br></div></div>= <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= adding-left:1ex"> struct S<br> {<br> =C2=A0 =C2=A0 S opBinary(string op : &quot;&amp;&quot;, S)(S s)<br> =C2=A0 =C2=A0 {<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 return this;<br> =C2=A0 =C2=A0 }<br> }<br> <br> struct M<br> {<br> =C2=A0 =C2=A0 S s;<br> }<br> <br> void main()<br> {<br> =C2=A0 =C2=A0 M m;<br> =C2=A0 =C2=A0 auto s =3D m.s &amp; m.s; =C2=A0// ok<br> }<br> <br> Suppose you want to turn &#39;s&#39; into a read-only property, so you writ= e:<br> <br> struct S<br> {<br> =C2=A0 =C2=A0 S opBinary(string op : &quot;&amp;&quot;, S)(S s)<br> =C2=A0 =C2=A0 {<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 return this;<br> =C2=A0 =C2=A0 }<br> }<br> <br> struct M<br> {<br> =C2=A0 =C2=A0 property S s() { return _s; }<br> =C2=A0 =C2=A0 private S _s;<br> }<br> <br> void main()<br> {<br> =C2=A0 =C2=A0 M m;<br> =C2=A0 =C2=A0 auto s =3D m.s &amp; m.s; =C2=A0// fail<br> }<br> <br> Now the user-code fails.<br></blockquote><div><br></div><div style>This is = not correct.&quot;<span style=3D"font-family:arial,sans-serif;font-size:14p= x">m.s &amp; m.s&quot; is always parsed as binary bitwise AND expression.</= span></div> <div style><span style=3D"font-family:arial,sans-serif;font-size:14px">So t= here is no address expression.</span></div><div></div></div><br></div><div = class=3D"gmail_extra" style>Kenji Hara</div></div> --089e01493bd08d13f104d4e74dd8--
Feb 04 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Monday, 4 February 2013 at 14:25:10 UTC, Timon Gehr wrote:
 On 02/04/2013 03:05 PM, Andrei Alexandrescu wrote:
 ...
 Couldn't AddressOf use "&(" + exp + ")"?

 I thought more about this. The problem remains even without 
  property,
 due to optional parens in function invocation. Consider:

 ref int fun() { ... }
 auto p1 = &fun;
 auto p2 = &(fun);
 auto p3 = &(fun());

 What are the types of the three? The optional parens in 
 invocation
 require some disambiguation.

The obvious rule is not to give significance to redundant parentheses.
 I think the sensible disambiguation is to
 have &fun take the address of fun and the other two take the 
 address of
 fun's result.

No! &fun and &(fun) are the same thing. Functions that get their address taken are not implicitly invoked. (Again, Scala agrees.)

Scala don't really agree. fun is the function pointer. It is evaluated if the function pointer is a NOOP, but that's it. Here is scala semantic with D syntax : void bar() {} bar; // execute bar. Is an exception because taking the function pointer is a NOOP. void foo(void function() bar) {} foo(bar); // OK, bar is not evaluated.
Feb 04 2013
prev sibling next sibling parent kenji hara <k.hara.pg gmail.com> writes:
--089e01493bd05f4c9304d4e77709
Content-Type: text/plain; charset=UTF-8

2013/2/4 Timon Gehr <timon.gehr gmx.ch>

 On 02/04/2013 03:38 PM, kenji hara wrote:

 I think this is necessary feature for the D's function and property
 semantics.

Why?

Because, "property" is one of D-specific feature. In D, "property" is directly translated to function call. So, we should get balance between two requirements: 1. property should be treated as its returned type. 2. property should be distinguished from raw field. (For example, serialization library should recognize it) Address expression is _only_one_ built-in feature to make a callable object from function symbol. So this "special feature" is enough reasonable to me. Kenji Hara --089e01493bd05f4c9304d4e77709 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">2013/2/4 Timon Gehr <span dir=3D"ltr">&lt;<a href=3D"mailt= o:timon.gehr gmx.ch" target=3D"_blank">timon.gehr gmx.ch</a>&gt;</span><br>= <div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D"= gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border= -left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> <div class=3D"im">On 02/04/2013 03:38 PM, kenji hara wrote:</div><div class= =3D"im"> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= adding-left:1ex"> I think this is necessary feature for the D&#39;s function and property<br> semantics.<br> </blockquote> <br></div> Why?<br> </blockquote></div><br></div><div class=3D"gmail_extra" style>Because, &quo= t;property&quot; is one of D-specific feature.</div><div class=3D"gmail_ext= ra" style><br></div><div class=3D"gmail_extra" style>In D, &quot;property&q= uot; is directly translated to function call. So, we should get balance bet= ween two requirements:</div> <div class=3D"gmail_extra" style>1. property should be treated as its retur= ned type.</div><div class=3D"gmail_extra" style>2. property should be disti= nguished from raw field. (For example, serialization library should recogni= ze it)</div> <div><br></div><div class=3D"gmail_extra" style>Address expression is _only= _one_ built-in feature to make a callable object from function symbol. So</= div><div class=3D"gmail_extra" style>this &quot;special feature&quot; is en= ough reasonable to me.</div> <div class=3D"gmail_extra" style><br></div><div class=3D"gmail_extra" style=
Kenji Hara</div><div class=3D"gmail_extra" style><br></div></div>

--089e01493bd05f4c9304d4e77709--
Feb 04 2013
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 2/4/13, kenji hara <k.hara.pg gmail.com> wrote:
 This is not correct."m.s & m.s" is always parsed as binary bitwise AND
expression.
 So there is no address expression.

Fantastic, more special casing. I don't think you guys realize what a mess you would introduce. Basically: s & s; // fine, they're binary operators &s; // oops, doesn't work even if property returns a type with a unary operator On 2/4/13, kenji hara <k.hara.pg gmail.com> wrote:
 Address expression is _only_one_ built-in feature to make a callable object
 from function symbol. So
 this "special feature" is enough reasonable to me.

Yes "only one". And then later we'll add another "one", and another one, until we end up with the mess that is C++. This feature does not pull its own weight regardless of how easy it is to implement in the compiler. From a user's perspective, it is completely pointless and unintuitive.
Feb 04 2013
prev sibling next sibling parent kenji hara <k.hara.pg gmail.com> writes:
--089e013d12c0fbd45004d4e7bec9
Content-Type: text/plain; charset=UTF-8

2013/2/5 Andrej Mitrovic <andrej.mitrovich gmail.com>

 On 2/4/13, kenji hara <k.hara.pg gmail.com> wrote:
 This is not correct."m.s & m.s" is always parsed as binary bitwise AND

 So there is no address expression.

Fantastic, more special casing. I don't think you guys realize what a mess you would introduce. Basically: s & s; // fine, they're binary operators &s; // oops, doesn't work even if property returns a type with a unary operator

Address operator cannot be overloaded. http://dlang.org/operatoroverloading On 2/4/13, kenji hara <k.hara.pg gmail.com> wrote:
 Address expression is _only_one_ built-in feature to make a callable

 from function symbol. So
 this "special feature" is enough reasonable to me.

Yes "only one". And then later we'll add another "one", and another one, until we end up with the mess that is C++. This feature does not pull its own weight regardless of how easy it is to implement in the compiler. From a user's perspective, it is completely pointless and unintuitive.

We can think like this. "To resolve ambiguity, we should introduce new operator: &( exp )". Or, we can think like that we introduce one new restriction. "If you want to get function address, you MUST not add redundant parenthesis." &func; // OK &(func); // Bad. It should be written in the article "Migration for Property Enforcement". Kenji Hara --089e013d12c0fbd45004d4e7bec9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">2013/2/5 Andrej Mitrovic <span dir=3D"ltr">&lt;<a href=3D"= mailto:andrej.mitrovich gmail.com" target=3D"_blank">andrej.mitrovich gmail= .com</a>&gt;</span><br><div class=3D"gmail_extra"><div class=3D"gmail_quote= "><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde= r-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid= ;padding-left:1ex"> <div class=3D"im">On 2/4/13, kenji hara &lt;<a href=3D"mailto:k.hara.pg gma= il.com">k.hara.pg gmail.com</a>&gt; wrote:<br> &gt; This is not correct.&quot;m.s &amp; m.s&quot; is always parsed as bina= ry bitwise AND expression.<br> &gt; So there is no address expression.<br> <br> </div>Fantastic, more special casing. I don&#39;t think you guys realize wh= at a<br> mess you would introduce. Basically:<br> <br> s &amp; s; =C2=A0// fine, they&#39;re binary operators<br> &amp;s; =C2=A0// oops, doesn&#39;t work even if property returns a type wit= h a unary operator</blockquote><div><br></div><div>Address operator cannot = be overloaded.</div><div><a href=3D"http://dlang.org/operatoroverloading">h= ttp://dlang.org/operatoroverloading</a><br> </div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px = 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);bord= er-left-style:solid;padding-left:1ex"><div class=3D"im"> On 2/4/13, kenji hara &lt;<a href=3D"mailto:k.hara.pg gmail.com">k.hara.pg = gmail.com</a>&gt; wrote:<br> &gt; Address expression is _only_one_ built-in feature to make a callable o= bject<br> &gt; from function symbol. So<br> &gt; this &quot;special feature&quot; is enough reasonable to me.<br> <br> </div>Yes &quot;only one&quot;. And then later we&#39;ll add another &quot;= one&quot;, and another<br> one, until we end up with the mess that is C++. This feature does not<br> pull its own weight regardless of how easy it is to implement in the<br> compiler. From a user&#39;s perspective, it is completely pointless and<br> unintuitive.<br> </blockquote></div><br></div><div class=3D"gmail_extra" style>We can think = like this.</div><div class=3D"gmail_extra" style>&quot;To resolve ambiguity= , we should introduce new operator: &amp;( exp )&quot;.</div><div class=3D"= gmail_extra"> <br></div><div class=3D"gmail_extra">Or, we can think like that we introduc= e one new restriction.</div><div class=3D"gmail_extra">&quot;If you want to= get function address, you MUST not add redundant parenthesis.&quot;</div><= div class=3D"gmail_extra" style> &amp;func; =C2=A0 // OK<br></div><div class=3D"gmail_extra" style>&amp;(fun= c); =C2=A0// Bad.</div><div class=3D"gmail_extra" style><br></div><div clas= s=3D"gmail_extra" style>It should be written in the article &quot;Migration= for Property Enforcement&quot;.</div> <div class=3D"gmail_extra" style><br></div><div class=3D"gmail_extra">Kenji= Hara<br></div></div> --089e013d12c0fbd45004d4e7bec9--
Feb 04 2013
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 2/4/13, Dmitry Olshansky <dmitry.olsh gmail.com> wrote:
 Unary & is not overloadable, precisely due to confusing mess it can
 create (see C++).

Right I overlooked that, but this new rule will introduce a confusing mess as well. Anyway my vote is firmly against it. If anything we should have a vote on it before someone starts hacking on master without us knowing about it (UDA's, anyone?).
Feb 04 2013
prev sibling next sibling parent kenji hara <k.hara.pg gmail.com> writes:
--089e01493bd0e4e4bd04d4e824d9
Content-Type: text/plain; charset=UTF-8

I have thought in long term that, in D, "proerty" is just a syntactic
rerwiting rule of  function call. It is much reasonable abstraction to me.

So, using __trait is overkill.

Kenji Hara
2013/02/05 0:45 "Timon Gehr" <timon.gehr gmx.ch>:

 On 02/04/2013 04:08 PM, kenji hara wrote:

 2013/2/4 Timon Gehr <timon.gehr gmx.ch <mailto:timon.gehr gmx.ch>>

     On 02/04/2013 03:38 PM, kenji hara wrote:

         I think this is necessary feature for the D's function and
 property
         semantics.


     Why?


 Because, "property" is one of D-specific feature.

 In D, "property" is directly translated to function call. So, we should
 get balance between two requirements:
 1. property should be treated as its returned type.
 2. property should be distinguished from raw field. (For example,
 serialization library should recognize it)

Address expression is _only_one_ built-in feature to make a callable
 object from function symbol.

Property symbols are not to be treated like function symbols syntactically. That is the point. Otherwise we may as well get rid of properties. So this "special feature" is enough reasonable to me.
 ...

"special features" are usually not reasonable.

--089e01493bd0e4e4bd04d4e824d9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <p>I have thought in long term that, in D, &quot;proerty&quot; is just a sy= ntactic rerwiting rule of=C2=A0 function call. It is much reasonable abstra= ction to me.</p> <p>So, using __trait is overkill.</p> <p>Kenji Hara</p> <div class=3D"gmail_quote">2013/02/05 0:45 &quot;Timon Gehr&quot; &lt;<a hr= ef=3D"mailto:timon.gehr gmx.ch">timon.gehr gmx.ch</a>&gt;:<br type=3D"attri= bution"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border= -left:1px #ccc solid;padding-left:1ex"> On 02/04/2013 04:08 PM, kenji hara wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> 2013/2/4 Timon Gehr &lt;<a href=3D"mailto:timon.gehr gmx.ch" target=3D"_bla= nk">timon.gehr gmx.ch</a> &lt;mailto:<a href=3D"mailto:timon.gehr gmx.ch" t= arget=3D"_blank">timon.gehr gmx.ch</a>&gt;&gt;<br> <br> =C2=A0 =C2=A0 On 02/04/2013 03:38 PM, kenji hara wrote:<br> <br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 I think this is necessary feature for the D&#39= ;s function and property<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 semantics.<br> <br> <br> =C2=A0 =C2=A0 Why?<br> <br> <br> Because, &quot;property&quot; is one of D-specific feature.<br> <br> In D, &quot;property&quot; is directly translated to function call. So, we = should<br> get balance between two requirements:<br> 1. property should be treated as its returned type.<br> 2. property should be distinguished from raw field. (For example,<br> serialization library should recognize it)<br> <br> </blockquote> <br> This is what __traits are for.<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Address expression is _only_one_ built-in feature to make a callable<br> object from function symbol.<br> </blockquote> <br> Property symbols are not to be treated like function symbols syntactically.= That is the point. Otherwise we may as well get rid of properties.<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> So this &quot;special feature&quot; is enough reasonable to me.<br> <br> ...<br> </blockquote> <br> &quot;special features&quot; are usually not reasonable.<br> </blockquote></div> --089e01493bd0e4e4bd04d4e824d9--
Feb 04 2013
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 04 Feb 2013 06:47:26 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 On 2/4/13 2:10 AM, monarch_dodra wrote:
 It was my understanding that once a function is declared a property, it
 is meant to emulate a field. In such circumstance, there were talks
 about plain and simply not allowing taking the address of an  property
 function.

 2 questions:

 1. Was this proposal rejected, or have we just forgotten about it?

Well I at least haven't forgotten. Generally in D we don't want to 100% disallow doing something sensible.
 2. What are the actual use cases for taking the address of a property
 function?


Basically any time you have a use case for creating a delegate that returns a field or a property value. Instead of creating a wrapping delegate to call a function, it would make more sense to access the delegate directly. In other words, the use case isn't important, what we are doing here is creating an optimization. If the compiler could do that automatically, I think that would be fine too.
 Unless I'm mistaken, the "entire mess" of &a.b would be solved if we
 simply recognized it as "but you aren't allowed to take the address of
 the function b, so why have a syntax to support it anyways"? In such
 circumstance, "&a.b" == "&(a.b)" == "the address of the thing obtaining
 by running a.b"

Yes, if we disallowed address taking things would get a bit simpler.

Elsewhere you shot down my idea of __traits(getDelegate) generically because we already have this possibility: void foo(int) {} void foo(string) {} void delegate(string) dg = &foo; // select string overload What if we use the same exception for properties? property int foo(); auto x = &foo; // error int delegate() x = &foo; // ok -Steve
Feb 04 2013
prev sibling next sibling parent "Tove" <tove fransson.se> writes:
On Monday, 4 February 2013 at 16:01:45 UTC, Steven Schveighoffer 
wrote:
  property int foo();

 auto x = &foo; // error
 int delegate() x = &foo; // ok

 -Steve

I was going to submit the same suggestion, but didn't find time to until just now. gets my vote.
Feb 04 2013
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 2/4/13, Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:
 I think it's because it's a matter in which reasonable people may disagree.

Well, Walter seemed to agree with us before: d.puremagic.com/issues/show_bug.cgi?id=9062#c13 And even Kenji who likes it seemed to close his pull: https://github.com/D-Programming-Language/dmd/pull/1310#issuecomment-12524998 I don't know what changed their opinions now.
Feb 04 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Monday, 4 February 2013 at 11:47:25 UTC, Andrei Alexandrescu 
wrote:
 Yes, if we disallowed address taking things would get a bit 
 simpler.

The address taking of ?
Feb 04 2013
prev sibling next sibling parent "ixid" <nuaccount gmail.com> writes:
 And how often do you think you'll find yourself in the 
 situation of needing to get a delegate from a property anyway? 
 Can't we just make » property getter expressions are always 
 equivalent to their return value« a hard (simple!) rule and add 
 something like __traits(propertyGetter, ...) for the rare cases 
 where you really need to get hold of the underlying function?

As a beginner D user this seems like a far better solution, it's much clearer and doesn't violate one's normal understanding of parentheses (which is exactly as you've outlined). &(a.b) feels very much like a hack.
Feb 05 2013
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 04 Feb 2013 18:18:16 -0500, Walter Bright  
<newshound2 digitalmars.com> wrote:

 On 2/4/2013 6:05 AM, Andrei Alexandrescu wrote:
 Couldn't AddressOf use "&(" + exp + ")"?

 I thought more about this. The problem remains even without  property,  
 due to
 optional parens in function invocation. Consider:

 ref int fun() { ... }
 auto p1 = &fun;
 auto p2 = &(fun);
 auto p3 = &(fun());

 What are the types of the three? The optional parens in invocation  
 require some
 disambiguation. I think the sensible disambiguation is to have &fun  
 take the
 address of fun and the other two take the address of fun's result.

The only time it is valid to take the address of a function's return value is if the function returns a ref. But I also would think that it's a suspicious practice to take the address of a ref. We've disallowed it in other circumstances, why allow it here? If a function intends for someone to take the address of the return ref, shouldn't the function return a pointer instead?

I'd agree with you if we could have ref variables. In some cases, taking the address is the ONLY option. -Steve
Feb 05 2013
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 04 Feb 2013 17:23:25 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 On 2/4/13 11:01 AM, Steven Schveighoffer wrote:
  property int foo();

 auto x = &foo; // error
 int delegate() x = &foo; // ok

That's an interesting idea. I'm a bit weary about it though. At least for properties I'm inclined toward starting real tight with address-of disabled and relax the rules later.

Did you mean wary? In any case, that certainly is a defensible plan. We do have the workaround of declaring an extra delegate (and someone probably can come up with some template magic which does it). If we make it illegal, it gives us the option of coming up with a good solution later if needed. -Steve
Feb 05 2013
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

 One would still be able to take the address of a field in a 
 class because that's assumed to live on the GC heap.

Maybe some people want to allocate many small class instances on the stack. Bye, bearephile
Feb 05 2013
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 05 Feb 2013 13:33:35 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 Walter and I reviewed the discussion and had a long talk. We are very  
 seriously considering banning the use of & against a ref result from a  
 function (and actually ref parameters and even struct members in  safe  
 code). One would still be able to take the address of a field in a class  
 because that's assumed to live on the GC heap.

What about structs that live on the heap? e.g. a struct element of an array, or a struct member of a class instance. I think the point about safe code is moot, aren't pointers disallowed in safe code anyway?
 To get the address of an object in  system code without resorting to  
 operator& at all, we're considering adding a stdlib function implemented  
 like this (there are several other ways, this is just for illustration):

  system T* addressOf(T)(ref T obj)
 {
      static T* id(T* p) { return p; }
      auto idr = cast(T* function(ref T)) id;
      return idr(obj);
 }

I think a cast would be sufficient: cast(int *)(&refparam); // understood that a cast is required To jump through this machinery to turn a reference into a, um... reference, seems like a huge waste of code space and resources. -Steve
Feb 05 2013
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 05 Feb 2013 13:33:35 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 Walter and I reviewed the discussion and had a long talk. We are very  
 seriously considering banning the use of & against a ref result from a  
 function (and actually ref parameters and even struct members in  safe  
 code). One would still be able to take the address of a field in a class  
 because that's assumed to live on the GC heap.

Back to the problem I stated, how does one do this: ref A foo(); ref A bar(); A *a; if(condition) a = &foo(); else a = &bar(); // use a for a few lines I can see a possible solution but it's not pretty: void processA(ref A a) { // lines that deal with a here } if(condition) processA(foo()); else processA(bar()); But this kind of seems hacky. Why should I have to declare a function just to keep a persistent reference to a return value for the scope of my function? Not only is is awkward, there is a performance hit in that I have to call another function. Note also that this doesn't fix memory issues: struct S { ref S self() {return this;} } ref S bad() { S s; return s.self(); } Which I believe would be valid still with your rules. -Steve
Feb 05 2013
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 05 Feb 2013 13:33:35 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 Walter and I reviewed the discussion and had a long talk. We are very  
 seriously considering banning the use of & against a ref result from a  
 function (and actually ref parameters and even struct members in  safe  
 code). One would still be able to take the address of a field in a class  
 because that's assumed to live on the GC heap.

Thinking about this some more, would this be allowed: trusted T *getAddr(T)(ref T obj) { return &obj; } // allowed? You said only safe code would disallow address of ref parameters -Steve
Feb 05 2013
prev sibling next sibling parent "Zach the Mystic" <reachBUTMINUSTHISzach gOOGLYmail.com> writes:
On Tuesday, 5 February 2013 at 18:33:36 UTC, Andrei Alexandrescu 
wrote:
 I have a DIP in the making that makes "ref" entirely sealed, 
 i.e. it makes it impossible to have a dangling ref in safe 
 code. If that DIP gets approved, then DIP23 gets considerably 
 simplified because operator& won't be applicable to the result 
 of a function anymore.


 Andrei

I hope it at least considers my proposal with regard to 'out' return values. 'out' implies ref and guarantees that the result is as good as global: out int foo(ref int a) { return a; } // Error, 'out' return may not return ref parameter out int goo(ref int a) { return new int; } // Fine My impression was that this would solve 98% of problems, the other 2% requiring scope parameters, which also imply ref: ref int haa(ref int a, scope int b) { return b; } // Error, may not return scope parameter ref int gaa(ref int a, scope int b) { return a; } // Fine
Feb 05 2013
prev sibling next sibling parent "TommiT" <tommitissari hotmail.com> writes:
On Tuesday, 5 February 2013 at 18:33:36 UTC, Andrei Alexandrescu 
wrote:
 [..]
 Walter and I reviewed the discussion and had a long talk. We 
 are very seriously considering banning the use of & against a 
 ref result from a function (and actually ref parameters and 
 even struct members in  safe code). [..]

Did you consider using Rust's idea of 'Named lifetimes' in order to make ref parameters memory-safe. I haven't given much thought to it, but since Rust's borrowed pointers are effectively isomorphic to D's ref variables, it should work. Here's a Rust borrowed pointer tutorial: http://static.rust-lang.org/doc/tutorial-borrowed-ptr.html
Feb 05 2013
prev sibling next sibling parent "Zach the Mystic" <reachBUTMINUSTHISzach gOOGLYmail.com> writes:
On Tuesday, 5 February 2013 at 20:24:16 UTC, Andrei Alexandrescu 
wrote:
 I hope it at least considers my proposal with regard to 'out' 
 return
 values. 'out' implies ref and guarantees that the result is as 
 good as
 global:

 out int foo(ref int a) { return a; } // Error, 'out' return 
 may not
 return ref parameter
 out int goo(ref int a) { return new int; } // Fine

 My impression was that this would solve 98% of problems, the 
 other 2%
 requiring scope parameters, which also imply ref:

 ref int haa(ref int a, scope int b) { return b; } // Error, 
 may not
 return scope parameter
 ref int gaa(ref int a, scope int b) { return a; } // Fine

I'm sorry, I didn't know of that proposal. Generally we're aiming for economy of means i.e. we want to clarify semantics of existing syntax instead of adding new syntax and semantics. Andrei

It's not a new syntax, just new semantics. Also, the reason for adding these semantics to the function signature was so that the compiler would never have to leave the function in order to compile it. It's a natural complement to ref returns' scope being the most local of the ref parameters, which you suggested in your proposal. It keeps that too.
Feb 05 2013
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 05 Feb 2013 15:15:05 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 On 2/5/13 2:05 PM, Steven Schveighoffer wrote:
 I think a cast would be sufficient:

 cast(int *)(&refparam); // understood that a cast is required

 To jump through this machinery to turn a reference into a, um...
 reference, seems like a huge waste of code space and resources.

The whole point was to avoid using operator &.

The mechanism to avoid it seems overly extravagant (and prone to low performance). If you want actually avoid using operator &, then make a compiler special function or something. Also, the use of & can still be hidden inside a function. -Steve
Feb 05 2013
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 05 Feb 2013 15:21:14 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 Also consider the simpler:

 ref int id(ref int x) { return x; }
 ref int id1(ref int x) { return id(x); }
 ref int id2(ref int x) { return id1(x); }
 ref int oops(int x) { return id2(x); }

 DIP24 addresses that and other similar cases at their core.

I look forward to reading it. -Steve
Feb 05 2013
prev sibling next sibling parent "Max Samukha" <maxsamukha gmail.com> writes:
On Tuesday, 5 February 2013 at 18:33:36 UTC, Andrei Alexandrescu 
wrote:

 Walter and I reviewed the discussion and had a long talk. We 
 are very seriously considering banning the use of & against a 
 ref result from a function

Please, no. ref T foo(); extern(C) void bar(T*); bar(&foo()); // how?
Feb 05 2013
prev sibling next sibling parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On 2013-02-05, 23:46, Max Samukha wrote:

 On Tuesday, 5 February 2013 at 18:33:36 UTC, Andrei Alexandrescu wrote:

 Walter and I reviewed the discussion and had a long talk. We are very  
 seriously considering banning the use of & against a ref result from a  
 function

Please, no. ref T foo(); extern(C) void bar(T*); bar(&foo()); // how?

system T* addressOf(T)(ref T obj) { static T* id(T* p) { return p; } auto idr = cast(T* function(ref T)) id; return idr(obj); } bar(addressOf(foo()); // Like this It's right there in his post. -- Simen
Feb 05 2013
prev sibling next sibling parent "Zach the Mystic" <reachBUTMINUSTHISzach gOOGLYmail.com> writes:
On Tuesday, 5 February 2013 at 21:59:53 UTC, Andrei Alexandrescu 
wrote:
 Just to make sure: this is about 
 http://forum.dlang.org/thread/ririagrqecshjljcdubd forum.dlang.org.

 Language design is a subjective topic. With time I have learned 
 it's best to not comment very much about it. I have created 
 dozens, maybe hundreds of tidbits of language design and 
 invariably I believe they had obvious merits and negligible 
 drawbacks. The confidence in the quality of my own language 
 designs has decayed exponentially over the years.

 I'm telling this to put in perspective my following comment. I 
 think it's awesome that work like yours is discussed and 
 refined in this group. At the same time my opinion is that the 
 design is not appropriate for us. It changes semantics of 
 existing code and fosters a cross-talk between subcomponents 
 that has not been time tested. It is complicated in 
 implementation for a benefit that's not properly motivated. At 
 the top level it solves the wrong problem. As stated: "The 
 challenge is to do better, both in terms of functionality and 
 in terms of syntax, than his proposal: ..." The actual 
 challenge is to make properties work with maximum backward 
 compatibility, minimal surprise, best integration with the rest 
 of the language, and maximum of benefits.


 Andrei

Okay. But I just want to be clear that you are saying what I am reading, which is that I came to this language too late to really make a difference in it.
Feb 05 2013
prev sibling parent "Zach the Mystic" <reachBUTMINUSTHISzach gOOGLYmail.com> writes:
On Tuesday, 5 February 2013 at 21:59:53 UTC, Andrei Alexandrescu 
wrote:
 Just to make sure: this is about 
 http://forum.dlang.org/thread/ririagrqecshjljcdubd forum.dlang.org.

 Language design is a subjective topic. With time I have learned 
 it's best to not comment very much about it. I have created 
 dozens, maybe hundreds of tidbits of language design and 
 invariably I believe they had obvious merits and negligible 
 drawbacks. The confidence in the quality of my own language 
 designs has decayed exponentially over the years.

 I'm telling this to put in perspective my following comment. I 
 think it's awesome that work like yours is discussed and 
 refined in this group. At the same time my opinion is that the 
 design is not appropriate for us. It changes semantics of 
 existing code

My proposal changes exactly one existing semantic, which is that a nested struct will find symbols it doesn't find in itself in the parent before looking at module and import levels. I'm pretty sure it's a bad practice to shadow names in nested structs, and I predicted no code breakage at all in the vast majority of projects.
 and fosters a cross-talk between subcomponents that has not 
 been time tested. It is complicated in implementation for a 
 benefit that's not properly motivated. At the top level it 
 solves the wrong problem. As stated: "The challenge is to do 
 better, both in terms of functionality and in terms of syntax, 
 than his proposal: ..." The actual challenge is to make 
 properties work with maximum backward compatibility, minimal 
 surprise, best integration with the rest of the language, and 
 maximum of benefits.

 Andrei

I've thought about this some more. You're right in that my proposal does not meet the first two design goals. But it doesn't harm them either. property can exist side-by-side with my proposal indefinitely. The only demand you must make on programmers is that they convert all overloads of a given local property implementation at once so there's no repeat declaration. As far as best integration with the rest of the language, my proposal requires one new syntax (Highlander) and no new keyword or even the keeping of ' property' itself. As far as maximum of benefits, I think mine wins by far. Not only have properties been granted the full semantic power of the already-designed-and-implemented structs, but the features required to make this possible have their own uses totally apart from making properties easy. Yes, my proposal fosters cross-talk between subcomponents that have not been time tested, but it doesn't prevent people from programming in the way they always have, either, with the one exception mentioned above. So is my proposal properly motivated? Here's what happened. I saw a connection between what everyone is trying to do with properties and what the built-in struct operators already do. I can't figure out why you would want to have two systems when you could just design one really well (design goal 3 above: best integration with the rest of the language). So I figured out what needed to change to be able to use the one system for the two purposes. The new proposal with nested structs is confusing, but I see no problems with it. Underneath, it's just what old-fashioned C programming is about, a bunch of functions which accept a bunch of variables, some of them references. Whether or not my proposal gains any more traction than it already has, I consider myself lucky to have discovered it. It felt like it was just sitting right there for someone, and I was the one to find it. I may feel a little bad that there was so much opposition. So far, the original person who posed the challenge has said nothing at all about it, for example, but still, I'm glad I found it, and I don't even care at this point if anyone else cares.
Feb 05 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, Feb 03, 2013 at 08:30:48PM -0500, Andrei Alexandrescu wrote:
 On 2/3/13 3:16 AM, Andrei Alexandrescu wrote:
 [snip]
 
 Some more thinking got me to three simple principles that guide the
 proposed property design:
 
 http://wiki.dlang.org/DIP23#In_a_nutshell
 
 I think most, if not all, detailed rules derive from these.

This is precisely the kind of simplicity we need to resolve this issue. I fully concur. T -- 2+2=4. 2*2=4. 2^2=4. Therefore, +, *, and ^ are the same operation.
Feb 03 2013
prev sibling next sibling parent kenji hara <k.hara.pg gmail.com> writes:
--089e01493bd0c2ed4904d4dcc5a4
Content-Type: text/plain; charset=UTF-8

2013/2/4 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>

 On 2/3/13 3:16 AM, Andrei Alexandrescu wrote:
 [snip]

 Some more thinking got me to three simple principles that guide the
 proposed property design:

 http://wiki.dlang.org/DIP23#**In_a_nutshell<http://wiki.dlang.org/DIP23#In_a_nutshell>

 2. A  property may have EXACTLY ONE or EXACTLY TWO parameters, counting

a getter, and the TWO-parameter version is ALWAYS a setter. There's no variadics, defaulted parameters, and such. Unfortunately, I can present a counterexample. struct S { static int value; static property int foo() { return value; } static property void foo(int n) { value = n; } } void main() { int n = S.foo; S.foo = 1; } Should they be disallowed, as like module level properties? Kenji Hara --089e01493bd0c2ed4904d4dcc5a4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">2013= /2/4 Andrei Alexandrescu <span dir=3D"ltr">&lt;<a href=3D"mailto:SeeWebsite= ForEmail erdani.org" target=3D"_blank">SeeWebsiteForEmail erdani.org</a>&gt= ;</span><br> <blockquote class=3D"gmail_quote" style=3D"margin-top:0px;margin-right:0px;= margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color= :rgb(204,204,204);border-left-style:solid;padding-left:1ex">On 2/3/13 3:16 = AM, Andrei Alexandrescu wrote:<br> [snip]<br> <br> Some more thinking got me to three simple principles that guide the propose= d property design:<br> <br> <a href=3D"http://wiki.dlang.org/DIP23#In_a_nutshell" target=3D"_blank">htt= p://wiki.dlang.org/DIP23#<u></u>In_a_nutshell</a></blockquote><div><br></di= v><div>&gt; 2.=C2=A0A property may have EXACTLY ONE or EXACTLY TWO paramet= ers, counting the implicit this parameter if at all. The ONE-parameter vers= ion is ALWAYS a getter, and the TWO-parameter version is ALWAYS a setter. T= here&#39;s no variadics, defaulted parameters, and such.</div> <div><br></div><div>Unfortunately,=C2=A0I can present a counterexample.=C2= =A0</div><div><br></div><div><div>struct S {</div><div>=C2=A0 =C2=A0 static= int value;</div><div>=C2=A0 =C2=A0 static property int foo() { return=C2= =A0value; }</div><div>=C2=A0 =C2=A0=C2=A0static=C2=A0 property void foo(int= n) {=C2=A0value =3D n;=C2=A0}</div> <br class=3D""><div>}<br></div><div>void main() {</div><div>=C2=A0 =C2=A0 i= nt n =3D S.foo;</div><div>=C2=A0 =C2=A0 S.foo =3D 1;</div><div>}</div></div=
<div><br></div><div>Should they be disallowed, as like module level proper=

</div><div>Kenji Hara</div></div></div></div> --089e01493bd0c2ed4904d4dcc5a4--
Feb 03 2013
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, February 03, 2013 22:06:27 Andrei Alexandrescu wrote:
 Yes. No static properties.

So, properties such as Duration.max would simply be normal functions called without parens if they have they have to be property functions rather than variables or enums? - Jonathan M Davis
Feb 03 2013
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, February 04, 2013 05:00:21 David Nadlinger wrote:
 On Monday, 4 February 2013 at 03:15:51 UTC, David Nadlinger wrote:
 On Monday, 4 February 2013 at 03:11:25 UTC, Andrei Alexandrescu
=20
 wrote:
 I really think you are wrong about this. Parenthesizing has
 nothing to do with this. &a.b is punctuation that creates an
 indivizible unit.

a.b already is an indivisible unit, the result of the function call.

Actually, let me illustrate this point a bit further, sorry for the hasty reply. =20 The problem I see is that usually, one can insert grouping pairs of parentheses into an expression according to the operator precedence/associativity rules at will without changing the result. This isn't merely a theoretical exercise, but the way (well, in the form of trees) I tend to reason about source code intuitively. =20 Now, grouping the expression =C2=BB&a.b=C2=AB according to the preced=

 rules yields =C2=BB&(a.b)=C2=AB =E2=80=93 but in your proposal, they =

 completely different things.
=20
 You could argue that &<expression>.<identifier> is a special
 construct different from the normal address-of operator. But
 where do you mentally draw the line? What about &a.b.c <->
 &(a.b).c <-> &((a.b).c)? &(a + b).c <-> &((a + b).c)?
=20
 Again, from an user's perspective the change in behavior seems to
 be completely at odds with the usual rule in C-family languages
 that grouping parens can be added without changing the meaning of
 an expression. Thus, this part of the proposed syntax strikes me
 as being extremely misleading, which is especially bad because
 the situation with the two possible meanings is confusing enough
 to start out with already.
=20
 And how often do you think you'll find yourself in the situation
 of needing to get a delegate from a property anyway? Can't we
 just make =C2=BB property getter expressions are always equivalent to=

 their return value=C2=AB a hard (simple!) rule and add something like=

 __traits(propertyGetter, ...) for the rare cases where you really
 need to get hold of the underlying function?

I tend to agree that making the parens change the nature of the express= ion is=20 a bad idea. I'm also concerned that making it legal to take the address= of a=20 property function is going to cause serious issues when anyone tries to= =20 actually try and swap between variables and property functions. But the= re's=20 also the issue of it not being terribly common to need the address of a= =20 property function. The biggest concern there would be what happens when= =20 someone takes the address of a variable which then gets turned into a=20= property. It's not going to work, and the way that that it doesn't work= is=20 going to vary depending on what & does on a property function and what = they're=20 trying to assign it to. - Jonathan M Davis
Feb 03 2013
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, February 03, 2013 03:16:08 Andrei Alexandrescu wrote:
 Destroy.

Another thing to consider would be to allow putting property on a variable with the idea that variables marked as such would not be usable in any situation where a property function wouldn't be - such as taking their address or passing them by ref. That would reduce code breakage when switching between public variables and property functions. The alternative would be to make it so that putting property on a variable would lower it to property functions. So, struct S { property int prop; } becomes something like struct S { private int __prop; property int prop() safe inout pure nothrow { return __prop; } property int prop(int value) safe pure nothrow { return __prop = value; } } One of the main ideas behind properties is to make it so that you can make something a variable when you don't the extra boilerplate for setter and getter functions (e.g. because you don't need to check the value it's being set to), but it's still easy to swap it out with an actual getter and setter function later when you actually _do_ need extra stuff in those functions. And if we don't do something to indicate that a variable could be swapped out with a property function later, then you risk code doing stuff like taking its address or passing it by ref, and that code will then break if the variable ever does become a property function. - Jonathan M Davis
Feb 03 2013
prev sibling next sibling parent "TommiT" <tommitissari hotmail.com> writes:
On Monday, 4 February 2013 at 04:45:27 UTC, Jonathan M Davis 
wrote:
 On Sunday, February 03, 2013 03:16:08 Andrei Alexandrescu wrote:
 Destroy.

Another thing to consider would be to allow putting property on a variable with the idea that variables marked as such would not be usable in any situation where a property function wouldn't be - such as taking their address or passing them by ref. [..]

If we consider a variable marked as property as a variable whose access is restricted, then the following should be also illegal uses of it: 1) calling its non-const method 2) mutating its data field If we consider a variable marked as property as lowered to getter and setter properties, then it doesn't have those restrictions. This is what I would advocate.
Feb 03 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Monday, 4 February 2013 at 05:36:10 UTC, Andrei Alexandrescu 
wrote:
 On 2/3/13 11:31 PM, Jonathan M Davis wrote:
 I tend to agree that making the parens change the nature of 
 the expression is
 a bad idea.

I think there's some misunderstanding here. Parens change the nature of expressions ALL the time. There is a weird rule in C++11 that makes sometimes typeof(expr) and typeof((expr)) mean different things. That is arguably an example to avoid. But introducing parens among parts of an expression is expected to affect meaning.

Weird behaviors of C++ are a very good reason to have D in the first place.
Feb 03 2013
prev sibling next sibling parent Johannes Pfau <nospam example.com> writes:
Am Mon, 04 Feb 2013 04:24:46 +0100
schrieb "TommiT" <tommitissari hotmail.com>:

 On Monday, 4 February 2013 at 02:36:41 UTC, Timon Gehr wrote:
 On 02/04/2013 03:23 AM, kenji hara wrote:
 Unfortunately, I can present a counterexample.

 struct S {
     static int value;
     static  property int foo() { return value; }
     static  property void foo(int n) { value = n; }

 }
 void main() {
     int n = S.foo;
     S.foo = 1;
 }

 Should they be disallowed, as like module level properties?

 Kenji Hara

Probably. (static essentially means module-level, but in a potentially nested name space.)

I disagree. Static properties can be allowed because they're not ambiguous. The problem with module-level: property void foo(int n) {} ...are the two interpretations of foo as either a setter taking an int or a getter property of int type. So, one of those interpretations must be disallowed. But, with static member properties, there aren't multiple interpretations.

"getter property of int type" But a getter shouldn't return void, right? So it's actually not ambiguous?
Feb 03 2013
prev sibling next sibling parent "Daniel Kozak" <kozzi11 gmail.com> writes:
 From DIP:
If prop is a property, &prop or a.prop obey the normal rules...

I think there missing '&' before a.prop:

If prop is a property, &prop or &a.prop obey the normal rules...
Feb 04 2013
prev sibling next sibling parent Chad Joan <chadjoan gmail.com> writes:
On 02/03/2013 03:16 AM, Andrei Alexandrescu wrote:
 Walter and I have had a discussion on how to finalize properties.

 http://wiki.dlang.org/DIP23

 We got input from DIP21 (which we didn't want to clobber, hence the new
 DIP) and the recent discussion.

 The proposal probably won't be accepted in its current form because it
 breaks some code. We hope to bring it to good shape with everyone's help.

 In brief:

 * Optional parens stay.

 * Just mentioning a function or method without parens does NOT
 automatically take its address. (This is a change from the current
 behavior.)

 * Read properties (using  property) work as expected with the mention
 that they may NOT be called with the parens. Any parens would apply to
 the returned value.

 * Write properties (using  property) may only be used in the assignment
 form (no function-style call allowed).

 It is understood that the current proposal is just a draft and there
 must be quite a few corner cases it doesn't discuss. We also understand
 it's impossible to reconcile all viewpoints and please all tastes. Our
 hope is to get to a point where the rules are self-consistent,
 meaningful, and complete.


 Destroy.

 Andrei

This would be a huge step up from the current properties. Thank you for listening and being rigorous. ------ There are a couple things in the DIP that I might be able to destroy; here's the first: the property rewrite is chosen based on whether it compiles or not. I don't like the rule and its potential ambiguities. When I was attempting a property rewrite patch for DMD, one of the first things I did was match the different contexts a property expression may appear in: - read-only - read-write - write-only In read-only contexts, stuff like "q = prop;" or "auto foo(T)(T x); ... foo(prop);" should only call the getter. In read-write context, the full rewrite is applied. "prop++" expands to "(auto t = prop, t++, prop = t);". This could include things like appearing as the argument to a function's ref parameter, but I've been convinced at one point that it might be wiser to disallow that (unfortunately, I forget /why/). In write-only contexts, only the setter is applied. This is stuff like "prop = q;" or "auto foo(T)(out T x); ... foo(prop);". ------ I would suggest guaranteeing that the property rewrite will evaluate the getter/setter no more than once in an expression. ------ As Jonathan M Davis pointed out, it should be possible to mark fields as property and forbid address-of on such members. ------ I also think that allowing address-of on properties is dubious. I've mentioned that in another response. There is no easy way to make address-of do the same thing for variables and for properties, so to make properties work consistently in the transition between POD to calculated data, it is easiest to just forbid address-of. I think that allowing getters to return lvalues is dangerous in general. It could create ambiguities in the writer's intentions with getter/setter pairs: did they want prop++ to expand to (prop++) or (auto t = prop, t++, t = prop)? I think the latter should always be chosen, and the whole example should never compile if they only provide a getter.
Feb 04 2013
prev sibling next sibling parent reply "Rob T" <alanb ucora.com> writes:
On Sunday, 3 February 2013 at 08:16:08 UTC, Andrei Alexandrescu 
wrote:
 Walter and I have had a discussion on how to finalize 
 properties.

 http://wiki.dlang.org/DIP23

 We got input from DIP21 (which we didn't want to clobber, hence 
 the new DIP) and the recent discussion.

 The proposal probably won't be accepted in its current form 
 because it breaks some code. We hope to bring it to good shape 
 with everyone's help.

 In brief:

 * Optional parens stay.

 * Just mentioning a function or method without parens does NOT 
 automatically take its address. (This is a change from the 
 current behavior.)

 * Read properties (using  property) work as expected with the 
 mention that they may NOT be called with the parens. Any parens 
 would apply to the returned value.

 * Write properties (using  property) may only be used in the 
 assignment form (no function-style call allowed).

 It is understood that the current proposal is just a draft and 
 there must be quite a few corner cases it doesn't discuss. We 
 also understand it's impossible to reconcile all viewpoints and 
 please all tastes. Our hope is to get to a point where the 
 rules are self-consistent, meaningful, and complete.


 Destroy.

 Andrei

IMO the concept of emulating a field with a function is proving to be an idea that should be simplified. Just look at the huge amount of wasted effort on these discussions, We have at least 5 threads open, two open DIPS and two superseded DIPS. As it stands, I don't even know why there's such a strong desire to have properties that emulate variables. I read the arguments in favor, and they are all very weak IMO, and probably will result in maintenance issues. We all seem to be getting along just fine without full variable emulation, and what we have now for property seems good enough (although I agree it could be done better with a few simple adjustments). If we must keep property, then my advice is to keep the emulation simple and restricted to the cases where it can work without acrobatics (eg no address taking, no pass by ref or return by ref). What I see being proposed is going too far for very little gain. BTW, I am wondering if the idea of "memberspaces" was considered, and if it was considered, then why was it dropped? I won't argue for them in here, just would like to know what the thinking is because I don't recall any feedback from Walter or Andrei. --rt
Feb 04 2013
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/4/13 1:15 PM, Rob T wrote:
 BTW, I am wondering if the idea of "memberspaces" was considered, and if
 it was considered, then why was it dropped?

An idea that departs considerably from the current status in D has a disadvantage compared to an idea that makes things work within the property framework. Andrei
Feb 04 2013
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, February 04, 2013 23:56:50 kenji hara wrote:
 2013/2/4 Andrej Mitrovic <andrej.mitrovich gmail.com>
 
 On 2/4/13, Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:
 I'm unclear that's a problem.

The problem is you cannot replace a field with a property function without breaking user-code when you take into account operator

 overloading. Consider:

As far as I thought, such rewriting will cause: 1. compile error by type mismatch (if you use &obj.field), 2. or, success of compilation *without any semantic breaking* (if you don't use &obj.field). I think the result is not so harmful.

There's also the issue a variable being able to be passed by ref, which a property function can't emulate, which is why it would be quite valuable to be able to mark a variable as property - either to indicate that it's illegal to do anything with it that you can't do with a property function or to make it so that it lowers to getter and setter property functions and therefore can't be used with anything which wouldn't work with a property function. But if we could guarantee that swapping out variables and property functions wouldn't break code, then we could get rid of a _lot_ of property functions (since many of them don't do anything other than set and/or return the variable that they're wrapping). Because we currently allow stuff which only works with a variable or a function, we can't just seamlessly between variables and property functions, and it's not going to happen anywhere near as often for fear of breaking code. And many more people will simply create useless wrapper property functions around variables in case they need to add more code to them later (e.g. to validate the argument to the setter). We'd be much better off if anything which wasn't legal for both variables and property functions was made illegal for property functions and added a way to do the same for variables which are supposed to be treated as properties rather than explicitly being intended to be public variables like in a POD type. We could save a lot of boilerplate code if we can simply make it variables and property functions guaranteed to be swappable without breaking code. - Jonathan M Davis
Feb 04 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/4/13 2:04 PM, Jonathan M Davis wrote:
 We could save a lot of boilerplate code if we can simply make it variables and
 property functions guaranteed to be swappable without breaking code.

I think this is quite powerful. The way we can do this is by making properties emulate a subset of actual variables. Andrei
Feb 04 2013
next sibling parent reply Chad Joan <chadjoan gmail.com> writes:
On 02/04/2013 05:28 PM, Andrei Alexandrescu wrote:
 On 2/4/13 2:04 PM, Jonathan M Davis wrote:
 We could save a lot of boilerplate code if we can simply make it
 variables and
 property functions guaranteed to be swappable without breaking code.

I think this is quite powerful. The way we can do this is by making properties emulate a subset of actual variables. Andrei

I agree with Jonathan. Please do not make them a subset. Make them as identical as possible. The subset thing makes them no longer "swappable". Allow variables to be marked with property to limit them to operations that property functions can do, and make sure property functions are limited to what property variables can do (ex: no address-of!). With that in hand, they'll be very swappable.
Feb 04 2013
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/4/13 10:30 PM, Chad Joan wrote:
 On 02/04/2013 05:28 PM, Andrei Alexandrescu wrote:
 On 2/4/13 2:04 PM, Jonathan M Davis wrote:
 We could save a lot of boilerplate code if we can simply make it
 variables and
 property functions guaranteed to be swappable without breaking code.

I think this is quite powerful. The way we can do this is by making properties emulate a subset of actual variables. Andrei

I agree with Jonathan. Please do not make them a subset. Make them as identical as possible. The subset thing makes them no longer "swappable". Allow variables to be marked with property to limit them to operations that property functions can do, and make sure property functions are limited to what property variables can do (ex: no address-of!). With that in hand, they'll be very swappable.

The purpose is to replace members with properties, not to change one's mind back and forth. There will be no marking of variables with property as that can be easily achieved by actually making them properties. Andrei
Feb 04 2013
next sibling parent Chad Joan <chadjoan gmail.com> writes:
On 02/04/2013 11:18 PM, Andrei Alexandrescu wrote:
 On 2/4/13 10:30 PM, Chad Joan wrote:
 On 02/04/2013 05:28 PM, Andrei Alexandrescu wrote:
 On 2/4/13 2:04 PM, Jonathan M Davis wrote:
 We could save a lot of boilerplate code if we can simply make it
 variables and
 property functions guaranteed to be swappable without breaking code.

I think this is quite powerful. The way we can do this is by making properties emulate a subset of actual variables. Andrei

I agree with Jonathan. Please do not make them a subset. Make them as identical as possible. The subset thing makes them no longer "swappable". Allow variables to be marked with property to limit them to operations that property functions can do, and make sure property functions are limited to what property variables can do (ex: no address-of!). With that in hand, they'll be very swappable.

The purpose is to replace members with properties, not to change one's mind back and forth. There will be no marking of variables with property as that can be easily achieved by actually making them properties. Andrei

Why not allow one to change their mind back and forth? That would be far more useful from a design perspective. With what you're proposing, there is no migration path for variables. They are not swappable at all. Once someone takes the address of your "public int foo;" it will no longer be possible to turn it into a property without breaking API. Going even further, suppose we allow property variables and also allow address-of on property functions only (a subset relationship!). Now it is possible to make a "public property int foo;" that can be migrated to a full-fledged property later without some god-awful boilerplate. However, the developer will hesitate to make such a change: converting property variables to property functions is a liability. Once you convert, you can't convert back without breaking API. At that point the hypothetical developer wonders: "why am I using property variables in the first place? I can't migrate them because of the liability, which makes them no more useful than public variables that break encapsulation." At that point the whole concept goes out the window and we're back in Java writing drivel like this: class XYZ { int m_foo; int getFoo() { return m_foo; } void setFoo(int val) { m_foo = val; } ... } I'm arguing the point because I'd much rather write this: class XYZ { property int foo; ... }
Feb 04 2013
prev sibling next sibling parent Chad Joan <chadjoan gmail.com> writes:
On 02/04/2013 11:18 PM, Andrei Alexandrescu wrote:
 On 2/4/13 10:30 PM, Chad Joan wrote:
 I agree with Jonathan.

 Please do not make them a subset. Make them as identical as possible.
 The subset thing makes them no longer "swappable". Allow variables to be
 marked with  property to limit them to operations that  property
 functions can do, and make sure  property functions are limited to what
  property variables can do (ex: no address-of!). With that in hand,
 they'll be very swappable.

The purpose is to replace members with properties, not to change one's mind back and forth. There will be no marking of variables with property as that can be easily achieved by actually making them properties. Andrei

Related: Is there some reason why we /need/ to be able to take the address of properties? Wouldn't something like 'someFunc(PropAccessor!"prop"(foo))' work in cases where we need a generic way to defer reads and writes? For clarity: auto PropAccessor(string propertyStr, T)( T tinstance ) { struct Accessor(string propertyStr, U) { private U tinstance; auto get() { mixin("return tinstance."~propertyStr~";"); } // I had to put system here to shut up a compiler error. Bug? system void set(V)(V val) { mixin("tinstance."~propertyStr~" = val;"); } } Accessor!(propertyStr, T) acc; acc.tinstance = tinstance; return acc; } auto PtrAccessor(T)( T* payload ) { struct Accessor(U) { private U* payload; U get() { return *payload; } U set(U val) { return *payload = val; } } Accessor!(T) acc; acc.payload = payload; return acc; } template isAccessor(Acc) { Acc a; static if ( __traits(compiles, { auto x = a.get(); } ) && __traits(compiles, a.set(a.get())) ) const bool isAccessor = true; else const bool isAccessor = false; } // Function that accepts the be-all-end-all of reference types. auto someFunc(Acc)(Acc qux) if ( isAccessor!(Acc) ) { auto x = qux.get(); x |= 0xF00D; qux.set(x); return qux.get(); } struct MyStruct { private int m_q; property int q() { return m_q; } property void q(int v) { m_q = v; } } unittest { MyStruct s; s.q = 0; int abc = 0; assert(someFunc(PtrAccessor(&abc)) == 0xF00D); assert(someFunc(PropAccessor!"q"(s)) == 0xF00D); } void main() { }
Feb 04 2013
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-02-05 05:18, Andrei Alexandrescu wrote:

 The purpose is to replace members with properties, not to change one's
 mind back and forth. There will be no marking of variables with
  property as that can be easily achieved by actually making them
 properties.

Why not? That will just require needless boilerplate code, wrappers just forwarding to instance variables. I have wanted to have this since the introduction of the property keyword. -- /Jacob Carlborg
Feb 05 2013
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-02-05 07:13, Jonathan M Davis wrote:

 One of the main purposes generally given for having properties is so that you
 can make them public variables when you don't need them to do anything but get
 and set the member variable, but you can still make it a function later when
 you need to add other stuff to it (such as checking the value that it's being
 set to). One of the primary reasons for making a property function act like a
 variable is precisely so that you can switch between variables and functions
 when refactoring without breaking code.

 Also, being able to mark variables as  property would save us a lot of
 boilerplate. Instead, it's incredibly common to do stuff like

 struct S
 {
       property int prop()  safe const pure nothrow
      { return _prop; }

       property int prop(int value)  safe pure
      { return _prop =  value; }

      private int _prop;
 }

 That's a lot of extra code just to buy some encapsulation. If we could do

 struct S
 {
       property int prop;
 }

 we could really reduce the amount of boilerplate code surrounding member
 variables. Even if putting  property on a variable simply lowered to the
 property functions rather than it still be a variable, it would be a big help.
 But without either that or marking variables with  property so that you can't
 do anything to them that you can't do to a property function, we lose the
 ability to make a property a variable when the getters and setters are
 unnecessary, and that means that we're stuck with a lot of extra boilerplate.

I fully agree. But they do need to be lowered to methods, see: http://forum.dlang.org/thread/kel6c8$1h5d$1 digitalmars.com?page=17#post-keqfol:242un9:241:40digitalmars.com -- /Jacob Carlborg
Feb 05 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-02-05 07:13, Jonathan M Davis wrote:

 One of the main purposes generally given for having properties is so that you
 can make them public variables when you don't need them to do anything but get
 and set the member variable, but you can still make it a function later when
 you need to add other stuff to it (such as checking the value that it's being
 set to). One of the primary reasons for making a property function act like a
 variable is precisely so that you can switch between variables and functions
 when refactoring without breaking code.

 Also, being able to mark variables as  property would save us a lot of
 boilerplate. Instead, it's incredibly common to do stuff like

 struct S
 {
       property int prop()  safe const pure nothrow
      { return _prop; }

       property int prop(int value)  safe pure
      { return _prop =  value; }

      private int _prop;
 }

 That's a lot of extra code just to buy some encapsulation. If we could do

 struct S
 {
       property int prop;
 }

 we could really reduce the amount of boilerplate code surrounding member
 variables. Even if putting  property on a variable simply lowered to the
 property functions rather than it still be a variable, it would be a big help.
 But without either that or marking variables with  property so that you can't
 do anything to them that you can't do to a property function, we lose the
 ability to make a property a variable when the getters and setters are
 unnecessary, and that means that we're stuck with a lot of extra boilerplate.

BTW, if it does get lowered to methods, do we want to be able to access the instance variable directly? I think it's good to be able to bypass the setter/getter sometimes internally. Alternatively there could be a __traits to access the instance variable. -- /Jacob Carlborg
Feb 05 2013
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 02/05/2013 12:34 PM, Jacob Carlborg wrote:
 On 2013-02-05 07:13, Jonathan M Davis wrote:

 One of the main purposes generally given for having properties is so
 that you
 can make them public variables when you don't need them to do anything
 but get
 and set the member variable, but you can still make it a function
 later when
 you need to add other stuff to it (such as checking the value that
 it's being
 set to). One of the primary reasons for making a property function act
 like a
 variable is precisely so that you can switch between variables and
 functions
 when refactoring without breaking code.

 Also, being able to mark variables as  property would save us a lot of
 boilerplate. Instead, it's incredibly common to do stuff like

 struct S
 {
       property int prop()  safe const pure nothrow
      { return _prop; }

       property int prop(int value)  safe pure
      { return _prop =  value; }

      private int _prop;
 }

 That's a lot of extra code just to buy some encapsulation. If we could do

 struct S
 {
       property int prop;
 }

 we could really reduce the amount of boilerplate code surrounding member
 variables. Even if putting  property on a variable simply lowered to the
 property functions rather than it still be a variable, it would be a
 big help.
 But without either that or marking variables with  property so that
 you can't
 do anything to them that you can't do to a property function, we lose the
 ability to make a property a variable when the getters and setters are
 unnecessary, and that means that we're stuck with a lot of extra
 boilerplate.

BTW, if it does get lowered to methods, do we want to be able to access the instance variable directly? I think it's good to be able to bypass the setter/getter sometimes internally. Alternatively there could be a __traits to access the instance variable.

I like the general idea. But to access variable one can still use tupleof, so there should be a guarantee that the hidden field layout is the same as if it was declared as variable.
Feb 05 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-02-05 10:10, Dmitry Olshansky wrote:

 I like the general idea. But to access variable one can still use
 tupleof, so there should be a guarantee that the hidden field layout is
 the same as if it was declared as variable.

As long as accessing it via tupleof works it would be fine. A serializer would be quite crippled otherwise. -- /Jacob Carlborg
Feb 05 2013
prev sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, February 04, 2013 23:18:57 Andrei Alexandrescu wrote:
 On 2/4/13 10:30 PM, Chad Joan wrote:
 On 02/04/2013 05:28 PM, Andrei Alexandrescu wrote:
 On 2/4/13 2:04 PM, Jonathan M Davis wrote:
 We could save a lot of boilerplate code if we can simply make it
 variables and
 property functions guaranteed to be swappable without breaking code.

I think this is quite powerful. The way we can do this is by making properties emulate a subset of actual variables. Andrei

I agree with Jonathan. Please do not make them a subset. Make them as identical as possible. The subset thing makes them no longer "swappable". Allow variables to be marked with property to limit them to operations that property functions can do, and make sure property functions are limited to what property variables can do (ex: no address-of!). With that in hand, they'll be very swappable.

The purpose is to replace members with properties, not to change one's mind back and forth. There will be no marking of variables with property as that can be easily achieved by actually making them properties.

One of the main purposes generally given for having properties is so that you can make them public variables when you don't need them to do anything but get and set the member variable, but you can still make it a function later when you need to add other stuff to it (such as checking the value that it's being set to). One of the primary reasons for making a property function act like a variable is precisely so that you can switch between variables and functions when refactoring without breaking code. Also, being able to mark variables as property would save us a lot of boilerplate. Instead, it's incredibly common to do stuff like struct S { property int prop() safe const pure nothrow { return _prop; } property int prop(int value) safe pure { return _prop = value; } private int _prop; } That's a lot of extra code just to buy some encapsulation. If we could do struct S { property int prop; } we could really reduce the amount of boilerplate code surrounding member variables. Even if putting property on a variable simply lowered to the property functions rather than it still be a variable, it would be a big help. But without either that or marking variables with property so that you can't do anything to them that you can't do to a property function, we lose the ability to make a property a variable when the getters and setters are unnecessary, and that means that we're stuck with a lot of extra boilerplate. - Jonathan M Davis
Feb 04 2013
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-02-04 23:52, Jonathan M Davis wrote:

 Which is why I would argue that we need to be able to mark variables with
  property (which either makes it so that you can't do anything with them that
 you can't do with a property function or makes it so that it lowers to
 property functions for getting and setting), and we need to disallow taking
 the address of property functions as well as anything else that you could do
 with a variable that we can't emulate with a property function.

They need to be lowered to methods. Otherwise you cannot switch from a method to a field, since methods are virtual and can be overridden in unknown subclasses. -- /Jacob Carlborg
Feb 05 2013
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, February 04, 2013 17:28:24 Andrei Alexandrescu wrote:
 On 2/4/13 2:04 PM, Jonathan M Davis wrote:
 We could save a lot of boilerplate code if we can simply make it variables
 and property functions guaranteed to be swappable without breaking code.

properties emulate a subset of actual variables.

Yes. There are things that propery functions need to emulate from normal variables (hence the rewrites with ++ and += and whatnot), and there are of course things that they can't emulate (like taking the address of a variable). But what we also need is a way to mark a variable as a property and then make it so such a variable and property functions have the same capabilities so that you're guaranteed to be able to swap between the two without breaking code. As soon as one of the two has capabilities that the other doesn't have, or there's a major semantic change between them (like taking the address works on one but not the other or the type returned by taking the address differs), then you can't do that. Which is why I would argue that we need to be able to mark variables with property (which either makes it so that you can't do anything with them that you can't do with a property function or makes it so that it lowers to property functions for getting and setting), and we need to disallow taking the address of property functions as well as anything else that you could do with a variable that we can't emulate with a property function. - Jonathan M Davis
Feb 04 2013
prev sibling next sibling parent reply "Zach the Mystic" <reachBUTMINUSTHISzach gOOGLYmail.com> writes:
On Sunday, 3 February 2013 at 08:16:08 UTC, Andrei Alexandrescu 
wrote:
 Walter and I have had a discussion on how to finalize 
 properties.

 http://wiki.dlang.org/DIP23

 We got input from DIP21 (which we didn't want to clobber, hence 
 the new DIP) and the recent discussion.

 The proposal probably won't be accepted in its current form 
 because it breaks some code. We hope to bring it to good shape 
 with everyone's help.

 In brief:

 * Optional parens stay.

 * Just mentioning a function or method without parens does NOT 
 automatically take its address. (This is a change from the 
 current behavior.)

 * Read properties (using  property) work as expected with the 
 mention that they may NOT be called with the parens. Any parens 
 would apply to the returned value.

 * Write properties (using  property) may only be used in the 
 assignment form (no function-style call allowed).

 It is understood that the current proposal is just a draft and 
 there must be quite a few corner cases it doesn't discuss. We 
 also understand it's impossible to reconcile all viewpoints and 
 please all tastes. Our hope is to get to a point where the 
 rules are self-consistent, meaningful, and complete.


 Destroy.

 Andrei

http://forum.dlang.org/thread/ririagrqecshjljcdubd forum.dlang.org Smash.
Feb 04 2013
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 02/05/2013 02:28 AM, Andrei Alexandrescu wrote:> On 2/4/13 2:04 PM, 
Jonathan M Davis wrote:
 We could save a lot of boilerplate code if we can simply make it
 variables and
 property functions guaranteed to be swappable without breaking code.

I think this is quite powerful. The way we can do this is by making properties emulate a subset of actual variables.

This is the primary real-world proble to solve. If tackle it right we'd secure a sizable flow of Java converts simply because of this feature alone ;) More seriously I believe it's worth noting that properties can't emulate (in principle) exactly one aspect of variable - taking address as a pointer. Honestly I can't see a way to overcome it without introducing a user-defined way to impose this restriction on a field of a struct/class. Then keeping in mind __traits I have the following clause to add to the current proposal: Inside of aggregate a field marked with property indicate is semantically equivalent to compiler wrapping it with trivial getter and setter. Example: struct Foo{ property T x; } treated semantically as if: T __x; // hidden by compiler //templated to have deduced safe, pure, nothrow property T x()()inout{ return x; } property void x()(T val){ x = val; } --- Dmitry Olshansky
Feb 05 2013
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 2/5/13 3:39 AM, Dmitry Olshansky wrote:
 On 02/05/2013 02:28 AM, Andrei Alexandrescu wrote:> On 2/4/13 2:04 PM,
 Jonathan M Davis wrote:
  >> We could save a lot of boilerplate code if we can simply make it
  >> variables and
  >> property functions guaranteed to be swappable without breaking code.
  >
  > I think this is quite powerful. The way we can do this is by making
  > properties emulate a subset of actual variables.
  >

 This is the primary real-world proble to solve.

The problem with this approach is feature creep - there will always be yet another possible case in which a feature helps some case. We need to put a halt on that. Unprotected, unchecked member variables that can be get and set without any hooks into the enclosing structure are rare. That's not the case we should help and cater for. When that's the case, the entire object is legitimately a "bag of values" that has only public data. Andrei
Feb 05 2013
next sibling parent Chad Joan <chadjoan gmail.com> writes:
On 02/05/2013 08:31 AM, Andrei Alexandrescu wrote:
 On 2/5/13 3:39 AM, Dmitry Olshansky wrote:
 On 02/05/2013 02:28 AM, Andrei Alexandrescu wrote:> On 2/4/13 2:04 PM,
 Jonathan M Davis wrote:
 We could save a lot of boilerplate code if we can simply make it
 variables and
 property functions guaranteed to be swappable without breaking code.

I think this is quite powerful. The way we can do this is by making properties emulate a subset of actual variables.

This is the primary real-world proble to solve.

The problem with this approach is feature creep - there will always be yet another possible case in which a feature helps some case. We need to put a halt on that. Unprotected, unchecked member variables that can be get and set without any hooks into the enclosing structure are rare. That's not the case we should help and cater for. When that's the case, the entire object is legitimately a "bag of values" that has only public data. Andrei

Rare? What? No. Where is your data? My anecdotal experience is contradictory. I tend to end up with A LOT of things that I'd like to make into public variables but don't due to the risk of breaking encapsulation. The boilerplate can really suck. I would argue that being able to do the /right/ thing in a /convenient/ way is a very important feature. I also do not see how this would lead to more features. If anything, everyone seems to draw the line at address-of: it's a potential feature that we /don't/ want because it's too complicated and introduces harmful semantics. There are a finite amount of features that are needed to make D's property implementation very complete. Throw them all on the table and D will have /the best/ property implementation. If, instead, you are chintzy and give people only some of them, then you will get constant property discussions on the news group and it will /seem/ like you're having to implement an endless stream of features.
Feb 05 2013
prev sibling next sibling parent reply Chad Joan <chadjoan gmail.com> writes:
On 02/05/2013 08:31 AM, Andrei Alexandrescu wrote:
 On 2/5/13 3:39 AM, Dmitry Olshansky wrote:
 On 02/05/2013 02:28 AM, Andrei Alexandrescu wrote:> On 2/4/13 2:04 PM,
 Jonathan M Davis wrote:
 We could save a lot of boilerplate code if we can simply make it
 variables and
 property functions guaranteed to be swappable without breaking code.

I think this is quite powerful. The way we can do this is by making properties emulate a subset of actual variables.

This is the primary real-world proble to solve.

The problem with this approach is feature creep - there will always be yet another possible case in which a feature helps some case. We need to put a halt on that. Unprotected, unchecked member variables that can be get and set without any hooks into the enclosing structure are rare. That's not the case we should help and cater for. When that's the case, the entire object is legitimately a "bag of values" that has only public data. Andrei

Hmmm. This statement that unchecked public members are rare makes me wonder if there is a fundamental difference of background here. Things might be much different if you came from C# or Java instead of C++. I always get this feeling that Walter and Andrei never truly understood how to use properties effectively. That's why I bring up C# and Java: those programmers are very comfortable with properties and know how to use them. Properties are an alien concept in C programming, and probably C++ as well. As a result, I wouldn't be surprised at all of Walter and Andrei haven't really used properties in the same capacity as the typical C# or Java coder, and thus would think things like "unchecked public members are rare". This isn't a bashing post or an ad hominem; I'll try to be informative. In C# properties actually work very well, or at least they did 8 years ago when I used them (ignoring Java: those programmers use properties a lot, but it is a pain). They did not require an enormous amount of features to gain their power, and D shouldn't either. The primary differences are these: (1) C# usually doesn't allow address-of on /anything/. (2) User-defined value types are rare in C#. (3) Unambiguous property declaration syntax. In C# if you try to use a property to return a struct and manipulate a variable off of that, then the compiler will error because C# never implemented property rewrites. It didn't matter because value types are rare. (This may be dated by about 3 years.) I think that those differences are very solvable in D: (1) Disallow address-of on anything dealing with property. No one will miss it; they didn't expect it to exist in the first place. (2) Do semantic rewriting on properties. Once you have semantic rewriting, the value-type-properties problem is SOLVED and never needs to be revisited again. (Disallowing value types in properties would be poor course in a language where user-defined value types are very common.) (3) This is pretty much solved in DIP23 already. In both Java and C# the initial state of properties has always been a huge pain. Just because something /might/ be a property in the future, you always have to make a bunch of boilerplate. Java/C# programmers probably don't believe in "bags of values"; such things are nonsense if you want proper encapsulation! People coming from this background are going to LOVE having a shorthand like "public property int foo;" that removes all of the pain from properly encapsulating public state. Using properties in a properly-constrained system was actually very enjoyable. The above is why I don't see feature creep. The D designers probably don't see where it ends because they've never been to that edge. I worry that I could be totally wrong about Andrei/Walter's experiences in these arenas. I don't assert these notions as truth, but instead as a way of communicating my perceptions. I hope this is informative and not insulting.
Feb 05 2013
parent Chad Joan <chadjoan gmail.com> writes:
On 02/05/2013 10:11 AM, Dicebot wrote:
 On Tuesday, 5 February 2013 at 15:08:55 UTC, Chad Joan wrote:
 Hmmm. This statement that unchecked public members are rare makes me
 wonder if there is a fundamental difference of background here. Things
 might be much different if you came from C# or Java instead of C++.

Well, Andrei background is easy to check: http://en.wikipedia.org/wiki/Andrei_Alexandrescu ;)

I know I know ;) C++ guru, which is why I say what I say. It's still possible that he got a good dosage of property usage somewhere. If that happened and I based an argument off of it, then that would make me an ass. I also wouldn't notice because I don't stalk Andrei ;)
Feb 05 2013
prev sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
05-Feb-2013 17:31, Andrei Alexandrescu пишет:
 On 2/5/13 3:39 AM, Dmitry Olshansky wrote:
 On 02/05/2013 02:28 AM, Andrei Alexandrescu wrote:> On 2/4/13 2:04 PM,
 Jonathan M Davis wrote:
  >> We could save a lot of boilerplate code if we can simply make it
  >> variables and
  >> property functions guaranteed to be swappable without breaking code.
  >
  > I think this is quite powerful. The way we can do this is by making
  > properties emulate a subset of actual variables.
  >

 This is the primary real-world proble to solve.

The problem with this approach is feature creep - there will always be yet another possible case in which a feature helps some case. We need to put a halt on that. Unprotected, unchecked member variables that can be get and set without any hooks into the enclosing structure are rare. That's not the case we should help and cater for. When that's the case, the entire object is legitimately a "bag of values" that has only public data.

Thinking more of it with proper properties it would be doable with a half-decent template mixin. Then it'd better be in Phobos one day as that would make it readily accessible but separate from the language. -- Dmitry Olshansky
Feb 05 2013
prev sibling next sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
05-Feb-2013 23:37, Zach the Mystic пишет:
[snip]
 While I appreciate your responding to my post, I'm a little confused
 which of its points you are addressing here.

Sorry, I posted reply to the wrong post. -- Dmitry Olshansky
Feb 05 2013
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday, February 05, 2013 08:31:46 Andrei Alexandrescu wrote:
 On 2/5/13 3:39 AM, Dmitry Olshansky wrote:
 On 02/05/2013 02:28 AM, Andrei Alexandrescu wrote:> On 2/4/13 2:04 PM,
 
 Jonathan M Davis wrote:
  >> We could save a lot of boilerplate code if we can simply make it
  >> variables and
  >> property functions guaranteed to be swappable without breaking code.
  > 
  > I think this is quite powerful. The way we can do this is by making
  > properties emulate a subset of actual variables.
 
 This is the primary real-world proble to solve.

The problem with this approach is feature creep - there will always be yet another possible case in which a feature helps some case. We need to put a halt on that.

Being able to initially use a public variable and then swap it out later for property functions when refactoring is generally the reason that I've heard for why properties exist in the first place in C#. It's what a number of people around here seem to think is a core feature of properties, and a core feature isn't feature creep. And if property on a variable makes it so that it lowers to getter and setter property functions (rather than leaving it as a public variable with certain restrictions on it), then we don't even have to worry about which features of a variable property functions do and don't emulate and whatever feature creep might appear there. The "variable" would immediately match due to the fact that you'd actually end up with property functions. You just wouldn't have had to do all the boilerplate for it.
 Unprotected, unchecked member variables that can be get and set without
 any hooks into the enclosing structure are rare. That's not the case we
 should help and cater for. When that's the case, the entire object is
 legitimately a "bag of values" that has only public data.

Really? In my experience they're quite common. It's usually the case that not all of the variables on a type have pass-through getters and setters, but it's quite common to have at least a few which do. It's been brought up a number of times in the past that it would be nice to have property on variables be used to avoid the boilerplate code in those cases. I suppose that we could use a mixin to solve that problem, but then you wouldn't get any documentation on it, since you can't document anything that's mixed in. - Jonathan M Davis
Feb 05 2013
prev sibling parent kenji hara <k.hara.pg gmail.com> writes:
--089e013d12c099bbbb04d503cc73
Content-Type: text/plain; charset=UTF-8

2013/2/6 Jonathan M Davis <jmdavisProg gmx.com>
 Being able to initially use a public variable and then swap it out later
 for
 property functions when refactoring is generally the reason that I've heard
 for why properties exist in the first place in C#. It's what a number of
 people
 around here seem to think is a core feature of properties, and a core
 feature
 isn't feature creep. And if  property on a variable makes it so that it
 lowers
 to getter and setter property functions (rather than leaving it as a public
 variable with certain restrictions on it), then we don't even have to worry
 about which features of a variable property functions do and don't emulate
 and
 whatever feature creep might appear there. The "variable" would immediately
 match due to the fact that you'd actually end up with property functions.
 You
 just wouldn't have had to do all the boilerplate for it.

I fully agree with Andrei. I can see that swapping public data field to property function call is not rare, but in almost case, such refactoring also intends to add encapsulation. struct S { // Before swapping int _data; // After swapping private int _data; property int data() { return _data; } property void data(int n) { enforce(n > 0); _data = n; } } S s; int n = s.data; s.data = 1; //int* pdata = &s.data; // changed to disallowed ... it is mostly intended.
 Unprotected, unchecked member variables that can be get and set without
 any hooks into the enclosing structure are rare. That's not the case we
 should help and cater for. When that's the case, the entire object is
 legitimately a "bag of values" that has only public data.

Really? In my experience they're quite common. It's usually the case that not all of the variables on a type have pass-through getters and setters, but it's quite common to have at least a few which do. It's been brought up a number of times in the past that it would be nice to have property on variables be used to avoid the boilerplate code in those cases. I suppose that we could use a mixin to solve that problem, but then you wouldn't get any documentation on it, since you can't document anything that's mixed in.

Wrapping a field data with property function but also allow accessing to it directly through pointer is quite rare. struct S { // After swapping private int _data; property ref int data() { return _data; } // ref return property void data(int n) { enforce(n > 0); _data = n; } } S s; int n = s.data; // call getter s.data = 1; // call setter, enforce n > 0 int* pdata = &s.data; // But, if this is allowed, *pdata = -1; // this is accidentally allowed... Is this really intended? To me, it is just a encapsulation breaking. I'm not sure that it is what you would really expect. Kenji Hara --089e013d12c099bbbb04d503cc73 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">2013= /2/6 Jonathan M Davis <span dir=3D"ltr">&lt;<a href=3D"mailto:jmdavisProg g= mx.com" target=3D"_blank">jmdavisProg gmx.com</a>&gt;</span><blockquote cla= ss=3D"gmail_quote" style=3D"margin-top:0px;margin-right:0px;margin-bottom:0= px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,20= 4);border-left-style:solid;padding-left:1ex"> Being able to initially use a public variable and then swap it out later fo= r<br> property functions when refactoring is generally the reason that I&#39;ve h= eard<br> for why properties exist in the first place in C#. It&#39;s what a number o= f people<br> around here seem to think is a core feature of properties, and a core featu= re<br> isn&#39;t feature creep. And if property on a variable makes it so that it= lowers<br> to getter and setter property functions (rather than leaving it as a public= <br> variable with certain restrictions on it), then we don&#39;t even have to w= orry<br> about which features of a variable property functions do and don&#39;t emul= ate and<br> whatever feature creep might appear there. The &quot;variable&quot; would i= mmediately<br> match due to the fact that you&#39;d actually end up with property function= s. You<br> just wouldn&#39;t have had to do all the boilerplate for it.<br></blockquot= e><div><br></div><div>I fully agree with Andrei.</div><div>I can see that s= wapping public data field to property function call is not rare, but in alm= ost case, such refactoring also intends to add encapsulation.</div> <div><br></div><div>struct S {<br></div><div>=C2=A0 =C2=A0 // Before swappi= ng</div><div>=C2=A0 =C2=A0 int _data;</div><br class=3D""><div>=C2=A0 =C2= =A0 // After swapping</div><div>=C2=A0 =C2=A0 private int _data;</div><div>= =C2=A0 =C2=A0=C2=A0 property=C2=A0int data() { return _data; }</div> <div>=C2=A0 =C2=A0 property void data(int n) { enforce(n &gt; 0); _data = =3D n; }</div><div>}</div><div>S s;</div><div>int n =3D s.data;</div><div><= div>s.data =3D 1;</div>//int* pdata =3D &amp;s.data;</div><div>// changed t= o disallowed=C2=A0... it is mostly intended.</div> <div><br></div><blockquote class=3D"gmail_quote" style=3D"margin-top:0px;ma= rgin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;bo= rder-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> &gt; Unprotected, unchecked member variables that can be get and set withou= t<br> &gt; any hooks into the enclosing structure are rare. That&#39;s not the ca= se we<br> &gt; should help and cater for. When that&#39;s the case, the entire object= is<br> &gt; legitimately a &quot;bag of values&quot; that has only public data.<br=

Really? In my experience they&#39;re quite common. It&#39;s usually the cas= e that not<br> all of the variables on a type have pass-through getters and setters, but i= t&#39;s<br> quite common to have at least a few which do. It&#39;s been brought up a nu= mber of<br> times in the past that it would be nice to have property on variables be u= sed<br> to avoid the boilerplate code in those cases. I suppose that we could use a= <br> mixin to solve that problem, but then you wouldn&#39;t get any documentatio= n on<br> it, since you can&#39;t document anything that&#39;s mixed in.</blockquote>= <div><br></div><div>Wrapping a field data with property function but also a= llow accessing to it directly through pointer is quite rare.</div><div> <br></div><div><div>struct S {<br></div><div>=C2=A0 =C2=A0 // After swappin= g<br></div><div>=C2=A0 =C2=A0 private int _data;</div><div>=C2=A0 =C2=A0=C2= =A0 property ref int data() { return _data; } =C2=A0// ref return</div><div=
=C2=A0 =C2=A0  property void data(int n) { enforce(n &gt; 0); _data =3D n;=

<div>}</div><div>S s;</div><div>int n =3D s.data; =C2=A0// call getter</div=
<div>s.data =3D 1; =C2=A0// call setter, enforce n &gt; 0</div><div>int* p=

=3D -1; =C2=A0// this is accidentally allowed... Is this really intended?</= div> <br class=3D""></div><div>To me, it is just a encapsulation breaking.</div>= <div>I&#39;m not sure that it is what you would really expect.</div><div><b= r></div><div>Kenji Hara</div></div></div></div> --089e013d12c099bbbb04d503cc73--
Feb 05 2013
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday, February 05, 2013 09:34:06 Jacob Carlborg wrote:
 BTW, if it does get lowered to methods, do we want to be able to access
 the instance variable directly?

No, because the variable would presumably end up with a compiler-chosen name which would presumably be implementation-dependent. All that the programmer has defined is the name of the property, not the name of the underlying variable. And for the most part, it wouldn't matter. For structs, inlining would fix the problem, and for classes, if you really want to be able to access the member variable directly for efficiency, you can always declare the property functions explicitly. - Jonathan M Davis
Feb 05 2013
prev sibling next sibling parent "Dicebot" <m.strashun gmail.com> writes:
On Tuesday, 5 February 2013 at 15:08:55 UTC, Chad Joan wrote:
 Hmmm.  This statement that unchecked public members are rare 
 makes me wonder if there is a fundamental difference of 
 background here.  Things might be much different if you came 
 from C# or Java instead of C++.

Well, Andrei background is easy to check: http://en.wikipedia.org/wiki/Andrei_Alexandrescu ;)
Feb 05 2013
prev sibling next sibling parent "Zach the Mystic" <reachBUTMINUSTHISzach gOOGLYmail.com> writes:
On Tuesday, 5 February 2013 at 08:39:15 UTC, Dmitry Olshansky 
wrote:
 On 02/05/2013 02:28 AM, Andrei Alexandrescu wrote:> On 2/4/13 
 2:04 PM, Jonathan M Davis wrote:
 We could save a lot of boilerplate code if we can simply


 variables and
 property functions guaranteed to be swappable without


 I think this is quite powerful. The way we can do this is by

 properties emulate a subset of actual variables.

This is the primary real-world proble to solve. If tackle it right we'd secure a sizable flow of Java converts simply because of this feature alone ;) More seriously I believe it's worth noting that properties can't emulate (in principle) exactly one aspect of variable - taking address as a pointer. Honestly I can't see a way to overcome it without introducing a user-defined way to impose this restriction on a field of a struct/class.

I'm not really sure which part of my article you are addressing here, but allowing 'opAddress' is available as a last resort. Also note that I had proposed 'cast(function)' instead of '&' to get the top-level function, which, unlike '&', can give: 'Error: not castable as a function'
 Then keeping in mind __traits I have the following clause to 
 add to the current proposal:

 Inside of aggregate a field marked with  property indicate is 
 semantically equivalent to compiler wrapping it with trivial 
 getter and setter. Example:
 struct Foo{
  property T x;
 }

 treated  semantically as if:
 T __x; // hidden by compiler
 //templated to have deduced safe, pure, nothrow
  property T x()()inout{ return x; }
  property void x()(T val){ x = val; }

 ---
 Dmitry Olshansky

While I appreciate your responding to my post, I'm a little confused which of its points you are addressing here.
Feb 05 2013
prev sibling next sibling parent "Zach the Mystic" <reachBUTMINUSTHISzach gOOGLYmail.com> writes:
On Tuesday, 5 February 2013 at 19:44:03 UTC, Dmitry Olshansky 
wrote:
 05-Feb-2013 23:37, Zach the Mystic пишет:
 [snip]
 While I appreciate your responding to my post, I'm a little 
 confused
 which of its points you are addressing here.

Sorry, I posted reply to the wrong post.

I hope this doesn't end up being the primary reason people respond to my posts. :-)
Feb 05 2013
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday, February 05, 2013 16:53:51 Steven Schveighoffer wrote:
 On Tue, 05 Feb 2013 16:43:39 -0500, Jonathan M Davis <jmdavisProg gmx.com>
 
 wrote:
 On Tuesday, February 05, 2013 14:05:24 Steven Schveighoffer wrote:
 I think the point about  safe code is moot, aren't pointers disallowed
 in
 safe code anyway?

Goodness no. It's pointer arithmetic which is disallowed. Pointers themselves are perfectly safe as long as you just pass them around or dereference them (which would include calling functions on them). For instance, the result of in on an AA is a pointer to the object, and that's safe.

Well, it would seem setting all kinds of extra rules on ref (in addition to the restrictions we have now), when pointers are more useful even in safe code, will simply result in people using pointers more than ref. I'm not sure that's the right message, but I'm afraid that will be what it is. For example, I have to use pointers for my linked list implementation in dcollections, because ref is forbidden to be used as a class or struct member (my nodes are structs because classes are too heavy). Also, ref is not rebindable, whereas a pointer is.

That may end up happening, but the issues with ref may boil over into some of what happens with pointers - the key issue being escaping references. Using & on a local variable is already considered unsafe, but using ref as a function parameter gets you pretty much exactly the same thing if a local variable is passed to it and ref is returned by the function (I believe that discussions on that are what triggered Andrei's work on the DIP on ref that he brought up). What's really needed is to be able to detect and prevent escaping pointers and references, and there are a lot of difficulties with that. The easy way out tends to mean making a lot of code be system, which could either end up being very limiting or result in a lot more code being system instead of safe. I don't know what exactly Andrei and Walter are cooking up, but SafeD could end up becoming very limited with regards to pointers and refs in order to deal with all of the corner cases. - Jonathan M Davis
Feb 05 2013
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, February 06, 2013 09:56:40 kenji hara wrote:
 I fully agree with Andrei.
 I can see that swapping public data field to property function call is not
 rare, but in almost case, such refactoring also intends to add
 encapsulation.
 
 struct S {
     // Before swapping
     int _data;
 
     // After swapping
     private int _data;
      property int data() { return _data; }
      property void data(int n) { enforce(n > 0); _data = n; }
 }
 S s;
 int n = s.data;
 s.data = 1;
 //int* pdata = &s.data;
 // changed to disallowed ... it is mostly intended.

You misunderstand. We don't _want_ taking the address to work. We _want_ the encapsulation. We just don't want to have to write all of the boilerplate code. The idea is that you want to be able to just make it a variable first, because you don't need to do any extra checks or anything else but get or set the variable. So, having to declare the setters and getters is overkill. The problem is that if you just declare it a variable, then people can take the address of it or pass it by ref - which you don't want. You _want_ the encapsulation up-front. You just don't want to have to bother with all of the boilerplate code required to do it. That's why some of us have suggested making it so that you can mark variables with property. That then either makes it illegal to do anything with it which you couldn't do with a property function (e.g. take its address), or it simply lowers it to the getters and setters, making it so that you _do_ have the property functions in the beginning. You just don't have to write them explicitly. Then later, if refactoring requires that you add additional checks or other operations to the getter and/or setter, then you explicitly declare the property functions. - Jonathan M Davis
Feb 05 2013
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 2/6/13, Jonathan M Davis <jmdavisProg gmx.com> wrote:
 That's why some of us have suggested
 making it so that you can mark variables with  property.

What Jonathan means is this: struct S { int var; // modifiable, can take address } Now suppose later you want to turn var into a property: struct S { property int var(); property void var(int); } This potentially breaks code if the user-code was using a pointer to the public var field in the previous version of your library. So instead we should have the ability to annotate fields with property: struct S { property int var; // modifiable, can *not* take address } There's no run-time cost, but it disallows taking the address of var, and it allows you to introduce property functions in the future without breaking user-code.
Feb 05 2013
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday, February 05, 2013 21:22:34 Andrei Alexandrescu wrote:
 Note that most people tend to vastly overestimate their few first
 language designs, and that there are much more people who think are good
 at language design than those actually are. (Note I'm only passing
 opinion on what I saw; You may as well be an awesome language designer,
 but the spark is not visible in this particular proposal.) Though I've
 had an idea or two that stuck, I confess without any false modesty that
 I don't consider myself to be a noted language designer.

Another thing to consider is that it's fairly common for people to come up with ideas that seem like very good ideas and seem very solid but which ultimately end up falling apart due to corner cases. And we're already suffering from features which are partially implemented and not necessarily fully thought through, even if they're solid in their basics. As far as changing D goes, we're far enough along in the process that anything which would break backwards compatibility needs a really compelling case for it happen. We're trying to stabilize the language, which _does_ require breaking code in some cases, but we'd like to minimize that. Backwards compatible feature requests are more likely to make it in, but even then, they need very compelling use cases and are likely to be held back by all of the work that _needs_ to be done (new features may be nice, but they're unlikely to be necessary at this point). We're past the point where we're freely mucking with the language to try out new ideas but instead are trying to polish what we have. But as Andrei says, there's tons of room for stuff to be done on the library front and plenty of work to do helping out with stuff like documentation and articles. So, there's tons for people to do to help out, and there's certainly plenty of innovation that could be done with regards to how stuff is handled in new stuff in the standard library. It's just the lanugage itself where we're limiting what innovation we put into it at this point. - Jonathan M Davis
Feb 05 2013
prev sibling next sibling parent "Zach the Mystic" <reachBUTMINUSTHISzach gOOGLYmail.com> writes:
On Wednesday, 6 February 2013 at 02:36:13 UTC, Jonathan M Davis 
wrote:
 On Tuesday, February 05, 2013 21:22:34 Andrei Alexandrescu 
 wrote:
 Note that most people tend to vastly overestimate their few 
 first
 language designs, and that there are much more people who 
 think are good
 at language design than those actually are. (Note I'm only 
 passing
 opinion on what I saw; You may as well be an awesome language 
 designer,
 but the spark is not visible in this particular proposal.) 
 Though I've
 had an idea or two that stuck, I confess without any false 
 modesty that
 I don't consider myself to be a noted language designer.

Another thing to consider is that it's fairly common for people to come up with ideas that seem like very good ideas and seem very solid but which ultimately end up falling apart due to corner cases. And we're already suffering from features which are partially implemented and not necessarily fully thought through, even if they're solid in their basics. As far as changing D goes, we're far enough along in the process that anything which would break backwards compatibility needs a really compelling case for it happen. We're trying to stabilize the language, which _does_ require breaking code in some cases, but we'd like to minimize that. Backwards compatible feature requests are more likely to make it in, but even then, they need very compelling use cases and are likely to be held back by all of the work that _needs_ to be done (new features may be nice, but they're unlikely to be necessary at this point). We're past the point where we're freely mucking with the language to try out new ideas but instead are trying to polish what we have. But as Andrei says, there's tons of room for stuff to be done on the library front and plenty of work to do helping out with stuff like documentation and articles. So, there's tons for people to do to help out, and there's certainly plenty of innovation that could be done with regards to how stuff is handled in new stuff in the standard library. It's just the lanugage itself where we're limiting what innovation we put into it at this point. - Jonathan M Davis

Well, Jonathan M Davis, I had posted a second response to Andrei's first comment before reading either his second one or yours. But I think I pretty much explained my position, for better or worse. It's not so much not having the feature included so much as wanting to know why because despite Andrei's clear intelligence and good intentions, I felt pretty strongly that I had put onto the table something very good.
Feb 05 2013
prev sibling next sibling parent Robert <jfanatiker gmx.at> writes:
It is not feature creep, it is properties done right. If not done this
way, than honestly I don't know what properties are good for any way. We
could use set/get methods just as well.

If properties done right are feature creep, than properties per se are
feature creep, which is debatable. But if we keep them, we should do
them right.

Maybe you can elaborate what properties are good for, if not for
avoiding trivial set/get methods? -> Please really do that, because I am
having a hard time understanding your reasoning.



On Tue, 2013-02-05 at 08:31 -0500, Andrei Alexandrescu wrote:
 The problem with this approach is feature creep - there will always
 be 
 yet another possible case in which a feature helps some case. We need
 to 
 put a halt on that.

Feb 06 2013
prev sibling next sibling parent "Tove" <tove fransson.se> writes:
On Wednesday, 6 February 2013 at 01:40:37 UTC, Andrej Mitrovic 
wrote:
 On 2/6/13, Jonathan M Davis <jmdavisProg gmx.com> wrote:
 That's why some of us have suggested
 making it so that you can mark variables with  property.

What Jonathan means is this: struct S { int var; // modifiable, can take address } Now suppose later you want to turn var into a property: struct S { property int var(); property void var(int); } This potentially breaks code if the user-code was using a pointer to the public var field in the previous version of your library. So instead we should have the ability to annotate fields with property: struct S { property int var; // modifiable, can *not* take address } There's no run-time cost, but it disallows taking the address of var, and it allows you to introduce property functions in the future without breaking user-code.

It is also possible to first start with setters/getters and then switch to a public field(!) Which leads to the conclusion, in order for the property abstraction to be complete, address taking of *anything* annotated with property should either NOT be allowed... property int var(); // can *not* take address property void var(int); // can *not* take address property int var; // can *not* take address ... or we have to guarantee that the type remains unchanged... which is problematic due to different types of the getter and setter, which would force one to always specify the expected type rather than relying on auto. property int var; int delegate() d_get = &var; void delegate(int) d_set = &var;
Feb 10 2013
prev sibling parent Martin Nowak <code dawg.eu> writes:
On 02/03/2013 09:16 AM, Andrei Alexandrescu wrote:
 Walter and I have had a discussion on how to finalize properties.

 http://wiki.dlang.org/DIP23

accordingly. If the discussion has settled can we bless one of the 3 property DIPs with being approved? Otherwise what work has to be done to get there? http://wiki.dlang.org/DIP21 http://wiki.dlang.org/DIP23 http://wiki.dlang.org/DIP24
Dec 13 2013