[Issue 21065] the new operator should lower to a template function call in object.d

d-bugmail at puremagic.com d-bugmail at puremagic.com
Thu Jul 23 02:02:41 UTC 2020


https://issues.dlang.org/show_bug.cgi?id=21065

--- Comment #2 from Andrei Alexandrescu <andrei at erdani.com> ---
(In reply to Mathias LANG from comment #1)
> Regarding your proposed implementation:
> 
> > T __makeClassObject(T, A...)(auto ref A);
> 
> This would have the effect of producing a potentially large amount of
> template instances, as the `auto ref` variadic will match the parameters
> *exactly* - something we don't really want, e.g. when instantiating `class
> Foo { this (int) {} }` and passing `short`.

Not to worry about that at all - the instantiations are limited by the number
of calls to new in source code, which is a small fraction of the code in the
project. (In the Pool pull request, __FILE__ and __LINE__ are part of the
instantiation so literally there's one instantiation per use.) So we're looking
at hundreds to thousands. By comparison recursive templates are liable to
generate orders of magnitude more.

> Additionally, with this change the implicit conversions don't work anymore
> (e.g. passing `ulong.init` will give it a `ulong` which will error when
> attempting to implicitly convert it to `int`).

Hmmm, this would be a problem. Can you please explain a bit?

> What I found to be working very well when doing this kind of forwarding was
> to instead *generate* an overload set and let the compiler do the heavy
> lifting for me. In this case, the definition would become:
> 
> > template __makeClassObject (T)
> 
> And have multiple `__makeClassObject (args)` functions defined in it, each
> one accepting exactly the parameter of one constructor definition.
>
> Alternatively, just leave the initialization where it currently is (the
> compiler) and just templatize `newclass` to sidestep this issue.

As a matter of principle, the more compiler magic we need the more problems
with the language we're sweeping under the rug. Both of these seem to be in
that category.

All high level constructs should lower to a small core language of data
structures and functions.

--


More information about the Digitalmars-d-bugs mailing list