[phobos] Time to get ready for the next release

[Robert Jacques]

On Sun, 24 Apr 2011 07:33:30 -0400, Jacob Carlborg <doob at me.com> wrote:
> On 23 apr 2011, at 23:20, Robert Jacques wrote:
>> 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.
>
> 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.

I have not heard this particular combination before; thank you. More  
choices are always appreciated. There are real, practical use cases for  
not- at property methods with write-only field semantics, which this would  
prevent. And between a real use case and a synthetic straw-man, I believe  
the use case should win. However, I am interested in any of the practical  
issues which inspired writeln = "foo", if you know of any.

Also, this and another post have given me an idea: what if non- at property  
methods could be assigned to if and only if a valid 'getter' also existed.  
This would still 'fix' writeln = "foo" but be a less restrictive than an  
outright ban.