[phobos] Time to get ready for the next release

[Robert Jacques]

On Mon, 25 Apr 2011 13:50:25 -0400, Jacob Carlborg <doob at me.com> wrote:
> On 24 apr 2011, at 18:03, Robert Jacques wrote:
>> 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.
>
> I don't know if there is an issue with writeln = "foo" other than that  
> it can be confusing and looks very odd.

Then how is it any worse than all the other strange, confusing, odd and  
downright cryptic code one _could_ write in C/C++/D/etc, but (almost)  
_never_ actually does? (outside of programming competitions, that is).