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.)

On Tue, 05 Feb 2013 19:39:55 -0500, Timon Gehr <timon.gehr@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 :)

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

On 02/06/2013 02:20 AM, Steven Schveighoffer wrote:
> On Tue, 05 Feb 2013 19:39:55 -0500, Timon Gehr <timon.gehr@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.)

> 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.")

On 2/5/13 7:39 PM, Timon Gehr 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.)

I salute the appeal to rigor and comprehensiveness.

This is not a contest or a competition so I allowed myself to make this its own DIP: http://wiki.dlang.org/DIP24


Andrei

On Wednesday, 6 February 2013 at 01:37:32 UTC, Andrei Alexandrescu wrote:
> This is not a contest or a competition so I allowed myself to make this its own DIP: http://wiki.dlang.org/DIP24

Converted the old page into a redirect and added it to the index (Timon, I hope you don't mind).

David

On 02/06/2013 02:37 AM, Andrei Alexandrescu wrote:
> On 2/5/13 7:39 PM, Timon Gehr 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.)
>
> I salute the appeal to rigor and comprehensiveness.
>

Thanks!

> This is not a contest or a competition so I allowed myself to make this
> its own DIP: http://wiki.dlang.org/DIP24
>

Makes sense. (As the two proposals agree on a meaning for most expressions I was not sure if that was enough for a full-blown DIP.)

On 02/06/2013 02:42 AM, David Nadlinger wrote:
> On Wednesday, 6 February 2013 at 01:37:32 UTC, Andrei Alexandrescu wrote:
>> This is not a contest or a competition so I allowed myself to make
>> this its own DIP: http://wiki.dlang.org/DIP24
>
> Converted the old page into a redirect and added it to the index (Timon,
> I hope you don't mind).
>
> David

Perfect, thanks!

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

On 02/06/2013 03:45 AM, Steven Schveighoffer wrote:
> ...
>
> There are a couple of clarifications I was curious about:
>
> 1. Does &prop work?  If so, what does it do?

It attempts to take the address of the result of the getter call.

> 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...

Yes, exactly, &__traits(propertyAccessors, prop) gives delegate/function pointer access to the @property function overload set.

> 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?

Not really. Good catch. Refined.

>     2c. What about ref returning properties?  In those cases, the
> rewrite should be __traits(propertyAccessors, prop)() = exp;
>

I had forgotten to specify this. (The setter rewrite should be performed only if it makes sense.)

I also had forgotten to treat alias declarations and template alias parameters. This is fixed now as well.

On Wednesday, 6 February 2013 at 00:39:55 UTC, Timon Gehr 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.
>

I have to spend more time on the @property part.

For the optional () part, I want to raise concern about point 2 (the others make sense).

In all other points, foo is either a call to function foo or the function foo itself. In point 2, we introduce a 3rd meaning of foo, identical to weird stuff we have in C/C++ (as we obviously aren't taking the address either of the function or of its result when executed). This object is an error of C and C++ we must get rid of.

Point 1, 4 and 5 make sense.

Point 3 is nonsensial if we want to really be rigorous as :
returnType foo(TemplateArgs)(args) {}

is equivalent to

template foo(TemplateArgs) {
    returnType foo(args) {}
}

In this case foo is a template, not a function. foo!args is the function hen eponymous trick is used.