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

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.

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.

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.

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

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;

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

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.

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?

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