On Saturday, November 9, 2024 3:36:00 AM MST Anton Pastukhov via Digitalmars-d wrote:
> I'm looking here: https://forum.dlang.org/post/uhcopuxrlabibmgrbqpe@forum.dlang.org and have an impression that @property was on the verge of deprecation in 2022. Specs, however, give a warning that this feature is "evaluated for its usefulness" but doesn't mention deprecation (https://dlang.org/spec/function.html#property-functions). So, two years later, at the end of 2024, what's the story with @property? Is it stuck in limbo?
>
> I also see threads like this https://forum.dlang.org/thread/gkvmkiuaaklywvfuyzpz@forum.dlang.org, that also end without any resolution. Honestly, this looks sad

I'm pretty sure that it simply hasn't been a priority, and if something more interesting is going to be done with it, then a DIP will be required (which some folks have talked about doing, but IIRC, no one has actually written one yet).

At this point, IIRC, all that @property really does is make it so that typeof gives the return type of the function and not the type of the function itself. This is occasionally useful (e.g. std.traits actually uses it to be able to implement a couple of traits, which would have to be rethought if it went a away), but for the most part, it's not particularly valuable, and it does complicate some type introspection, since you have to deal with the fact that typeof on a function isn't always the type of the function. For the most part though, it really isn't causing any problems. Lots of people seem to use it to document that they intend for a function to be used as a property, so it gets used pretty frequently, but it doesn't really do much good or bad in practice, so it's largely just documentation.

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

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.

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

On Sunday, 10 November 2024 at 11:52:30 UTC, Jonathan M Davis wrote:
> 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

> 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).
I want @property exactly because you cannot take the address of it.
For me the usecases of @property are
- protecting from modification (no setter)
- protecting from reading (no getter)
- protecting from getting the address (because: should that be the address of the getter or the setter? "&" should simply be forbidden)
- else working like an ordinary field (e.g. all operators defined for the field-type should work as usual).
- if you don't like that, use ordinary functions or ordinary fields.

Nothing of this is complicated to implement. We only need someone to decide: do we want this or not?

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

On Sunday, November 10, 2024 12:10:48 PM MST Steven Schveighoffer via Digitalmars-d wrote:
> So I just want to say as a side note, I've been using SDC to develop the new GC, and while there are a lot of missing features, one thing that SDC has implemented is enforcement of `@property` syntax. That is, if a function is labeled `@property`, then `&obj.member` gives you an address to the return of the property, and `obj.member()` would not be valid unless the return value was a callable.
>
> I have to say, I quite like this, and I wish D would adopt a more strict version of `@property`.
>
> I honestly think we should try a preview switch here...

I'd love to have a more strict version of @property where you're forced to use it like a property, and parens on it are always used on the return value. That would be a lot more useful (particularly since delegates and callables really can't be used with @property functions right now). That's essentially where we were supposedly going before, but previously, it would have included the requirement to use parens on non-@property functions, and UFCS definitely killed that, because people loved dropping the parens with UFCS. But if we could at least get the enforcement on @property functions so that they act like actual properties, that would be great.

- Jonathan M Davis