Summary: allow undefined aliases as template parameters and
                    alias tuples
           Product: D
           Version: D2
          Platform: x86_64
        OS/Version: Windows
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: DMD

--- Comment #0 from Gor Gyolchanyan <> 2011-07-28 08:35:50 PDT 
There are times, when a template needs to take an identifier as a parameter to
bind that identifier with something. For example:

mixin template aliasInt(string name)
    mixin(`alias int `~name~`;`);

This sure does what it says and the D identifier string literal reflects the
nature of the string being passed, but the problems gets very complicated when
using complex static conditions, which force you to wrap the entire template
body into a mixin just because you need an identifier.

I suggest to allow undefined aliases as template parameters and add a
__traits(defined, ...), which tests if the given aliases are defined or not.
in that case the above ugly template becomes small, clean and cute:

mixin template Test(alias name)
    alias int name;

but that would force everybody else to add another template constraint to
ensure, that the alias they are receiving is valid, unless they already do
check it for being a type, a function or something similar.

another way of doing this is to add a new construct, called a "symbol". A
symbol would be a compile-time only value, which holds a string literal of D
identifier format. It can be declared as:

symbol a = hello;

where "hello" is actually a string literal and thus, need not be a valid alias.
The key difference of a symbol from a string literal is, that the symbol will
behave exactly like an alias (allow to take the type of the symbol if it's a
variable, use it in the isExpression if it's a type, etc..).
If the symbol is initialized by or assigned an alias, then it will be have as
an alias, but if it's initialized by an undefined identifier, it behaves more
like a string.
a symbol would be able to be assigned an alias, in which case it would
essentially get it's name:

symbol a = writeln;
// is same as:
symbol b = writeln.stringof;

any other kind of strings would be illegal to assign to a symbol value.
the symbol is always compile-time and could be read from CTFE freely and be
able to be rebound.

this also removes some problems in the world of compile-time refection: Some
traits take and return strings, representing names, some take aliases and some
return functions (not function pointers), which can't be aliased.

For example, the __traits(getOverloads, ...) returns the functions themselves.
They can only be iterated over in a foreach. returning a string is useless,
because then the types of the overloads would be impossible to test. returning
symbols will allow to save them (possibly in an array or a tuple) and reuse

Configure issuemail:
------- You are receiving this mail because: -------

Reply via email to