Are properties mature enough?

[Jim Balter]

On Monday, 20 August 2018 at 00:49:02 UTC, Jonathan M Davis wrote:
> On Sunday, August 19, 2018 12:32:17 PM MDT QueenSvetlana via 
> Digitalmars-d- learn wrote:
>> In the D Style Guide, it says:
>>
>> Properties
>> https://dlang.org/dstyle.html#properties
>>
>> Functions should be property functions whenever appropriate. 
>> In particular, getters and setters should generally be avoided 
>> in favor of property functions. And in general, whereas 
>> functions should be verbs, properties should be nouns, just 
>> like if they were member variables. Getter properties should 
>> not alter state.
>>
>> In the Properties function section, it says:
>>
>> https://dlang.org/spec/function.html#property-functions
>>
>> WARNING: The definition and usefulness of property functions 
>> is being reviewed, and the implementation is currently 
>> incomplete. Using property functions is not recommended until 
>> the definition is more certain and implementation more mature.
>>
>> So which is it?
>
> Feel free to use @property or not, but the main point in the 
> style guide is about naming functions, not about @property. The 
> idea is that functions that wrap or emulate variables should 
> act like variables themselves. So, they should be named as if 
> they were variables and syntactically used as if they were 
> variables rather than prepending their names with get or set 
> and calling them as functions. e.g.
>
>     struct S
>     {
>         int prop() { return _prop; }
>         int prop(int val) { return _prop = prop; }
>
>         private int _prop;
>     }
>
> with
>
> auto r = s.prop;
> s.prop = 42;
>
> instead of
>
> struct S
> {
>     int getProp() { return _prop; }
>     int setProp(int val) { return _prop = prop; }
>
>     private int _prop;
> }
>
>
> auto r = s.getProp();
> s.setProp(42).
>
> Marking property functions with @property is an extremely 
> popular thing to do, but all it really does at this point is 
> document that the programmer intends for it to be used as a 
> property rather than enforce anything.
>
> IMHO, the spec words that bit too strongly, and it should be 
> fixed. That bit got added recently, because one of the devs 
> didn't understand the @property situation, and when he found 
> out what it was, he felt that the spec needed to be clarified 
> about it so that folks didn't think that it was what the spec 
> was claiming, but clearly, he's just confused matters in a 
> different way.
>
> Here's the deal. Using the property syntax with functions 
> really has nothing to do with @property. It's just based on the 
> signature that a function has. If it's a free function, and it 
> has a return value but no arguments, without using UFCS, it can 
> be used as a getter
>
> int prop();
>
>     auto r = prop;
>
> If it has a single argument, or it returns by ref, then it can 
> be used as a setter.
>
>     ref int prop();
>     int prop(int);
>     void prop(int);
>
> all work with
>
>     prop = 42;
>
> though the first two can also be used in chained assignment 
> operations, since they also return a value, whereas the third 
> can't be. e.g.
>
> auto foo = prop = 19;
>
> works with the first two but not the third.
>
> All of the same signatures as member functions also work in the 
> same way except that you then get
>
>     auto r = obj.prop;
>
> for the getter and
>
>     obj.prop = 42;
>
> for the setter. And if they're free functions, and you want to 
> use them with UFCS, then they each need one more parameter. e.g.
>
>     int prop(MyObj);
>
>     auto r = obj.prop;
>
> for the getter and
>
>     ref int prop(MyObj);
>     int prop(MyObj, int);
>     void prop(MyObj, int);
>
>     obj.prop = 42;
>
> for the setter. All of this works regardless of anything to do 
> with @property and has had since well before @property existed 
> (well, aside from using it with UFCS, since UFCS came later). 
> However, a number of folks thought that it was too messy to 
> allow any old function with the right set of parameters to be 
> used with the property syntax rather than requiring that it be 
> part of the API that it be a property function. Probably the 
> most egregious case is that something like
>
> writeln = 42;
>
> works just fine, and writeln is clearly a function, not a 
> function emulating a variable (which is what a property 
> function is supposed to be). So, to improve the situation, 
> @property was proposed.
>
> The idea was that functions marked with @property and the 
> correct number of parameters would work as property functions 
> and that they would _have_ to use the property syntax when 
> being used, whereas functions that weren't marked with 
> @property were not allowed to use the property syntax. The 
> ad-hoc nature of the whole thing then goes away, and stuff like
>
> writeln = 42;
>
> is then illegal. It also fixes the problem where the function 
> returns a callable (e.g. a delegate or a functor). If you have 
> the function foo, and it returns a callable, as long as it's 
> legal to call the function with the property syntax - foo - or 
> without - foo() - there's no way to distinguish when the 
> callable that's returned by the function should be called. If 
> foo is treated as a property, then foo() would call the 
> callable that foo returned, whereas if it's treated as a 
> function, then it would be foo()(). Without a way to indicate 
> that a function must be used as a property, there really isn't 
> a way to fix that.
>
> However, introducing enforcement to @property was a major 
> breaking change. So, for a while the -property flag was 
> introduced which was supposed to add enforcement so that we 
> could get code working with it first and then switch over to it 
> being the normal behavior later. However, the -property switch 
> didn't fully implement all of the necessary checks, and a lot 
> of folks weren't using it, so the transitition really wasn't 
> happening. And then UFCS came along.
>
> Once we got UFCS, it became normal to see code such as
>
> auto foo = range.map!(a => bar + 42);
>
> The first set of parens is for the template argument, so this 
> is technically using the property syntax. If @property were 
> enforced, then
>
> auto foo = range.map!(a => bar + 42)();
>
> would be required, and a lot of folks didn't like that. They 
> thought that it was too many parens. So, lots of folks didn't 
> want @property enforcement at that point. It really couldn't be 
> properly enabled without a lot of screaming, so plans do 
> enforce it were dropped as was the -property switch.
>
> The result is that @property currently only really does two 
> things:
>
> 1. Make it so that typeof(foo) gives you the return type of the 
> function rather than the function's actual type (this can be 
> argued as a good or bad thing, but it was an attempt to make it 
> act the same as if foo were a variable, since properties are 
> supposed to try to emulate variables).
>
> 2. Restrict function overloads in that a function marked with 
> @property cannot be overloaded with one that's not marked with 
> @property.
>
> @property does no sort of enforcement, and without enforcement, 
> it doesn't stop stuff like
>
> writeln = 42;
>
> It also doesn't affect functions that return callables, meaning 
> that you currently can't really have property functions that 
> return callables and have it work right.
>
> @property has been in limbo ever since UFCS was added, and it 
> became _very_ popular to call functions without parens 
> regardless of whether they were really properties in the sense 
> that they acted like a variable. @property may be deprecated 
> eventually, or it may be that we get some sort of enforcement 
> for it that's specific to properties that are callables - e.g. 
> if it's used on a function returning a callable, then _it_ must 
> be called without parens to fix the ambiguity, but other 
> @property functions don't have that restriction. But the future 
> of @property is very much unknown at this point, and it simply 
> hasn't been a high enough priority to sort out.
>
> However, @property _does_ get used heavily. It's _very_ common 
> practice to use it on property functions as documentation 
> (though I'm sure that since the spec hasn't been as clear on 
> the matter as it should be, plenty of folks use it thinking 
> that it's required). The reason to avoid it for those so 
> inclined is that if it's ever deprecated, then you'll have to 
> change your code, whereas if you don't use it, then you won't 
> have to change your code. But it may or may not ever be going 
> away. Either way, it's used so heavily in D code in general 
> (the standard library included), that it's not going to be 
> removed lightly.
>
> Using @property clearly indicates to those using your code that 
> it was intended to be used as a property function, so that 
> arguably has value, but it's not going to enforce anything. The 
> key thing to take away as far as the style guide goes is that 
> you should use property functions rather than getters or 
> setters. Whether you use @property or not is up to you.
>
> - Jonathan M Davis

That's a lot of detail. The bottom line is that the warning in 
the spec is completely wrong and should be removed -- using 
property functions is not discouraged, nor is @property. 
@property should be used, both as documentation and because it 
makes typeof work correctly. Maybe it will do even more later.