What's the story with @property again?

[Jonathan M Davis]

On Sunday, November 10, 2024 4:26:04 AM MST Alexandru Ermicioi via 
Digitalmars-d wrote:
> On Saturday, 9 November 2024 at 11:58:34 UTC, Jonathan M Davis
>
> wrote:
> > Honestly, UFCS kind of killed most of what was planned for
> > @property, and no new plan has ever been decided upon, so it's
> > just sat there, and since it isn't really causing issues, it
> > hasn't been a priority to figure out what to do about it. There
> > aren't a lot of people working on the language, and other stuff
> > has mattered a lot more. In all likelihood, @property will just
> > stick around as it is until someone takes the time to write a
> > DIP to do something interesting with it (and it's good enough
> > to be accepted).
> >
> > - Jonathan M Davis
>
> It would be nice to have it as simple annotation at least that
> denotes a method acts like a property. It would be useful for
> serialization libs in detection of what methods are actually
> properties that can be serialized/deserialized.

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.

In principle, @property is more supposed to be for providing a way to
emulate a field with getter and setter functions, and with the current
implementation, it's not really needed for that, since parens are optional
on functions with no arguments, and the assignment syntax works with member
functions that take a single argument. In that respect, the main hole is
that you can't really have a property that returns a delegate or other
callable and have it work as a property, because the parens will be used for
the property function call and not the return value (which is one reason why
having @property do more could be useful, but you'd probably need to make it
illegal to call @property functions with parens to make that clean, and I
doubt that we're going to go there at this point).

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

- Jonathan M Davis