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

[WebFreak001]

On Thursday, 25 November 2021 at 19:35:53 UTC, Paul Backus wrote:
> On Thursday, 25 November 2021 at 16:11:39 UTC, Dennis wrote:
>> On Thursday, 25 November 2021 at 15:57:13 UTC, WebFreak001 
>> wrote:
>>> with `return ref` and `return scope`, will there also be a 
>>> `return this` for the case like the opIndex functions 
>>> returning something with the lifetime of the containing 
>>> struct? I don't quite get how it's otherwise fixing it.
>>
>> `return this` in struct member functions is `return ref`. 
>> Walter proposes in the bugzilla issue to allow `ref` after the 
>> parameter list:
>>
>> ```D
>> struct S {
>>     ref int opIndex() return ref scope {
>>
>>     }
>> }
>> ```
>
> Seems like we may be reaching the point where it's worth it to 
> make the `this` parameter explicit, like it is in Python and 
> Rust:
>
> ```d
> struct S {
>     ref int opIndex(return ref scope this) {
>         // ...
>     }
> }
> ```

I really like this suggestion! It's a lot cleaner than having all 
the attributes after the function (which sometimes means the same 
as before the function)

Would be a lot easier to understand to people who have never seen 
attributes after the function before. (Like people coming from 
C#, Java, Python)

However it would be inconsistent to keep the other attributes 
after the function as well and I doubt anyone would prefer

```d
int width(const @property this) { ... }
                 // doesn't really make sense imo, would need to 
at least keep the @ attributes (and pure, nothrow) after the 
function
```

over

```d
int width() const @property { ... }
```

What is nice that stuff like const/inout would make more sense 
(writing it before the function meaning the same as after the 
function unless there are parentheses would be no more)

Would think you could write it like this:

```d
inout int[] getSomething(inout return this, int offset) @property 
{ ... }
```