Fallback 'catch-all' template functions

Meta via Digitalmars-d digitalmars-d at puremagic.com
Thu Sep 1 12:02:45 PDT 2016


On Thursday, 1 September 2016 at 18:24:13 UTC, Timon Gehr wrote:
>> The idea is that there'd only be one such "fallback" template, 
>> so that
>> you cannot get into a situation such as this. I'm guessing the 
>> ICE is
>> due to a recursive dependency between the two f templates?
>
> I posted the ICE to show that DMD does not necessarily have a 
> clear concept of how your code should be interpreted. Note that 
> you are essentially saying: "If not X then X". It's very easy 
> to run into behaviour that seems inconsistent once you do 
> things like this.

Well, I'd argue that's not quite right and the correct 
interpretation is "If not the other X then this X", due to the 
`!__traits(compiles, .f!T)`, explicitly telling the compiler to 
check if the *other* "overloads" compile. I don't actually know 
whether template constraints are considered to be at module scope 
or in the template scope, though, so maybe I'm completely wrong 
on this.


> enum isSomething(T)=false;
>
> int f(T)(T t) if(isSomething!T){
>     return 0;
> }
> int f(T)(T t) if(!compiles!".f!int") {
>     return 2;
> }
>
> enum compiles(string s) = __traits(compiles,mixin(s));
> pragma(msg, compiles!".f!int");         // false
> pragma(msg, __traits(compiles,.f!int)); // true
>
>
> DMD cannot properly process code like this (i.e. code that 
> contradicts itself, where the same expression in the same 
> context can be true in one part of the compilation, but false 
> later). Examples can be constructed where the semantics of the 
> resulting code depends on the order that modules are passed on 
> the command line. It's not specified anywhere what should 
> happen, and it is not immediately clear.
>
> DMD shouldn't accept code like this in the first place. It's 
> very brittle, the result depends on random compiler 
> implementation details.

I would argue that this is an entirely different case than my 
example, but we are getting into compiler implementation details 
that I know nothing about, so I can't actually say whether it is 
(or should) be valid code.




More information about the Digitalmars-d mailing list