digitalmars.D - What's wrong with D ? this bug remains unfixed since 12 years
- Basile B. (16/16) May 30 Context:
- Timon Gehr (7/31) May 30 Counterpoint: Those examples work with my frontend.
- Paul Backus (12/19) May 30 D's IFTI implementation is really, really bad. If you stray even
- Basile B. (17/37) May 30 These issues are very specific to the D type system, for example
- Timon Gehr (17/27) May 31 I agree this should ideally work, but I am not sure I would call it a
- Paul Backus (16/35) May 31 In that case, the spec's section on lambda parameter type
- Timon Gehr (25/74) May 31 The pattern `T[]` is injective. The pattern `T.property` is not injectiv...
- Elias (0xEAB) (7/7) May 31 What’s wrong with D you ask? :P
- Basile B. (2/9) May 31 You `have` my `agreement`. It is a very `important` thing to get.
- Max Samukha (6/8) Jun 01 I recently learned that SQL, one of the worst languages
- Basile B. (4/13) Jun 01 No off-topic or extrapolation attempts please. I'm sorry if the
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). 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. A bon entendeur and sorry for the provocation ;)
May 30
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 ;) ...
May 30
On Thursday, 30 May 2024 at 13:10:54 UTC, Basile B. wrote:I have a theory that is "we all make the same mistakes" (i.e when it's time to implement, we the human beings). 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.D's IFTI implementation is really, really bad. If you stray even slightly from the "happy path" of conventional, idiomatic code, it completely falls apart. 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 - https://issues.dlang.org/show_bug.cgi?id=22111 - https://issues.dlang.org/show_bug.cgi?id=23292 - https://issues.dlang.org/show_bug.cgi?id=23645 - https://issues.dlang.org/show_bug.cgi?id=23644 I would not be surprised if a ground-up rewrite of the entire IFTI implementation was necessary to fix all of these issues.
May 30
On Thursday, 30 May 2024 at 18:09:34 UTC, Paul Backus wrote:On Thursday, 30 May 2024 at 13:10:54 UTC, Basile B. wrote:These issues are very specific to the D type system, for example I see problem related to type qualifiers. For the two old issues I mentioned the simple algorithm should work. You try to see how the AST of the parameter type and the argument type match. You decompose them in paralell. If at some point the decomposition of the parameter ends up on an identifier and that the identifier matches to a template parameter then it's likely that the ident matches to what the paralell decomposition of the argument type is at. Simple stupid. As said previously I think that the two bugs are not related to IFTI but to the scope used to run the typesem... hard to explain it better. In a world where it would be allowed to bet on software bugs I'd bet it's not a IFTI problem and that it's a scope problem. If you try to find something that doesn't exist in a scope you wont find it. Anyway 12 years ;)I have a theory that is "we all make the same mistakes" (i.e when it's time to implement, we the human beings). 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.D's IFTI implementation is really, really bad. If you stray even slightly from the "happy path" of conventional, idiomatic code, it completely falls apart. 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 - https://issues.dlang.org/show_bug.cgi?id=22111 - https://issues.dlang.org/show_bug.cgi?id=23292 - https://issues.dlang.org/show_bug.cgi?id=23645 - https://issues.dlang.org/show_bug.cgi?id=23644 I would not be surprised if a ground-up rewrite of the entire IFTI implementation was necessary to fix all of these issues.
May 30
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=22903Not a bug (no IFTI is involved).- https://issues.dlang.org/show_bug.cgi?id=22111I 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=23292Seems 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=23645https://dlang.org/spec/template.html#function-templatesIf 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#iftiFunction templates can be implicitly instantiatedSo 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=23644Here 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.
May 31
On Friday, 31 May 2024 at 07:40:09 UTC, Timon Gehr wrote:On 5/30/24 20:09, Paul Backus wrote: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-inferenceHere'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=22903Not a bug (no IFTI is involved).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=22111I agree this should ideally work, but I am not sure I would call it a bug per se.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=23292Seems 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=23645However, 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.)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.- https://issues.dlang.org/show_bug.cgi?id=23644Here I am again not sure whether there was ever any intention for this to work, but it should be fixed in any case.
May 31
On 5/31/24 14:01, Paul Backus wrote:On Friday, 31 May 2024 at 07:40:09 UTC, Timon Gehr wrote:Probably.On 5/30/24 20:09, Paul Backus wrote: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 ...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=22903Not a bug (no IFTI is involved).The pattern `T[]` is injective. The pattern `T.property` is not injective.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=22111I agree this should ideally work, but I am not sure I would call it a bug per se.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.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. ...- https://issues.dlang.org/show_bug.cgi?id=23292Seems my frontend gets this one wrong too, though technically I don't think the spec implies that this should work.[2] https://dlang.org/spec/module.html#name_lookupAFAICT, 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.[...]- https://issues.dlang.org/show_bug.cgi?id=23645However, 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.)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.- https://issues.dlang.org/show_bug.cgi?id=23644Here I am again not sure whether there was ever any intention for this to work, but it should be fixed in any case.
May 31
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
May 31
On Friday, 31 May 2024 at 21:39:54 UTC, Elias (0xEAB) wrote: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. /sYou `have` my `agreement`. It is a very `important` thing to get.
May 31
On Friday, 31 May 2024 at 22:39:28 UTC, Basile B. wrote:You `have` my `agreement`. It is a very `important` thing to get.I recently learned that SQL, one of the worst languages programmers are stuck with, was intentionally designed in that way to be accessible for non-specialists. We should not repeat that mistake. Let D remain a powerful tool for professionals designed by professionals.
Jun 01
On Saturday, 1 June 2024 at 07:12:19 UTC, Max Samukha wrote:On Friday, 31 May 2024 at 22:39:28 UTC, Basile B. wrote:No off-topic or extrapolation attempts please. I'm sorry if the topic lead to the idea that it was possible but essentially everything unrelated to IFTI is considered off-topic.You `have` my `agreement`. It is a very `important` thing to get.I recently learned that SQL, one of the worst languages programmers are stuck with, was intentionally designed in that way to be accessible for non-specialists. We should not repeat that mistake. Let D remain a powerful tool for professionals designed by professionals.
Jun 01