On 23 apr 2011, at 23:20, Robert Jacques wrote:
> 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.
If writeln = "foo"; doesn't compile but printf = "foo"; does then I would
consider it not fixed. The way I would want @property to behave is disallow bar
= "foo"; for functions not marked with @property. But still allow functions not
marked with @property to be callable without parentheses.
> 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
--
/Jacob Carlborg
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
