[phobos] Time to get ready for the next release

[Robert Jacques]

On Mon, 25 Apr 2011 15:46:20 -0400, Steve Schveighoffer  
<schveiguy at yahoo.com> wrote:
>> From: Robert Jacques <sandford at jhu.edu>
>> To: Steve Schveighoffer <schveiguy at yahoo.com>; Discuss the phobos  
>> library for D <phobos at puremagic.com>
>> Sent: Monday, April 25, 2011 3:29 PM
>> Subject: Re: [phobos] Time to get ready for the next release
>>
>> On Mon, 25 Apr 2011 09:58:47 -0400, Steve Schveighoffer  
>> <schveiguy at yahoo.com> wrote:
>>> ----- Original Message -----
>>>> From: Robert Jacques <sandford at jhu.edu>
>>>> To: Discuss the phobos library for D <phobos at puremagic.com>
>>>> Cc:
>>>> Sent: Sunday, April 24, 2011 12:03 PM
>>>> Subject: Re: [phobos] Time to get ready for the next release
>>>>
>>>> On Sun, 24 Apr 2011 07:33:30 -0400, Jacob Carlborg <doob at me.com>  
>>>> wrote:
>>>
>>>>>   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.
>>>>
>>>> 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.
>>>
>>> It was an idea that Andrei brought up (before @property syntax was  
>>> introduced), but I don't think it can be properly enforced:
>>>
>>> int select(int timeout = 0); // both "getter" and "setter"
>>>
>>> -Steve
>>
>> Hmm... good point. Counter-point, select's functions signature is still  
>> a 'setter' signature. A 'select' / 'select()' method doesn't exist,  
>> it's simply syntactic sugar for select(0). Since a lookup of select by  
>> DMD involves the actual function overloads and not their  
>> sugary-transforms, it should still detect that select has no zero-arg  
>> overload and therefore error on 'select = 5'.
>
>
> Easily worked around:
>
> int select() { return select(0); }
> int select(int timeout) { ... }
>
>
> This seems silly, but it actually is likely to occur with final  
> interface methods that want to enforce what the default select does.

That makes sense. Thanks for the example and rational.

> But in any case, this is diverging into the obscure.  I don't think  
> rules that try to guess what the author is intending are as good as  
> annotations which tell the compiler what the author is intending.

Of course not, but there's a reason that most cars are automatics: there  
is a non-negligible cost to using a heavy annotation based system. The  
question isn't so much as is one 'better' or not, but is it good enough  
most of the time?
There are problems with using @property alone. There are problem with  
using Methods-as-Fields alone. This would indicate that some compromise is  
needed, and therefore every point of the synthesis/trade-off curve is  
valuable. (Or alternatively that we need to scrape both and start a fresh)