D Language Foundation November 2025 Monthly Meeting Summary

[Meta]

On Wednesday, 6 May 2026 at 10:44:18 UTC, Dennis wrote:
> On Monday, 4 May 2026 at 15:41:46 UTC, Kagamin wrote:
>> If explicit this is a parser change, what difference does it 
>> make? Just for AST to be a uniform array of arguments?
>
> The goal is to make the syntax clearer, because currently it 
> often looks like the attributes apply to the return value 
> instead of `this`.
>
> ```D
> struct S
> {
>     int x;
>     int* y;
>
>     const int f() => this.x; // returns const(int)?
>     scope int* g() => null; // returns a scoped pointer?
>     ref int h() return => this.x; // 'return' what?
> }
> ```
>
> With explicit this, the code becomes:
>
> ```D
> struct S
> {
>     int x;
>     int* y;
>
>     int f(const ref S this) => this.x;
>     int* g(scope ref S this) => null;
>     ref int h(return ref S this) => this.x;
> }
> ```

We could also borrow from Rust and clean up those signatures a 
bit:

```d
int f(const this) => this.x;
```

In a signature, `this` is equivalent to writing `ref S this` 
(maybe scope and return could be inferred too?).

Also, in my wildest dreams, this would allow us to write methods 
separately from the class/struct:

```d
struct S { ... }

// return/scope inferred, S must be explicitly
// specified because it is defined outside the
// struct
ref int h(this S) => this.x;
```

Is there any real benefit to doing this over UFCS? There's one 
very specific, highly requested feature it enables: operator 
overloading via standalone functions.

``|
import raylib: Vector2;

Vector2 opBinary(string op: "+")(this Vector2, Vector2 rhs) => 
Vector2(this.x + rhs.x, this.y + rhs.y);
```

This is obviously very useful in regular D code, but now with 
ImportC, we can actually *enhance* C libraries with modern 
functionality like custom operators, without having to do any 
wrapping or anything. Just import the C library and define 
whatever operators you want *outside* the native C types.