What's wrong with D ? this bug remains unfixed since 12 years

[Timon Gehr]

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.