https://issues.dlang.org/show_bug.cgi?id=12100

--- Comment #11 from bearophile_hugs@eml.cc ---
A temporary workaround (not meant to be left in place forever) could be using
lambdas as cookie:

pragma(msg, ((int) => 0).stringof);
pragma(msg, ((int) => 0).stringof);
void main() {}


Output:

__lambda3
__lambda4

--

https://issues.dlang.org/show_bug.cgi?id=12100

--- Comment #12 from bearophile_hugs@eml.cc ---
VC++ and GCC have "__COUNTER__":

http://stackoverflow.com/questions/652815/has-anyone-ever-had-a-use-for-the-counter-pre-processor-macro http://msdn.microsoft.com/en-us/library/b0084kay.aspx

--

https://issues.dlang.org/show_bug.cgi?id=12100

Simen Kjaeraas <simen.kjaras@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |pull
                 CC|                            |simen.kjaras@gmail.com

--- Comment #13 from Simen Kjaeraas <simen.kjaras@gmail.com> ---
Here's a PR:

https://github.com/D-Programming-Language/dmd/pull/5633

Notice I have used the name __GENSYM__ due to LISP's precedent.

--

https://issues.dlang.org/show_bug.cgi?id=12100

--- Comment #14 from Simen Kjaeraas <simen.kjaras@gmail.com> ---
A bit of reasoning behind the choices made in the PR above:

(In reply to bearophile_hugs from comment #12)
> VC++ and GCC have "__COUNTER__"

__COUNTER__ breaks when used with separate compilation, as discussed above. Also:

(In reply to bearophile_hugs from comment #6)
> I am asking for a integer that is incremented every time by 1, and that is exported as a range by every pre-compiled module to avoid duplications.

So... how do the other modules know about this range? One'd have to include the other compiled modules on the command line when compiling one module, from what I can see. If not, the compiler won't know of the used values, and chaos would ensue.

For my PR, __GENSYM__ returns a string with a 'G' prefix*, followed by the mangled name of the containing scope, followed by a scope-local counter:

module bar;
struct Ham(string gensym = __GENSYM__) {
    enum s = gensym;
    Eggs!() e;
}

struct Eggs(string gensym = __GENSYM__) {
    enum s = gensym;
}

module foo;
import bar;

struct S {
    static assert(__GENSYM__ == "G3foo1S1");
    static assert(__GENSYM__ == "G3foo1S2");
}

void baz() {
    static assert(__GENSYM__ == "G_D3foo3bazFZv1");
    static assert(__GENSYM__ == "G_D3foo3bazFZv2");
}

static assert(__GENSYM__ == "G3foo1");
static assert(__GENSYM__ == "G3foo2");

void main() {
    static assert(__GENSYM__ == "G_Dmain1");
    static assert(__GENSYM__ == "G_Dmain2");
    static assert(Ham!().s == "G_Dmain3");
    static assert(Ham!().s == "G_Dmain4");
    static assert(Ham!().e.s == "G3bar31__T3HamVAyaa8_475f446d61696e35Z3Ham1");
    static assert(Ham!().e.s == "G3bar31__T3HamVAyaa8_475f446d61696e36Z3Ham1");
// Note that this is not identical to the above (5Z3Ham1 vs 6Z3Ham1)
}

The mangled names should be fairly unique, and I don't think there's a case
where the order of instantiation would be different within a single scope, but
I'm prepared to be proven wrong on this.
So that should take care of separate compilation.

It's possible that this scheme can return values that are no valid identifiers (if mangleof contains invalid characters). This is currently simply ignored.

* The 'G' prefix is used so that __GENSYM__ should return a valid identifier. The exact character is once again chosen for LISP compatibility.

--

https://issues.dlang.org/show_bug.cgi?id=12100

Iain Buclaw <ibuclaw@gdcproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P2                          |P4

--