DIP23 draft: Fixing properties redux
Andrei Alexandrescu
SeeWebsiteForEmail at erdani.org
Sun Feb 3 08:11:05 PST 2013
On 2/3/13 5:14 AM, Johannes Pfau wrote:
> "If a function returns a reference, then assignment through the
> paren-less call should work: "
>
> This is the only part where I would disagree. Why is this special rule
> necessary if we have full @property support? I think this would still
> allow too many false positives.
(As a note, this is the current behavior.)
The way I see it is this is a natural consequence of optional parens.
The name of a function without a "&" prepended or a "()" after it will
invoke the function, and that's that.
> One important aspect that this proposal doesn't cover yet is whether we
> want to allow "semantic rewriting" for properties:
> ----
> Struct a;
> a.property++; //would this be legal?
> ----
It's dangerous to get too clever about that. Anyhow, such rewrites are
possible:
++a.p ----> { auto v = a.p; ++v; a.p = v; return v; }()
a.p++ ----> { auto v = a.p; ++a.p; return v; }()
and so on.
> for other corner cases this list is a good start:
> http://wiki.dlang.org/Property_Discussion_Wrap-up#Implementation_concerns
>
> * Can we get a reference to the property? What does
> &x.property mean?
We need to add this to the proposal. There are two schools of thought here:
1. Make properties emulate regular variables as much as possible. In
that case &a.p is the same as &(a.p), i.e. it applies to the returned
value. (One counter-argument here is that properties should seldom
return a reference because that breaks encapsulation.)
2. Allow people to do whatever they need to do without much aggravation.
In that case &a.p obeys the normal rules of taking a method's address,
and &(a.p) applies to the returned value.
I favor (2) and put it in http://wiki.dlang.org/DIP23. Will talk to Walter.
> * How can we get the getter / setter functions? Do we need to get those?
Per (2) above there is no need for special provisions.
> * What is the type of the property? Return type, setter function type
> or getter function type? How to get the other types?
typeof(r.front) is the return type of the property, typeof(&(r.front))
is the type of a pointer to the return type of the property where
applicable, and typeof(&r.front) is the (possibly ambiguous) address of
the method. (To disambiguate one would use the appropriate receiver type.)
> * What does x.property++ do?
> ([http://www.prowiki.org/wiki4d/wiki.cgi?DocComments/Property#Semanticrewritingofproperties
> Semantic rewriting])
Added to http://wiki.dlang.org/DIP23.
> * Is returning ref values from the getter OK?
I see no reason to disallow it at the language level.
> * Is taking ref values in the setter OK?
How do you mean that?
> * Should all properties be nothrow? pure? getter const?
> ** Probably better as a rule for style guide.
No restriction at language level.
> * Are UFCS properties possible? How do they work exactly?
> * How do you disambiguate property functions when they're free
> functions which conflict?
I think it would be best to simply disallow parameterless module-level
properties.
// at top level
@property int foo(); // error
@property int goo(int); // fine, assume a getter for int
> ** Normal UFCS functions can be force
> called by using their fully qualified name. That's not possible for
> properties if function call syntax is disallowed?
Correct. Writing @property buys the writer into a constrained universe.
> * How many parameters are allowed for property functions?
One or two at top level, zero or one at member level.
> ** Are default parameters allowed?
> ** Especially consider the example about __FILE__ and __LINE__
I'd say no. Just keep it simple and focused on the goal.
> * Are templated properties allowed?
> ** The access syntax for properties doesn't allow providing types
No. Templated member variables are not allowed either.
Andrei
More information about the Digitalmars-d
mailing list