Enable class templates? (Or any TypeDecl template)

[alexnask]

Looking through the cover template code, I noticed it is pretty simple and elegant and does not have anything cover specific.

It would be really easy to move it to TypeDecl and enable the syntax for classes (and enums? :P).

I feel like @fasterthanlime intentionally added it to only covers but I never saw any discussion on reasoning.

In my opinion, adding the option to build class templates would be ideal, allowing us to write performance critical code that extends and implements interfaces.

@fasterthanlime Amos, what do you think?

[fasterthanlime]

I think the type structure of covers was simpler, that's why I started with only that — plus classes already had generics, so we would've continued on with the typical "covers are light/fast/low-level/templates" vs "classes are heavy/flexible/high-level/generics" dichotomy.

That said if you can get it reliably working for both I don't see any reason why not!

[alexnask]

Good, I will take a look at it later!
I think it can be done pretty easily tbh

The real issue would be generic class templates (something like Foo: class <T> template <U> { ... }) but I'm fairly sure it would work with little to no changes (although I don't see why you would ever do it :P)

[fasterthanlime]

I think it can be done pretty easily tbh

famous last words! :)

[alexnask]

Haha I'm sure it will bite me in the ass but I don't see a reason why having an instance table + resolving accesses and types against templates would not work for a TypeDecl :)

[vendethiel]

I don't know enough OOC to know the difference between generics and templates?

[alexnask]

@vendethiel

Generics in ooc are reified.
This basically means that we have type/class information at runtime (the class field) and a generic function/collection "just" takes an array of bytes and a class object.
Then, you can compare classes at runtime and cast however you wish (if necessary).

Templates are C++ style templates (although only class templates and without SFINAE), which basically means you generate a new version of your type for every different combination of templates passed.

This leads to code-bloat but enables greater freedom and composition capabilities, as you can do arbitrary things with your arguments (for example, add a variable of templated type T and templated type U and let the compiler figure out if it is indeed valid when generating a new instance and giving T and U).
In C++, you can even have members of templated classes that do invalid operations (for example, add an int and a std::string), as long as you do not call them (members are only generated when called).
(This is basically what SFINAE means)

[alexnask]

You can look in the generated C code to understand how all of this works, with a bit of practice rock's output is actually readable (I would not recommend doing it if you have a headache though :P).

[vendethiel]

(This is basically what SFINAE means)

(No, not really. SFINAE is template overloading, what you described is just the "duck typed" nature of C++ templates)

Thanks for the information. I'm not sure I want to poke at generated C code, but maybe one day :P

[alexnask]

Yes, you are right, I thought that invalid operations on an expression of a templated type (or derivative) qualified as SFINAE too.

[refi64]

(This is basically what SFINAE means)

That would be deferred instantiation.

[alexnask]

I think I have a working version, at least simple cases seem to work fine (including generic class templates).

Will be adding a couple of tests in a bit.

[alexnask]

Never mind, cover template tests are failing (rock is crashing T_T)

[alexnask]

Closed by #965