Does `is` expression with template alias need fixing.

[Elfstone]

On Friday, 17 March 2023 at 13:37:27 UTC, Steven Schveighoffer 
wrote:
> On 3/17/23 1:19 AM, Elfstone wrote:
>
>> Perhaps the compiler doesn't have to completely erase 
>> `Foo!float` before it can solve the equation? I don't know. It 
>> definitely looks easy to solve.
>
> It looks easy to solve, until you realize that the part that 
> has to solve it doesn't see the same thing.
>
> It's like trying to work backwards that a C preprocessor macro 
> was used after the macro is done rewriting the code.
>
> I get what you are saying, but there will always be an edge 
> where the compiler just can't figure it out, and so, some 
> confusion is going to happen.
>
>> Again the current behaviour is of no use to anyone, and the 
>> compiler lets the code pass without warning is not OK. 
>> Whenever someone use a template alias (which s/he may not know 
>> is an alias) in an `is` expression, or as a function 
>> parameter, it should report an error, or warning, whatever.
>
> It might be possible, it might not. The compiler *doesn't know* 
> that a template is an alias until it instantiates the template. 
> To us, reading the code, it is obvious. But internally it 
> doesn't store things that way.
>
>> 
>> SHOO's case is even more intolerable. Do you expect the user 
>> to care about the hidden fact that `Regex` is an alias, and 
>> `isInstanceOf` can't do its job because `Regex` is an alias, 
>> all because `is` doesn't work with template aliases?
>> 
>
> SHOO's case is even more unsolvable. `isInstanceOf` is itself a 
> template, and therefore cached. Per the D language rules, 
> aliases cannot cause a different instantiation.
>
> ```d
> alias Foo(T) = T;
> alias Bar(T) = T;
>
> pragma(msg, isInstanceOf!(int, Foo)); // Should this be true?
>
> // these are now cached, since they are equivalent to the first
> // Should the evaluation depend on which order you call these?
> pragma(msg, isInstanceOf!(Bar!T, Foo));
> pragma(msg, isInstanceOf!(Foo!T, Foo));
> ```
>
> -Steve

I'll perhaps try to read the compiler code someday, for now it 
sounds to me like a matter of whether people want to fix the bug 
or not, even if it involves fundamental redesign of the frontend, 
or an extra pass to scan for unresolvable cases by design.

The compiler must at some point know that Foo is an alias, and 
that a particular param of isInstanceOf will be expanded to 
something inside `is(...)`. Store that info if not already, 
report an error when Foo is passed to isInstanceOf.