D Properties when?

[Hipreme]

On Thursday, 14 December 2023 at 19:49:35 UTC, ryuukk_ wrote:
> On Thursday, 14 December 2023 at 18:08:52 UTC, Hipreme wrote:
>> This is no news in the programming world, yet, we still don't 
>> have it.
>>
>> This is very important for I can define a good API in which I 
>> could increase my engine performance.
>> With that, I could implement fields with dirty flags and not 
>> make the API looks dirty (no pun intended).
>>
>>
>> Think of an object with X and Y position. I want to be able to 
>> when its value changes, it sets a dirty flag to true. The 
>> problem is that I'm unable to do `X+= 50` after that. I need 
>> to do `X = X + 50`, this is not news but still makes the API 
>> inconsistent and more verbose.
>> I don't care how this is implemented, I only want this some 
>> day to not make it look ugly.
>
> a function is a function, a field is a field
>
> mixing the two is a bad idea, you think you get a field, but 
> under the food it does weird stuff
>
> `properties` is nitpicking, making things more confusing that 
> they should be
>
> it's the same nitpicking as:
>
> ```D
> int my_dumb_function() => 1 + 1;
> ```
>
> this stuff is useless, takes development time to implement, and 
> produce 0 value, literally confusing and useless
>
> i don't understand why people want D to be a copy pasta of C#
>
> i'd rather the language focus on what _really_ matter, areas 
> where D falls behind serious competition 
> (Rust/Zig/Odin/Nim/Swift)
>
> - native tuple: multiple return value
> - tagged union: improved enum/union
> - pattern matching: improved switch

Tagged Union can easily be implemented as library solutions, and 
ought to take a lot more time than implementing a simple feature 
which brings real value to development. About the others, I could 
not care less, the library tuples+aliasseq are just enough for 
me, tuples are a lot more confusing and code that overuse it is 
*always* bad. I want real productivity features.