www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - What's the story with property again?

reply Anton Pastukhov <caffeine9999 mailbox.org> writes:
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
Nov 09
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
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
Nov 09
next sibling parent reply Alexandru Ermicioi <alexandru.ermicioi gmail.com> writes:
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.
Nov 10
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
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
Nov 10
next sibling parent Dom DiSc <dominikus scherkl.de> writes:
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?
Nov 10
prev sibling parent Alexandru Ermicioi <alexandru.ermicioi gmail.com> writes:
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
Nov 10
prev sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
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).


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

-Steve
Nov 10
next sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
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
Nov 10
prev sibling parent reply Nick Treleaven <nick geany.org> writes:
On Sunday, 10 November 2024 at 19:10:48 UTC, Steven Schveighoffer 
wrote:

 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.


Does it also disallow `writeln = "hi";`? That should be made an 
error IMO.
https://issues.dlang.org/show_bug.cgi?id=17474
Nov 13
next sibling parent Paul Backus <snarwin gmail.com> writes:
On Wednesday, 13 November 2024 at 16:44:53 UTC, Nick Treleaven 
wrote:

 On Sunday, 10 November 2024 at 19:10:48 UTC, Steven 
 Schveighoffer wrote:

 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.


 Does it also disallow `writeln = "hi";`? That should be made an 
 error IMO.
 https://issues.dlang.org/show_bug.cgi?id=17474


The fact that this works is actually kinda useful for writing 
`opDispatch` wrappers. You can write something like

     auto opDispatch(string name, Args...)(Args args)
     {
         return __traits(getMember, payload, name) = args;
     }

...and it will work for both member functions and member 
variables.
Nov 13
prev sibling parent Steven Schveighoffer <schveiguy gmail.com> writes:
On Wednesday, 13 November 2024 at 16:44:53 UTC, Nick Treleaven 
wrote:

 On Sunday, 10 November 2024 at 19:10:48 UTC, Steven 
 Schveighoffer wrote:

 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.


 Does it also disallow `writeln = "hi";`? That should be made an 
 error IMO.
 https://issues.dlang.org/show_bug.cgi?id=17474


I'm unsure, as I haven't tried.

But the point of this wasn't really to say that what SDC does is 
what we should implement in D. The point was to say, this one 
aspect of property enforcement I have been forced to use while 
implementing the GC, and I quite like it. Instead of a hypothesis 
of "yes, I think I would like it if we did this", I can say "I 
like it, and I have experience liking it".

-Steve
Nov 13