Future of memory management in D

[Alexandru Ermicioi]

On Friday, 19 November 2021 at 11:14:46 UTC, Dom DiSc wrote:
> On Friday, 19 November 2021 at 10:21:35 UTC, Max Samukha wrote:
>> On Thursday, 18 November 2021 at 19:32:36 UTC, Atila Neves 
>> wrote:
>>
>>>
>>> Works with `ref prop() { return _fld; }`.
>>
>> The whole point of properties is to hide private state. 
>> Exposing a private member for direct mutation is generally a 
>> bad idea.
>
> Exactly.
> What I would expect from a "real" property is that
>
> prop += 5;
>
> is automatically lowered to
>
> prop(prop() + 5); // function style
>
> or direct
>
> auto tmp = prop; tmp += 5; prop = tmp;
>
> or whatever - but would work only if there is both a getter 
> _and_ a setter.
> And if only one of the two is implemented, a fitting error 
> message should be emitted like
> "no setter for prop available" or "no getter for prop 
> available".
>
> It should NEVER EVER set a property through the getter!!!

If you want to hide the field from public use, then just don't 
expect it to behave like a public field.

If you want to have += and other operators that affect the 
private field, you could return a wrapper that does this and 
saves the field.

This behavior of @properties should just be explained a lot 
better, and that's it.

> ref prop() { ... } is a very bad anti-pattern.

Why is it bad?

Best regards,
Alexandru.