On Friday, 28 June 2013 at 12:45:22 UTC, Marco Leise wrote:
Am Thu, 27 Jun 2013 23:24:48 +0200
schrieb "Meta" <[email protected]>:

I'm not an expert on how DMD works, but could this possibly be done after the native code is generated

I've thought of that as well, but you have to merge templates
at an earlier stage. In case of a compiler such as GCC, the
native code is not even generated in the compiler, but an
external assembler.
That said, DMD does not create duplicate template instances
for the same parameters. I'd assume this includes "string
lambdas".

What is a "string lambda" ? Do you mean "a string alias latter parsed as an expression", or "an actual lambda function". There were talks about this recently in learn: If you *type* the same lambda function twice, it *will* generate two different templates.
http://forum.dlang.org/thread/[email protected]

For example:
--------
struct S(alias pred){}

void main()
{
    auto a = S!(() => 1)();
    auto b = S!(() => 1)();
    a = b;
}
--------
DMD v2.064 DEBUG
main.d(7): Error: cannot implicitly convert expression (b) of type S!(function int()
{
return 1;
}
) to S!(function int()
{
return 1;
}
)
--------

However,

--------
enum PRED = () => 1;

struct S(alias pred){}

void main()
{
    auto a = S!PRED();
    auto b = S!PRED();
    a = b;
}
--------
This is fine.

From testing, *string* preds don't have this "feature"/"bug" (?), even if you compile time build them, the compiler will "see" that it is the same string (probably true for integrals and whatnot). But for lambdas, only their *name* counts (eg __lambda1__). So if you plan to re-use a lambda, it *must* be stored in a way the compiler can "see" its unicity, and not typed more than once.

Furthermore, I'm think this is the correct behavior.

Reply via email to