Explicit this for methods

[Quirin Schroll]

On Saturday, 27 July 2024 at 00:08:19 UTC, Paul Backus wrote:
> On Tuesday, 23 July 2024 at 11:07:54 UTC, vit wrote:
>> Explicit `this` allow manipulating of `this` type without 
>> interacting with function attributes and without need to 
>> create template function or string mixin-s.
>>
>> Syntax:
>> - explicit `this` must be first parameter of non-static method
>> - name is not identifier but keyword `this`.
>
> Agree with all of this.
>
>> - explicit `this` doesn't support all parameter attributes 
>> like `ref`, `out`, `in` and `lazy`, but attributes like 
>> `scope` and `return` can be supported.
>
> To be more precise, any attribute or storage class that is 
> currently [specified as applying to the `this` parameter when 
> used on a method][1] should be supported.
>
> Personally, I would also **require** the `this` parameter of a 
> `struct` method to be declared as `ref`, since [`this` is 
> always passed by reference][2]. (An explicit `ref` is not 
> needed for `class` methods, because classes are reference 
> types.)
>
> [1]: https://dlang.org/spec/class.html#member-functions
> [2]: https://dlang.org/spec/expression.html#this
>
>
>> - `this template parameter` can by replaced with explicit 
>> `this` + normal template parameter.
>
> I'm not sure allowing the user to specify the type of the 
> `this` parameter is a great idea. Everything else in this 
> proposal is just a new syntax for existing behavior; this would 
> add entirely new behavior to the language.

But `ref` means that it must me an lvalue.

A decision must be made if this proposal wants an alternative 
syntax for non-static member functions or if it wants to add 
something to the language that isn't expressible in the current 
state.

My argument is that adding explicit `this` has a low chance of 
adoption if it adds nothing that can't already be expressed. It's 
best rationale, … I have it spelled out in quite some detail in 
my previous post – not gonna repeat that.
If we were discussing *how* to add non-static member functions, 
that proposal would be a good contender against implicit this, 
but we already have implicit this, so if this isn't going to add 
something, it has little chance of getting through. It's not good 
for a language if there are two competing ways of doing things 
which are roughly equal and low in complexity. That can lead to 
style wars. It would be a completely different story if this were 
to propose deprecating implicit this.