On Sat, 23 Apr 2011 16:06:35 -0400, Jacob Carlborg <[email protected]> wrote:
On 23 apr 2011, at 17:32, David Simcha wrote:
On 4/23/2011 11:24 AM, Jacob Carlborg wrote:
I think I would like to have something in the middle of strict and
loose semantics. I would like that functions marked with @property
have to be called like a field:
auto bar = foo.field;
foo.field = 3;
But functions not marked with @property still can be called without
the parentheses:
foo.bar();
foo.bar;
Maybe there's been some misunderstanding, but actually this is what
loose semantics means. Loose semantics (at least as I understand them)
mean stuff marked @property would not be callable using method syntax,
and this rule would be used to disambiguate the corner cases, but
nothing would change for stuff not marked @property.
Ok, then I probably misunderstood. What about:
writeln = "foo";
is that already fixed?
If by fixed, you mean doesn't compile, then yes, it's fixed. But this
might be a quality of implementation issue, regarding method syntax and
templates and not a true theoretical fix. Case in point: printf = "foo"
works. However, while ugly, neither writeln = "foo" nor printf = "foo" are
doing something the original author didn't intend. The greater violators
(which actually caused bug reports/confusion) are those where the
statements became nonsense, like math_function = 5 or obj.factory_method =
6.[1] Fixes for most of these issues exist: Not using the result from a
strongly pure function should be an error, not matter how it's called. And
const/immutable methods shouldn't be assignable, since you can't assign to
a const or immutable variable. Static/free functions can't be marked
const/immutable, but considering the only thing they can modify is global
state, pure is equivalent. So neither strongly nor weakly pure functions
should be assignable.
From a theoretical perspective, assignment is a function which stores a
value (in addition to taking an input and producing an output, like any
other function). Since we can cleanly express in D whether a function
modifies external state (i.e. stores values) via pure/const/immutable, we
can detect and error on non-consistent uses of assignment. This won't be
perfect, because not all functions which modify state store something from
a high-level point of view, but it covers a lot (all?) of the common use
cases.
Regarding your question, writeln/printf = "foo" would still be valid under
these new tests; but to play devil's advocate, maybe you do kernel
development work, etc, and mentally model I/O as writing to specific
memory locations. That mental model actually prefers printf = "foo" to
printf("foo").
P.S. I've never liked the writeln = "foo" example, because it's of the
form verb = value, and therefore feels like a straw men. The more
realistic situation is noun = value, but its very hard to find this kind
of example that is A) named in a way such that a user might reasonably
make an assignment to it and B) also feels natural as a method call.
[1] In the actual examples, the use of a noun for the factory function
name lead to the confusion.
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
