On Tue, 05 Feb 2013 20:34:11 -0500, Timon Gehr <timon.g...@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.g...@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-@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
