[phobos] Time to get ready for the next release

[Steve Schveighoffer]

>________________________________
>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.

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.


-Steve