DIP1000: Walter's proposal to resolve ambiguity of ref-return-scope parameters

[ShadoLight]

On Friday, 26 November 2021 at 02:03:41 UTC, Paul Backus wrote:
> On Friday, 26 November 2021 at 00:31:19 UTC, Dennis wrote:
>> On Friday, 26 November 2021 at 00:26:35 UTC, Paul Backus wrote:
>>> More seriously: this is exactly the kind of obscure "gotcha" 
>>> that makes C++ so beginner-hostile, and IMO it is worth going 
>>> to considerable lengths (including breaking changes) to avoid 
>>> it.
>>
>> Allowing breaking changes, what syntax do you think makes 
>> intuitive sense?
>
> * Allow `return ref` and `return scope`.
> * Forbid the `return` storage class from appearing in any other 
> context.
>

As an occasional D(hobby) user but long-time lurker on this 
forum... it has been noticeable t me that D is gradually 
approaching C++ in complexity!

Something like this, as you hinted,...

> ```d
> struct S {
>     ref int opIndex(return ref scope this) {
>         // ...
>     }
> }
> ```

... are inevitably going to be confusing to newbies.

Personally what I think would help is to somehow 'link' those 
keywords together that is a single entity i.e. in your example 
`return ref` and `return scope` becomes `return-ref` and 
`return-scope`.

Or anything similar that achieves the same, like `return_ref` and 
`return_scope`, as long as it is clear that they are not separate 
keywords in this context. Or whatever makes the most sense from a 
lexing/parsing POV.

It will at least read easier and be easier to explain (like `ref 
int opIndex(return-ref scope this)` is allowed, but not `ref int 
opIndex(ref-return scope this)`, compared to `ref int 
opIndex(return ref scope this)` is allowed, but not `ref int 
opIndex(ref return scope this)` .

I realize this in effect introduces new keywords and is equally a 
breaking change, but in my opinion this is preferable to the 
explosion in parameter attributes we are seeing.