Michel Fortin wrote:
On 2009-07-28 11:37:05 -0400, Andrei Alexandrescu
<[email protected]> said:
Michel Fortin wrote:
On 2009-07-28 10:16:16 -0400, Andrei Alexandrescu
<[email protected]> said:
Well I don't think so. To repeat what I wrote elsethread: foo = bar
is rewritten into foo(bar) if and only if auto __x = foo, __x = bar
works. This means, a setter only works if there's a corresponding
getter. (Write-only properties be damned.)
This may lead to strange issues if both the setter and the getter
don't have the same protection attribute, or purity, or constness of
arguments.
For instance:
protected void foo(Object o);
public pure const const(Object) foo();
Here, you can assign to foo using the property syntax only from a
non-pure functions of this class or a derived classes and when the
value you're assinging is a const(Object). Elsewhere, you can only
assign using the function syntax. Anything else would break "auto __x
= foo, __x = bar".
Well I chose the rule that makes bar look and feel as much as an
assignable value as possible. The rule could be relaxed (e.g. by
dropping qualifiers), but that means we're departing from assignable
value lookalike.
Also, what if a derived class implements a getter while the base class
only has a setter. Does that mean that only the derived class can use
the property syntax on the base class' setter?
It all follows normal language rules. That's what I like about rewrites
(lowerings): they allow you to reason about a new mini-feature (that in
this case is absolutely nothing beyond a minor syntactic convenience) in
terms of the rest of the language.
What I don't like about that proposal is that that how to call a setter
is bound to the existence of another function in the same scope using
pretty non-obvious rules.
I think the rules are very obvious.
Also, it doesn't solve the problem of the
getter that returns a delegate since you can continue using the function
notation with properties and you can continue to call functions with no
parenthesis.
It doesn't solve the problem with a getter that returns a delegate.
People who want to return delegates must use an extra pair of parens.
While I like too being able to call functions with no argument by
skipping the tailing parenthesis, I'd easily give up on that if it means
I can get a language with less ambiguities.
I wouldn't want to hurt the majority of my code for an obscure case. I
do agree I'd rather not have an obscure case in the first place.
I also happen to agree with Walter and you that it wouldn't be so great
to just decorate functions with a keyword to give them a different
syntax. I've propsed earlier a namespace-like syntax where you can have
functions like "foo.opAssign" inside a class (or anywhere really) that
you can call with "foo = x", unifying properties with operator overloading.
That would work. Many things would work.
Andrei
