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.

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.

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.

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.

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

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. :)

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

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

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

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.