DIP23 Counter Proposal

[Steven Schveighoffer]

On Tue, 05 Feb 2013 20:34:11 -0500, Timon Gehr <timon.gehr at gmx.ch> wrote:

> On 02/06/2013 02:20 AM, Steven Schveighoffer wrote:
>> On Tue, 05 Feb 2013 19:39:55 -0500, Timon Gehr <timon.gehr at gmx.ch>  
>> wrote:
>>
>>> As my posts in the DIP23 thread have been left unanswered, I have
>>> prepared a counter proposal for DIP23 during the last hour.
>>>
>>> Everything DIP23 addresses is specified in the two short sub-sections
>>> "Optional parens" and "@property: basic design".
>>>
>>> Those in favour of what was called "semantic rewrites" in the DIP23
>>> thread should probably read on further.
>>>
>>> All parts of this proposal are independent of DIP24 (which Andrei is
>>> preparing).
>>>
>>> http://wiki.dlang.org/DIP23_Counter_Proposal
>>>
>>> There are almost no examples yet, but in case it is not clear how some
>>> case would be handled, feel free to ask.
>>>
>>>
>>> (Also feel free to fix the formatting.)
>>
>> Has my vote.  For what it's worth :)
>>
>
> Thanks! :)
>
> The full proposal or just the basic design part? (I think the full  
> "semantic rewrite" idea may have some issues regarding excessive  
> postblit/destruction, so I am not entirely sure if it is a good idea,  
> but it was requested.)

All that I really care about is the specification of what @property does.

The semantic rewrite stuff is something I don't feel strongly either way.   
It would be nice, but at the same time, it doesn't feel necessary to me.   
One can always simply avoid it by not using the operators on properties.

>> One thing that should be clarified, you should explicitly say "member
>> function (static or instance)" instead of just member function.  The
>> "optional this" kind of takes care of it, but you have to read it
>> carefully to get that.  I think it should be more straightforward.
>>
>> -Steve
>
> Done. Another thing that was not specified yet was what the compiler is  
> supposed to do when it encounters overloads where some are @property and  
> some are not. (I have added "It is illegal to overload  
> @property-qualified functions against non- at property-qualified  
> functions.")

Sounds correct.

I was reexamining the portion on the __traits rewrite.  I think it is  
interesting how you have simply made @property rewrite to  
__traits(propertyAccessors, x).

There are a couple of clarifications I was curious about:

1. Does &prop work?  If so, what does it do?
1a. if &prop doesn't work, does &__traits(propertyAccessors, prop) work  
(and give you the delegate to the property function overload set)?  I can  
only imagine this is the reason you have the rewrite to a __traits call...
2. Inside the rules for when you do prop = exp, you specify that if the  
return is void, the expression is rewritten as  
(__traits(propertyAccessors, prop)(exp), prop).  I see some issues with  
this:
    2a. If you are NOT using the expression beyond the assignment, why call  
the accessor again?
    2b. This would preclude write-only properties (as the second element of  
the comma expression is invalid).  Is that intentional?
    2c. What about ref returning properties?  In those cases, the rewrite  
should be __traits(propertyAccessors, prop)() = exp;

-Steve