On 5/30/24 15:10, Basile B. wrote:
> Context:
> 
> https://issues.dlang.org/show_bug.cgi?id=10228
> https://issues.dlang.org/show_bug.cgi?id=9024
> 
> You might have seen a recent post of mine, initially designed to speak about IFTI and tuples, where I explain that I have developed something similar to IFTI.
> 
> Turns out that, until yesterday, they failed too. Fixed them quickly:
> 
> https://gitlab.com/styx-lang/styx/-/commit/b026f923cf7619b795557e79ece969deaffcc326
> 
> I have a theory that is "we all make the same mistakes" (i.e when it's time to implement, we the human beings).

Counterpoint: Those examples work with my frontend.
(https://github.com/tgehr/d-compiler/)

> It's possible that actually for those two bugs, D IFTI works but after IFTI, the wrong scope is used, or-and that `resolve` is canceled too early.
> 
> I dont see how a mediocre language like styx can handle that while D still cant.
> ...

I guess different priorities and different allocation of focus and expertise. The desire to make template matching fast might have led to some shortcuts being taken. Have not actually worked with that part of the compiler so far though.

> A bon entendeur and sorry for the provocation ;)
> ...

On 5/30/24 20:09, Paul Backus wrote:
> Here's a list of just the bugs that I *personally* have found and reported in D's IFTI:
> 
> - https://issues.dlang.org/show_bug.cgi?id=22903

Not a bug (no IFTI is involved).

> - https://issues.dlang.org/show_bug.cgi?id=22111

I agree this should ideally work, but I am not sure I would call it a bug per se.

> - https://issues.dlang.org/show_bug.cgi?id=23292

Seems my frontend gets this one wrong too, though technically I don't think the spec implies that this should work.

> - https://issues.dlang.org/show_bug.cgi?id=23645

https://dlang.org/spec/template.html#function-templates
> If a template declares exactly one member, and that member is a function with the same name as the template, it is a function template declaration. 

https://dlang.org/spec/template.html#ifti
> Function templates can be implicitly instantiated
So I guess the spec needs updating too here. It contradicts itself:
https://dlang.org/spec/template.html#implicit_template_properties

However, I do think it is not obvious from the spec that IFTI should even work on function template templates. (Though it makes sense that it would.)

> - https://issues.dlang.org/show_bug.cgi?id=23644

Here I am again not sure whether there was ever any intention for this to work, but it should be fixed in any case.

Overall, I think this is an issue of incomplete spec as much as one of implementation quality.

On Friday, 31 May 2024 at 07:40:09 UTC, Timon Gehr wrote:
> On 5/30/24 20:09, Paul Backus wrote:
>> Here's a list of just the bugs that I *personally* have found and reported in D's IFTI:
>> 
>> - https://issues.dlang.org/show_bug.cgi?id=22903
>
> Not a bug (no IFTI is involved).

In that case, the spec's section on lambda parameter type inference [1] should be updated to clarify this.

[1] https://dlang.org/spec/expression.html#lambda-parameter-inference

>> - https://issues.dlang.org/show_bug.cgi?id=22111
>
> I agree this should ideally work, but I am not sure I would call it a bug per se.

If IFTI was unable to match the type `int[]` with the pattern `T[]`, nobody would doubt that was a bug. How is this different?

>> - https://issues.dlang.org/show_bug.cgi?id=23292
>
> Seems my frontend gets this one wrong too, though technically I don't think the spec implies that this should work.

I think the spec's section on name lookup [2] implies that this should work. There is nothing in the spec about IFTI or templates that implies any exception is made to the normal lookup rules in this case.

[2] https://dlang.org/spec/module.html#name_lookup

>> - https://issues.dlang.org/show_bug.cgi?id=23645
>
[...]
>
> However, I do think it is not obvious from the spec that IFTI should even work on function template templates. (Though it makes sense that it would.)
>
>> - https://issues.dlang.org/show_bug.cgi?id=23644
>
> Here I am again not sure whether there was ever any intention for this to work, but it should be fixed in any case.

Regardless of whether these are intended to work, I'd say the order-dependent behavior is a bug. But I do think it would be nicer to make them work in all cases than fail in all cases.

On 5/31/24 14:01, Paul Backus wrote:
> On Friday, 31 May 2024 at 07:40:09 UTC, Timon Gehr wrote:
>> On 5/30/24 20:09, Paul Backus wrote:
>>> Here's a list of just the bugs that I *personally* have found and reported in D's IFTI:
>>>
>>> - https://issues.dlang.org/show_bug.cgi?id=22903
>>
>> Not a bug (no IFTI is involved).
> 
> In that case, the spec's section on lambda parameter type inference [1] should be updated to clarify this.
> 
> [1] https://dlang.org/spec/expression.html#lambda-parameter-inference
> ...

Probably.

>>> - https://issues.dlang.org/show_bug.cgi?id=22111
>>
>> I agree this should ideally work, but I am not sure I would call it a bug per se.
> 
> If IFTI was unable to match the type `int[]` with the pattern `T[]`, nobody would doubt that was a bug. How is this different?
> ...

The pattern `T[]` is injective. The pattern `T.property` is not injective.

>>> - https://issues.dlang.org/show_bug.cgi?id=23292
>>
>> Seems my frontend gets this one wrong too, though technically I don't think the spec implies that this should work.
> 
> I think the spec's section on name lookup [2] implies that this should work. There is nothing in the spec about IFTI or templates that implies any exception is made to the normal lookup rules in this case.
> ...

What I mean is the spec says IFTI only works for function templates. Technically if you have an import in the template body there is no IFTI because it is not a function template.

Currently it seems IFTI only looks at the eponymous member's signature during IFTI. It does not look at any of the other declarations. It is also hard to analyze those declarations, because the template parameters are not yet known during IFTI.

It can also not work in the general case, because which module is imported may depend on template parameters. So now you are in a situation where you have to partially analyze the template body during instantiation.

I think if you allow arbitrary partial analysis, IFTI becomes undecidable. Therefore I think you would have to more clearly state what you expect to see in the specification rather than just assume if it does not work it is a bug.

I.e., I think as long as the spec does not explicitly state "imports of this or this shape are analyzed during IFTI", you cannot really say the implementation is "buggy", it just does not work the way you'd like it to.

> [2] https://dlang.org/spec/module.html#name_lookup
> 
>>> - https://issues.dlang.org/show_bug.cgi?id=23645
>>
> [...]
>>
>> However, I do think it is not obvious from the spec that IFTI should even work on function template templates. (Though it makes sense that it would.)
>>
>>> - https://issues.dlang.org/show_bug.cgi?id=23644
>>
>> Here I am again not sure whether there was ever any intention for this to work, but it should be fixed in any case.
> 
> Regardless of whether these are intended to work, I'd say the order-dependent behavior is a bug. But I do think it would be nicer to make them work in all cases than fail in all cases.
AFAICT, there is no specification for this particular interaction, but in `is` expressions the pattern has to come first too.

Anyway, this has at least some component of language design in it, it's not just bug fixing.

What’s wrong with D you ask? :P
Well, everyone keeps using abbr.s and specialist terms from compiler engineering to the extent where to avg. usr.’s supposed to undrstnd ’em as well.
That’s also what’s wrong with error messages of D compilers in particular.
/s