enums and std.traits

Christophe Travert travert at phare.normalesup.org
Mon Aug 6 06:55:36 PDT 2012


Jonathan M Davis , dans le message (digitalmars.D:174310), a écrit :
>> IMO, the behavior should be this: when trying to call the template with
>> a argument that is an enum type based on string, the compiler should try
>> to instanciate the template for this enum type, and isSomeString should
>> fail. Then, the the compiler will try to instanciate the template for
>> strings, which works. Thus, the template is called with a string
>> argument, which is the enum converted to a string.
> 
> I don't believe that the compiler ever tries twice to instantiate _any_ 
> template. It has a specific type that it uses to instantiate the template 
> (usually the exact type passed or the exact type of the value passed in the 
> case of IFTI - but in the case of IFTI and arrays, it's the tail const version 
> of the type that's used rather than the exact type). If it works, then the 
> template is instantiated. If it fails, then it doesn't. There are no second 
> tries with variations on the type which it could be implicitly converted to.
> 
> And honestly, I think that doing that would just make it harder to figure out 
> what's going on when things go wrong with template instantiations. It would be 
> like how C++ will do up to 3 implicit conversions when a function is called, 
> so you don't necessarily know what type is actually being passed to the 
> function ultimately. It can be useful at times, but it can also be very 
> annoying. D explicitly did not adopt that sort of behavior, and trying 
> multiple types when instantiating a template would not be in line with that 
> decision.

If someone implements a library function taking a string. People start 
to use that function with an enum based on string, which is fine, since 
enum implicitely cast to its base type. Now the library writer found a 
way to make is library more generic, and templatise its function to take 
any dchar range. All codes using enum instead of string breaks. Or there 
may be pressure on the library implementer to add load of template 
specializations to make the template work with enums. There is something 
wrong here: enum works for string function, but not ones that are 
template. It forces the user to check it the function he wants to use is 
a template before trying to use it with something that implicitely cast 
to the function's argument type. This is a problem that can be avoided 
by trying to instanciate the template with types that the argument 
implicitely cast to.

Of course, as you stated, mess can arise, because you don't know right 
away what template instanciation is going to be used. But there would be 
much less mess than in C++. First, D has a more conservative approach to 
implicit casting than C++. If an implicit casting is used, it will be 
one that is visible in the type's declaration, and that the type 
implementer wanted. The problems would be much more controled than for 
C++. Second, D has powerful template guards. You can make sure the 
argument's type given to the template is a of a kind that will work 
correctly for this function.

I don't thing the mess would be huge. Particularly for enums, which are 
more manifest constants than specific types in D.

-- 
Christophe


More information about the Digitalmars-d mailing list