Why does D not have generics?

[Ola Fosheim Grøstad]

On Tuesday, 12 January 2021 at 14:45:36 UTC, Adam D. Ruppe wrote:
> The benefit of this is you have almost zero compile time cost 
> and runtime cost comparable to any other class. It avoids 
> template bloat in codegen that can be very significant in D.

I haven't looked very closely at Phobos, but it seems like it is 
a bit compile time heavy ("over complicated") compared to what is 
most useful ("most common usage"). Perhaps simpler library type 
semantics with less compile time load would help.

Regarding code gen, I thought LDC cached code gen and would avoid 
emitting the same code twice? If that does not work, then maybe 
one can bring the IR to a normal form such that more code will be 
recognized as equivalent?


> I'd love to have it as an option in D as well. There's a lot of 
> types that can use identical runtime code and just change 
> types. Not just classes, but like integer types too can be 
> identical and merged, const/immutable/shared/etc can be 
> identical and merged, and even other things with cast(void*) 
> can do it.

But we probably could fix this by designing libraries with 
reinterpret casting through (void*) if desired. The template 
itself does not generate any code.

I imagine we could sketch up an alternative std lib based on the 
most commonly used semantics that Phobos provides. It should of 
course work alongside Phobos so that people can transition/choose.

It does not sound like we need Java-style generics, to me, but I 
could be wrong.

Maybe your own lib could be a starting point for such an effort?


> Lots of potential for use inside druntime itself, changing the 
> existing void* + TypeInfo pairs into templates can mean no more 
> annoying typeinfo requirement... but then it causes runtime 
> bloat.

Ideally the runtime should not contain anything that not every D 
program uses...

Maybe some kind of auto-import would make it possible to slim 
down the runtime to basically nothing. Basically some kind of 
feature that lets certain syntax trigger an import in application 
code (but not in library code). You could config this for the 
project in a config file and basically choose e.g. what kind of 
string interpolation semantics you want for you application.


> Doing this in today's D comes close with inlined templates but 
> it is still far more expensive than it has to be and really 
> annoying to try to describe. A sum type definition in the 
> template that actually merges would surely help.

Not exactly sure what you meant by merging here? But if D is 
going to continue being GC based then a discriminating union type 
is needed, so that is an area that requires some rethinking (sum 
types, unions).

(I think the only thing that prevents fully precise collection is 
unions with traced pointers? And precise collection is needed for 
reliable GC based destruction/finalization.)