[phobos] Time to get ready for the next release

[Robert Jacques]

On Sat, 23 Apr 2011 16:06:35 -0400, Jacob Carlborg <doob at me.com> 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.