Revised RFC on range design for D2

Fawzi Mohamed fmohamed at mac.com
Fri Oct 3 03:27:24 PDT 2008


On 2008-10-02 21:13:16 +0200, Andrei Alexandrescu 
<SeeWebsiteForEmail at erdani.org> said:

> Sean Kelly wrote:
>> == Quote from Andrei Alexandrescu (SeeWebsiteForEmail at erdani.org)'s article
>>> Bruno Medeiros wrote:
>>>> I don't understand that. You stated "It violates economy of syntax.", so
>>>>  it violates your Principle 1 of language design. So how can you be
>>>> happy with that (apart from the assignment issue)? Does fixing this
>>>> problem violate some other principle or concern of yours?
>>> I think keeping the language simple is also a good goal.
>> 
>> I apologize if this has been brought up before, but I'm not sure that 
>> simplicity
>> is a good thing if it can result in unpredictable behavior.  For example:
>> 
>>     import std.stdio;
>> 
>>     class C
>>     {
>>         this( bool delegate() p )
>>         {
>>             version( a )
>>                 cond = p;
>>             version( b )
>>                 ptr = p;
>>         }
>>         version( a )
>>         {
>>             bool delegate() cond;
>>         }
>>         version( b )
>>         {
>>             bool delegate() ptr;
>>             bool delegate() cond() { return ptr; }
>>         }
>>     }
>> 
>>     void main()
>>     {
>>         bool test() { writefln( "hi" ); return false; }
>>         auto c = new C( &test );
>>         if( c.cond() )
>>             writefln( "true" );
>>     }
>> 
>> Running version=a prints "hi" while version=b prints "true."  If there were
>> some way in the language to say "cond() is a property" then this issue would
>> not be silently introduced when changing cond from a variable to a method.
> 
> Oh how I am with you on this. I've always thought mentioning a delegate 
> name should NOT EVER evaluate the delegate.

I think here the problem is different
c.cond() in version a evaluates the delegate
in version b
c.cond() is interpreted as the the omittable parenthesis of the 
accessor method, and returns the delegate.
As (as you want, and I think is reasonable) the delegate is not 
evaluated. In if it is then interpreted as a logical and gives true (as 
it is a valid delegate, not null).
c.cond()() would give false.
So actually automatically evaluating the delegate would actually fix 
this particular problem (but would indeed introduce many other 
problems, like how to then get the delegate).

> Walter definitely took the wrong turn down that alley there. And guess 
> what. He got ambushed by the "lazy" keyword right there. I told Walter 
> to not do that "lazy" keyword, he disregarded, but the time will come 
> when that stone will be turned.
> 
> 
> Andrei




More information about the Digitalmars-d-announce mailing list