Editions Ideas

[Vladimir Panteleev]

On Friday, 26 December 2025 at 00:57:52 UTC, Richard (Rikki) 
Andrew Cattermole wrote:
> They do yes and that is the exact problem with @property.
>
> It does not mean what we have it doing.
>
> When people hear @property they think C#'s property feature. It 
> has come up consistently over a very long period of time and 
> nothing has been done to progress it.

I don't see the problem.

I stand by what I said

>> Just fix `@property`, don't invent more features that are 
>> kinda like other features and you have to know which one to 
>> use in which situation / language version
>
> Its not a new feature, its a renamed feature that is now being 
> completed using simpler rules than what was described in DIP24 
> to archive the same thing.

I can see what you mean but surely you realize that this is not 
how the rest of the world will see it. You say `@namedexpr`, the 
world says "Huh?"

This will not lead to any wins

> As per what Timon wants:

I don't see how you got to that conclusion

> " 4. OpAssign position: prop op= exp
>  -- In this case, the whole expression is rewritten to {auto 
> val=prop; val op= exp; return prop=val; }(), where 'val' is 
> choosen such that it does not occur free in exp or prop."

LGTM

> If you use the setter you will need more temporaries if the 
> type changes,

So don't allow the type to change?

> or make it inaccessible if it returns void.

I think that is perfectly fine? void-returning setters should be 
discouraged for copyable types, but are exactly correct for 
non-copyable types