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
