On Sun, 03 Feb 2013 11:11:05 -0500, Andrei Alexandrescu
<[email protected]> wrote:
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.
This sounds good. It might be a bit confusing, but nice in the fact that
&(a.b) always means address of whatever b returns, whether it is a field
or property.
* 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
I think this is a possible solution, and I can live with that, I'm fairly
certain that some people use global properties currently, so they will not
be too happy.
But having to set global properties using a function call (global getters
can simply be paren-less functions) isn't horrible.
* Are templated properties allowed?
** The access syntax for properties doesn't allow providing types
No. Templated member variables are not allowed either.
Wait, what? I don't like this idea. Why should this not be allowed:
@property void x(T)(T t) {_x = to!(typeof(_x))(t);}
As for templates that return a templated type, it should be allowed,
although the calling syntax would have to be for the explicit template
call, since you can't do IFTI on return values. In other words:
template x(T) { @property T x(){return to!(T)(_x);} } // could be
shortened to normal @property T x(T)()
auto xcopy = obj.x!(string).x;
Certainly, we need templated getters and setters at module levels:
@property T front(T)(T[] r) { return r[0];}
-Steve
