On Wed, 13 Oct 2010 14:34:14 -0400, Steven Schveighoffer
<[email protected]> wrote:
On Sat, 09 Oct 2010 21:58:00 -0400, Robert Jacques <[email protected]>
wrote:
On Sat, 09 Oct 2010 16:28:32 -0400, Denis Koroskin <[email protected]>
wrote:
On Sun, 10 Oct 2010 00:09:23 +0400, Sean Kelly
<[email protected]> wrote:
Andrei Alexandrescu <[email protected]> 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 then we are back to writeln = 42;
-Steve
:) I see that despite not valid code for what, over a year now?, writeln =
42 still persists.
That said, how exactly are we back to the verb = value "problem"? The
rearrangement ambiguity was never the expressed reason for introducing
@property. In fact, despite all the passionate posts about how wrong "verb
= value" looks, it took a very specific syntax ambiguity with
delegates/opCall to warrant language inclusion. And given the practical
problems @property has been running into, it kinda makes me wish I had run
across the uniform access principle
(http://www.eiffel.com/general/column/2005/Sept_October.html) back during
the debates.
