On 3/17/23 1:19 AM, Elfstone wrote:

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.

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 unsolvable. isInstanceOf is itself a template, and therefore cached. Per the D language rules, aliases cannot cause a different instantiation.

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.

This cannot ever work:

template identity(int i) { enum identity = i; }

void foo() {
    enum five = identity!5;
    static assert(is(five == identity!y, int y) && y == 5);
}

It cannot work because five does not lexically reference identity as a parent, because five is an int, and int is not a type that is or can be uniquely associated with the identity template.

But if we make it work for struct, it will work with every type (with a little extra boilerplate):

template identity(int i) {
   struct wrapper { int w = i; }
   enum identity = w;
}

void foo() {
    enum five = identity!5;
    static assert(is(five == identity!y, int y) && y == 5);
}

And with some new lowering we could even get rid of that boilerplate.
E.g. simply add the 'parent' property to the template parameters automatically if we detect that it is used in this way somewhere (but that may cost some compile time).

This cannot ever work:

template identity(int i) { enum identity = i; }

void foo() {
    enum five = identity!5;
    static assert(is(five == identity!y, int y) && y == 5);
}

It cannot work because five does not lexically reference identity as a parent, because five is an int, and int is not a type that is or can be uniquely associated with the identity template.

On Tuesday, 21 March 2023 at 07:51:50 UTC, FeepingCreature wrote:

template identity(int i) { enum identity = i; }

void foo() {
    enum five = identity!5;
    static assert(is(five == identity!y, int y) && y == 5);
}

Just to mention, even is(five) is false because five is not a type. So the static assert above would be false even if the pattern matching would succeed. (I have seen another D user say they thought that is can test a type instance - it can't). To match value patterns, another construct would be needed - perhaps a match expression.

OK, and it also wouldn't work with alias five = identity!5;. (If it wasn't an eponymous template, an inference expression could work with that).

On Saturday, 18 March 2023 at 01:15:35 UTC, Elfstone wrote:

To explain the mechanism:

The compiler knows what the template parameters are that are used to instantiate a struct that lives inside a template, because this information is stored with the struct. It can do this because - and only because! - the struct lives uniquely inside one particular template instantiation. That is, you can recover template parameters for precisely two cases, structs and classes:

template Foo(T) {
  struct Foo { }
}

You can do this because, and only because, the lexical parent of struct Foo is template Foo with a given T. Template parameter recovery works for types that have the property of uniquely storing a lexical parent; it does not work for any types that don't have this property.

This cannot ever work:

template identity(int i) { enum identity = i; }

void foo() {
    enum five = identity!5;
    static assert(is(five == identity!y, int y) && y == 5);
}

It cannot work because five does not lexically reference identity as a parent, because five is an int, and int is not a type that is or can be uniquely associated with the identity template.

What you want needs a fundamentally new language feature; something like typeclasses. Now there's an argument to be made to add typeclasses to the language, they would make ranges a lot more swanky for instance, but it's just not a matter of making template inference marginally more powerful.

On Saturday, 18 March 2023 at 01:15:35 UTC, Elfstone wrote:

To explain the mechanism:

The compiler knows what the template parameters are that are used to instantiate a struct that lives inside a template, because this information is stored with the struct. It can do this because - and only because! - the struct lives uniquely inside one particular template instantiation. That is, you can recover template parameters for precisely two cases, structs and classes:

template Foo(T) {
  struct Foo { }
}

You can do this because, and only because, the lexical parent of struct Foo is template Foo with a given T. Template parameter recovery works for types that have the property of uniquely storing a lexical parent; it does not work for any types that don't have this property.

This cannot ever work:

template identity(int i) { enum identity = i; }

void foo() {
    enum five = identity!5;
    static assert(is(five == identity!y, int y) && y == 5);
}

It cannot work because five does not lexically reference identity as a parent, because five is an int, and int is not a type that is or can be uniquely associated with the identity template.

What you want needs a fundamentally new language feature; something like typeclasses. Now there's an argument to be made to add typeclasses to the language, they would make ranges a lot more swanky for instance, but it's just not a matter of making template inference marginally more powerful.

I wouldn't call what I want a new feature, but a fix to this big hole in the language design (or implementation). People would expect an alias works the same as the original symbol, at least people need not care if they are using an alias from std (Regex), as long as the compiler will generate a warning where an alias might cause problems.

On Wednesday, 22 March 2023 at 07:25:04 UTC, Elfstone wrote:

Well, an alias works the same as the original symbol, that's rather the problem. You can't infer the template instantiation that produced the alias, because the compiler doesn't see the alias after the fact, because "an alias member" is not a lexical member in the same way that "a templated struct" is.

My opinion is that we're several steps into an X-Y problem here, where what we actually want is to indicate that a value fulfills a certain constraint - "is a vector" - in a more freeform fashion than template constraints allow us to, without having to write lots of isVector type predicates, in a way that's legible to the typesystem. I think something like type traits or typeclasses would fulfill this need in a cleaner way and also make a lot of range code better.