November 19, 2012
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
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
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
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
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
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
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
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
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
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 7 8 9 10 11 12
Top | Discussion index | About this forum | D home