What's the story with @property again?

[Alexandru Ermicioi]

On Sunday, 10 November 2024 at 11:52:30 UTC, Jonathan M Davis 
wrote:
> Usually, a library that's going to do something like that is 
> just going to provide its own user-defined attributes that let 
> the programmer tell it that kind of information based on how 
> the serialization library actually works. And whether a 
> function is designed to be use as a property doesn't 
> necessarily say much about what actually needs to be serialized 
> in order to be able to restore an object from the serialized 
> data at some point in the future.

The problem is that you'd get for each serialisation lib it's own 
set of annotations which is unmanageable if you try to use two 
different serialisation libs. Say one for json and one for xml, 
that both use annotations for serialisation info.
Also, in most common use case serialisation libs tend to 
serialise everything. For example jackson in java would serialise 
all getter methods unless marked to ignore. In D for example we 
don't have getter convention (i.e. getXxx method is only fetching 
a field in object), but we have property annotation that can be 
used instead. Without it you'd have to slap json and xml 
annotations over all methods acting as properties.
>
> In any case, the bigger problems stem from all of the various 
> things that you can do with an lvalue that you can't do with 
> getter and setter functions (e.g. taking the address of the 
> value or pass it by ref). And solving that problem is much 
> thornier (and probably not completely possible without 
> abstracting stuff like & in a way that we probably don't want 
> to). So, while ideally, you'd be able to swap between @property 
> functions and actual fields seemlessly, that's probably never 
> going to happen (though we could get closer than we currently 
> do).

Yeah, so current functionality built with @property annotation 
should be removed, but annotation itself can be repurposed to be 
like a marker denoting a method acts as a pseudo property, where 
devs and libs can use it to better understand what method is used 
for. In general would be nice to have a bunch of annotations that 
unify common meanings that are not possible to express through 
type system and might be used by reflection mechanisms similar to 
@property annotation, and for serialisation or other reflection 
libs to use them as well.
>
> - Jonathan M Davis