On 9/30/2011 9:01 AM, Christophe wrote:
> If the common type is obvious, the programmer can just type it.

What if it's ridiculously long and verbose?

> If not,
> I do not want to rely on the compiler to perform implicit casting to a
> type that I don't even know, and where I might loose informations,
> unless there is an unambiguous and error-free way to determine the comon
> type. I prefer the compiler to complain about an ill-defined return type
> than a compiler making uncontrolled casting to a type I don't even know.
> If auto return type has to be improved, it must be using a very safe and
> clearly defined behavior.

I was thinking it would work the same way as the ?: operator does.

dsimcha , dans le message (digitalmars.D:145820), a écrit :
> I was thinking it would work the same way as the ?: operator does.

I can believe that the way ?: work is appropriate to infer types of function with multiple return, but the documentation of ?: is not clear about what it does...

http://www.d-programming-language.org/expression.html#ConditionalExpression

On 09/30/2011 08:06 AM, Don wrote:
> On 30.09.2011 02:32, dsimcha wrote:
>> On 9/29/2011 5:06 PM, David Nadlinger wrote:
>>> Yes, this pattern is very useful indeed, I also often use a similar
>>> solution for generating code for string mixins on the fly. Do we already
>>> have a name for it, by the way? I like to call it »IEDL for »Immediately
>>> Executed/Evaluated Delegate Literal«, but that's probably just me.
>>
>> No previously chosen name that I know of, but I like your name. Anyhow,
>> I'm impressed/pleasantly surprised. I didn't realize an IEDL could be
>> executed at compile time to produce a mixin string. If IEDLs are that
>> universally useful, then they definitely deserve some special case
>> performance optimizations, i.e. inlining and avoiding heap allocations.
>> Does anyone else have any interesting use cases for them?
>
> I use them everywhere in the test suite. They behave a lot like comma
> expressions (in that they allow you to put multiple expressions in a
> place where you'd normally only be able to have one) but they allow
> statements and declarations as well as expressions. This makes them
> extremely useful in metaprogramming.

They will be if they are inlined. How about not only allow the compiler to inline the immediately executed delegate literals, but to even _enforce_ that every single one of them is inlined?