On Wednesday, 14 May 2025 at 22:30:27 UTC, Dennis wrote:
> On Wednesday, 14 May 2025 at 16:41:44 UTC, Sebastiaan Koppe wrote:
> Fair enough, but could the dip support it, or perhaps in the future? The fact that we both expected it was a constructor - and you could argue it actually is, on the grounds that it does in fact construct an object - suggests more users would expect it to work.
It could be added, but there's something to watch out for: as the DIP specifies, the search for constructors in a template is shallow, so just because the search didn't find one, doesn't mean there is none. I'm imagining a scenario where a constructor is hidden behind a mixin / static if or whatever, so Implicit Template Instantiation would assume a generated 'default constructor', but after the instantiation it ends up calling the written constructor instead but with template parameters resolved incorrectly. Granted, that might also happen when a 'hidden' constructor exists with a stronger match than the constructor found for IFTI, so I'm not sure. Perhaps an extra check can be added that the constructor used for deriving template parameters is the one that ends up actually being called, but it's getting rather complex.
Simple things ought to work.
D’s templates, contrary to C++’s templates, are extremely flexible. Without actually instantiating them, you can’t really know what’s going to be in there. To assess if an instantiated template won’t have a constructor explicitly defined, the language rules must do a conservative guess. It’ll never good enough for some, but pretending this isn’t possible won’t make people happy either.
What can be done
A lexical analysis can look for a constructor. This is quick and cheap. Contrary to semantic analysis, lexical analysis can see through static if, version, and debug. It can also see if there’s any mixin template or a string mixin. If s string mixin is present, things get really difficult. ITTI cannot assume the template instance (the type) has an implicitly defined constructor. Since we’re inferring the arguments from a constructor call, we need to know which constructor it will be, and it won’t be the implicitly defined one if it won’t exist.
Mixin Templates
The same kind of lexical analysis can examine mixin templates and show that it can’t possibly add constructors. Then, instantiating the the mixin template is fine, even if it’s instantiated using some of the struct template’s type parameters.
String Mixins
Here, semantic is needed to examine it. One option is to synthesize a new template with only the string mixin present, instantiating all type parameters with the internal __error__ type and try running the string mixin. If it succeeds without error and doesn’t add a constructor, it won’t do so in the original struct template.
That might be too expensive to run, though.
Version and Debug
If I’m not mistaken, version and debug cannot depend on template arguments, so it can be decided which branch they take. If that excludes a the only constructors defined, the template instance definitely won’t have any even if they’re lexically present.
Static If
A deeper analysis might be able to show that the static if condition or the mixin stuff doesn’t depend on the struct template’s arguments. That is only relevant if one branch defines a constructor or has a string mixin and the other does neither.
In that case, we can employ an approach similar to the one for string mixins.
Permalink
Reply
