On Sun, 10 Oct 2010 08:44:59 +0400, Robert Jacques <sandf...@jhu.edu>
wrote:
On Sat, 09 Oct 2010 22:03:56 -0400, Denis Koroskin <2kor...@gmail.com>
wrote:
On Sun, 10 Oct 2010 05:58:00 +0400, Robert Jacques <sandf...@jhu.edu>
wrote:
On Sat, 09 Oct 2010 16:28:32 -0400, Denis Koroskin <2kor...@gmail.com>
wrote:
On Sun, 10 Oct 2010 00:09:23 +0400, Sean Kelly
<s...@invisibleduck.org> wrote:
Andrei Alexandrescu <seewebsiteforem...@erdani.org> wrote:
On 10/8/10 7:55 CDT, Steven Schveighoffer wrote:
Someone was asking about UFC syntax for properties on d.learn, and
I
realized, we have a huge ambiguity here.
Given a function:
@property int foo(int x)
Is this a global setter or a getter on an int?
Good question.
Setter. Consider "a = b = c".
I think you missed the point. Which of the two is it:
int x = 42;
auto y = x.foo(); // transformed into "auto y = foo(x);", getter
or
foo = 42; // transformed into "foo(42);", setter
Both match.
I agree that there is ambiguity here, but does it why does foo have to
be only a getter or only a setter? Why can't it behave like either,
depending on its implementation and use?
Because you may want to have both, but you can't because their syntax
overlap.
Okay I'm confused. How do their syntax overlap? And which syntaxes do
you think are overlapping?
All the following 'lowerings' look fine/unambiguous to me:
foo = 42; => foo(42);
y = x.foo; => y = x.foo(); => y = foo(x);
foo = foo = x.foo; => foo = foo = x.foo(); => foo = foo = foo(x); => foo
= foo(foo(x)); => foo(foo(foo(x)));
I wasn't talking about ambiguity. I told that you can't assign different
behavior to
foo = 42;
and
y = x.foo;
Both are resolving to the same symbol.
E.g. I'd like to write a setter, "foo = 42;":
private int _foo;
int foo(int x)
{
debug writeln("foo = ", x);
_foo = x;
return x;
}
But the following code also triggers the setter above:
y = 42.foo(); // prints "foo = 42;", sets private variable _foo to 42, and
returns that value
That's completely unexpected. Imagine yourself writing class Foo with
method bar, and a user who highjacks a hole in the language, creates class
bar, and invokes method Foo on it. That's what it looks like at this
moment.
