View mode: basic / threaded / horizontal-split · Log in · Help
November 19, 2012
Re: @property needed or not needed?
So is it official? We keep the d1 syntax for none property 
functions? Even the assignment?

So for the dynamic stuff opDispatch only (for properties and 
methods)? The ()() syntax remains for the dynamic delegate 
properties.
November 19, 2012
Re: @property needed or not needed?
On Monday, November 19, 2012 12:31:02 sclytrack wrote:
> So is it official? We keep the d1 syntax for none property
> functions? Even the assignment?

No. It's not official. No decision has been made. For the moment, nothing has 
changed about @property. It may very well change, but nothing has happened but 
some discussion on the matter, and while Andrei is suggesting may very well be 
what happens, not everyone agrees with his assessment. We'll have to wait and 
see.

- Jonathan M Davis
November 19, 2012
Re: @property needed or not needed?
On Monday, 19 November 2012 at 06:52:11 UTC, Andrei Alexandrescu 
wrote:
> We need to redesign it to such that the keyword '@property' is 
> only required in cases that otherwise would be ambiguous 
> (functions returning functions).

There's a fairly easy way to do this, thanks to the @property 
word:

1) Any function without @property remains exactly the same as it 
is now. Parens are *not* required on them.

2) Any function with @property is rewritten into a call 
immediately. Therefore, putting () is naturally an error or 
delegate call because of the return value.

@property int foo() {}

foo; // rewritten into foo() transparently
foo(); // since foo is already foo(), this becomes foo()() - an 
error because you cannot call an int like a function



The only potential for code breakage here is on stuff marked 
@property, which if you have been marking it on semantic 
properties already (NOT on places where you just wanted appease 
the -property switch's idiotic rules), should be fine.

If in doubt, leave @property off. That leaves things exactly as 
they are.
November 19, 2012
Re: @property needed or not needed?
On 11/19/12 4:01 AM, monarch_dodra wrote:
> I kind of agree with Jonathan here. @property really shines when you
> want to "add" an attribute to a struct.

I kind of agree with him, too, but it would be a mistake to not reckon a 
change in dynamics. UFCS makes all those extra parens just awkward, and 
people will vote with their code regardless whether some particular 
viewpoint from some particular angle considers the approach backwards.

Andrei
November 19, 2012
Re: @property needed or not needed?
On 11/19/12 8:18 AM, Adam D. Ruppe wrote:
> On Monday, 19 November 2012 at 06:52:11 UTC, Andrei Alexandrescu wrote:
>> We need to redesign it to such that the keyword '@property' is only
>> required in cases that otherwise would be ambiguous (functions
>> returning functions).
>
> There's a fairly easy way to do this, thanks to the @property word:
[snip]

Would you please start a DIP with a paste of this idea?

Andrei
November 19, 2012
Re: @property needed or not needed?
On Monday, 19 November 2012 at 14:58:29 UTC, Andrei Alexandrescu 
wrote:
> On 11/19/12 4:01 AM, monarch_dodra wrote:
>> I kind of agree with Jonathan here. @property really shines 
>> when you
>> want to "add" an attribute to a struct.
>
> I kind of agree with him, too, but it would be a mistake to not 
> reckon a change in dynamics. UFCS makes all those extra parens 
> just awkward, and people will vote with their code regardless 
> whether some particular viewpoint from some particular angle 
> considers the approach backwards.
>
> Andrei

One of the things that we may want to take into account, is that 
-property prevents any existing function from migrating to/from 
property. For example, if we want to make "retro" a property, we 
can't without breaking any and all UFCS usage of retro.
November 19, 2012
Re: @property needed or not needed?
On 2012-11-19 06:52:11 +0000, Andrei Alexandrescu 
<SeeWebsiteForEmail@erdani.org> said:

> On 11/19/12 1:02 AM, Rob T wrote:
>> So what's up with @property?
> 
> It's a mistake on top of another. We need to redesign it to such that 
> the keyword '@property' is only required in cases that otherwise would 
> be ambiguous (functions returning functions).

…or functions returning a type with an opCall.

What about template functions with a parametrized return type that will 
sometime be ambiguous and sometime not depending on the template 
parameters?

-- 
Michel Fortin
michel.fortin@michelf.ca
http://michelf.ca/
November 19, 2012
Re: @property needed or not needed?
11/19/2012 7:18 PM, monarch_dodra пишет:
> On Monday, 19 November 2012 at 14:58:29 UTC, Andrei Alexandrescu wrote:
>> On 11/19/12 4:01 AM, monarch_dodra wrote:
>>> I kind of agree with Jonathan here. @property really shines when you
>>> want to "add" an attribute to a struct.
>>
>> I kind of agree with him, too, but it would be a mistake to not reckon
>> a change in dynamics. UFCS makes all those extra parens just awkward,
>> and people will vote with their code regardless whether some
>> particular viewpoint from some particular angle considers the approach
>> backwards.
>>
>> Andrei
>
> One of the things that we may want to take into account, is that
> -property prevents any existing function from migrating to/from
> property. For example, if we want to make "retro" a property, we can't
> without breaking any and all UFCS usage of retro.
>

The major problem about @property enforcement as it stands is that it 
breaks the duality of things like retro:
a.retro
vs
retro(a)

Both should be allowed as it's a matter of taste that shouldn't be 
enforced. A lot of new code uses a.retro and a lot of older code uses 
retro(a).

If retro is property then only the first one compiles
If retro is a function then only the second one compiles.

Which obviously means @property has to be reconsidered.

-- 
Dmitry Olshansky
November 19, 2012
Re: @property needed or not needed?
On Monday, 19 November 2012 at 17:42:28 UTC, Dmitry Olshansky 
wrote:
> 11/19/2012 7:18 PM, monarch_dodra пишет:
>> On Monday, 19 November 2012 at 14:58:29 UTC, Andrei 
>> Alexandrescu wrote:
>>> On 11/19/12 4:01 AM, monarch_dodra wrote:
>>>> I kind of agree with Jonathan here. @property really shines 
>>>> when you
>>>> want to "add" an attribute to a struct.
>>>
>>> I kind of agree with him, too, but it would be a mistake to 
>>> not reckon
>>> a change in dynamics. UFCS makes all those extra parens just 
>>> awkward,
>>> and people will vote with their code regardless whether some
>>> particular viewpoint from some particular angle considers the 
>>> approach
>>> backwards.
>>>
>>> Andrei
>>
>> One of the things that we may want to take into account, is 
>> that
>> -property prevents any existing function from migrating to/from
>> property. For example, if we want to make "retro" a property, 
>> we can't
>> without breaking any and all UFCS usage of retro.
>>
>
> The major problem about @property enforcement as it stands is 
> that it breaks the duality of things like retro:
> a.retro
> vs
> retro(a)
>
> Both should be allowed as it's a matter of taste that shouldn't 
> be enforced. A lot of new code uses a.retro and a lot of older 
> code uses retro(a).
>
> If retro is property then only the first one compiles
> If retro is a function then only the second one compiles.
>
> Which obviously means @property has to be reconsidered.

Hum... Perhaps you meant:
a.retro
vs
a.retro()
???

Because "retro(a)" works regardless of the property.
November 19, 2012
Re: @property needed or not needed?
On Monday, 19 November 2012 at 15:01:36 UTC, Andrei Alexandrescu 
wrote:
> Would you please start a DIP with a paste of this idea?

here it is:
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP21

I tried to implement this a while ago and hit some pain after 
some early success. The pain was trying to get assignments to 
work without breaking other cases like returning ref.

My plan was to make any reference to a @property change to a 
CallExp or whatever. But if you do that and it is on the left 
hand side of an assignment, you do the wrong thing.

foo = foo + 1;

should generally become:

foo(foo() + 1);

but if there isn't a setter, we should leave it as foo() = foo() 
+ 1; and finding the setter is a bit of a pain. Then, of course, 
we ideally want foo += 1 to work too..

Maybe someone who knows the compiler better than me will make it 
look easy though.
1 2 3 4 5 6
Top | Discussion index | About this forum | D home