Lazy eval

[Unknown W. Brackets]

Well, if I saw:

auto new_p = coalesce(p, last_p, new P())

I would not assume that new P() would be evaluated, unless p and last_p 
were null.

The same goes for a lot of macro function usage seen with the C 
preprocessor.  People are already dealing with this problem.  A lot.

I like this new feature, and would hate having to type the curlies.  I 
feel confident I can correctly document my functions and name them such 
that no one would be confused.

I won't, however, be using this feature with other function.  Or half, 
or even 15%.  I'll use it when it makes sense.

In my opinion it is a good feature.  And it makes D stand out.

-[Unknown]


> I think the lazy eval is a great feature, but in this form it has also
> great drawbacks.
> 
> The code isn't that much readable as it was before. You don't know what
> will happen. Will that expression be evaluated or not? Or will it be
> evaluated more than once?
> 
> There is no possibility to choose between
> 
> func( char[] a ) vs. func( char[] delegate() dg )
> 
> func( funcRetInt() ); vs. func( &funcRetInt );
> 
> It would be really important for me to have readable code. I want to
> look at the code, and want to have an impression what will happen.
> 
> What really would help, is if the the delegate is marked in some way as
> such. In the last releases of DMD the {} syntax was there. With it you
> needed the return statement. Perhaps we can choose the {} syntax with an
> optional return statement....
> 
> 
> { "abc"         } => char[] delegate()
> { return "abc"; } => char[] delegate()
> 
> func( "abc" ) calls func( char[] a )
> func({ "abc" }) calls func( char[] delegate() dg )
> func({ return "abc"; }) calls func( char[] delegate() dg )
> 
> With that syntax one can immidiatly see "this is a delegate, if it is
> called or not or more than once depends on func()" and the more typing
> of {} is not too much.
> 
> Frank
>