• Kagamin (28/28) Sep 01 It can be useful not only for attributes, but also for
• Kagamin (12/12) Sep 01 The first method isn't very meaningful
• Paul Backus (10/38) Sep 01 I think the best approach is to start by *only* supporting what's
• Basile B. (9/12) Sep 09 I'd like to mention

Kagamin <spam here.lot> writes:

It can be useful not only for attributes, but also for 
optimizations:
```
struct A
{
	int a;
	//by value, mutable
	void byval(this, int b)
	{
		a=1; //implicitly accessible
	}

	//by ref, mutable
	void byref(ref this, int b)
	{
		a=b; //change is visible
	}

	//default, by ref, mutable
	void bydefault(int b)
	{
		a=b; //change is visible
	}

	//`in` optimizations for small structs
	A opBinary(string op:"+")(in this, int b)
	{
		return A(a+b);
	}
}
```

Kagamin <spam here.lot> writes:

The first method isn't very meaningful
```
struct A
{
	int a;
	//by value, mutable
	int byval(this)
	{
		return a; //implicitly accessible
	}
}
```

Paul Backus <snarwin gmail.com> writes:

On Tuesday, 1 September 2026 at 20:13:43 UTC, Kagamin wrote:
 It can be useful not only for attributes, but also for 
 optimizations:
 ```
 struct A
 {
 	int a;
 	//by value, mutable
 	void byval(this, int b)
 	{
 		a=1; //implicitly accessible
 	}

 	//by ref, mutable
 	void byref(ref this, int b)
 	{
 		a=b; //change is visible
 	}

 	//default, by ref, mutable
 	void bydefault(int b)
 	{
 		a=b; //change is visible
 	}

 	//`in` optimizations for small structs
 	A opBinary(string op:"+")(in this, int b)
 	{
 		return A(a+b);
 	}
 }
 ```

I think the best approach is to start by *only* supporting what's 
allowed by the existing syntax (so, `ref this` for structs and 
non-`ref` `this` for classes). Once we have that in the language, 
we can discuss separately whether to add support for `in`, 
by-value struct methods, and so forth.

The reason I suggest this is any change to how the `this` 
parameter is passed will have both semantic and ABI implications, 
and I would rather not see the entire proposal get delayed or 
rejected just because of a few tricky details.

Basile B. <b2.temp gmx.com> writes:

On Tuesday, 1 September 2026 at 20:13:43 UTC, Kagamin wrote:
 It can be useful not only for attributes, but also for 
 optimizations:
 [...]

I'd like to mention

- https://bugzilla-archive.dlang.org/bugs/3720/
- https://bugzilla-archive.dlang.org/bugs/8114/

this implies that the type of member function is very well known 
to be wrong but thanks to delegates there is actually no problem 
with that. Adding explicit this would be delicate because you'll 
have to deal with both implicit and explicit versions of the 
function type, i.e think to the IsExpression.