Editions Ideas

[Richard (Rikki) Andrew Cattermole]

On 26/12/2025 1:48 PM, Vladimir Panteleev wrote:
> On Thursday, 25 December 2025 at 22:33:28 UTC, Richard (Rikki) Andrew 
> Cattermole wrote:
>> Rename it to ``@namedexpr``
> 
> No thanks
> 
> One of the reason people mentioned they were turned off by D is weird 
> naming decisions like using `enum` for manifest constants. Good names 
> matter; familiar names are good, even if semantics are slightly different

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.

> 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.

>>         - If a gotten from value has been mutated and it is not by-ref 
>> (i.e. mutable function call on it), call the modify-in-place setter. 
>> In the form of: ``void func(ref T val)``
> 
> Why?
> 
> AFAIK `someDynamicArray.length++` works fine by get+set and the sky 
> didn't fall
> 
> What other language does it this way?
As per what Timon wants:

" 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."

https://wiki.dlang.org/DIP24

Doing that with a by-value setter is going to have the problems I 
explained, it'll need to be the in place kind instead which takes it by-ref.