Generic inheritance is broken

[asterite]

Right now inheriting from generic types, and even inheriting a non-generic type that's not Reference is broken. There are many issues related to this, which I'll link here:

• Compiler problem in 0.16.0 with generics #2558 bug with generics inheritance
• class method returns one value, but is_a?(<this value>) contradicts. Can't debug #2376 mentions generics, the bug might be related to that
• Return type as generic base class is not allowed #2283 Return type as generic base class is not allowed
• How does macro inherited work with generics? #1793 How does macro inherited work with generics
• Bug with macro def and generic class inheriting non-generic class #846 Bug with macro def and generic class inheriting non-generic class
• Typing an instance variable as a generic module with specific type #2459 Can't type an instance variable as a generic module type
• Recursive alias does not match non generic subclass of generic type #1473 Recursive alias does not match non generic subclass of generic type
• Variance with generic parent class #1943 Variance with generic parent class
• Inheriting from generic class/struct ignoring the type causes segmentation fault #1944 Inheriting from generic class/struct ignoring the type causes segmentation fault
• Compiler error when subclassing HTTP::Handler with a generic class #2051 Compiler error when subclassing HTTP::Handler with a generic class

And one pending decision:

• Covariance and contravariance in generic types #1297 Covariance and contravariance in generic types

All of these should be fixed. The main issue is that the current implementation is very weak and needs a redesign. This is only a matter of time.

This issue will be used to mark all bugs related to generics as a duplicate of this one, because it's essentially one problem.

[asterite]

I'll keep this issue open for now, until we test it a bit more, but all or most of the bugs above are now fixed on master.

[benoist]

I'm not really sure about this example, should this work or not?

https://play.crystal-lang.org/#/r/1k1i

[spalladino]

@benoist what seems to be the problem in that example?

[benoist]

Ah sorry I should have explained it a bit better. I'd expected that adding 2 Int32Arrays it would also return an Int32Array. This is currently not the case

[spalladino]

Well, Array#+ is documented to return an Array, and not an instance of the same class that received the + message. As such, I'd not expect Int32Array to be returned in that example.

Anyhow, if you do believe it should, or have a similar issue, please open a new issue here; the idea of this one is to act as an "index" of generic-related stuff.

[benoist]

No I think I agree with you. If I want it to return a concatenation of self I should explicitly do so.
Thinking about it, inheriting from a generic is probably not a good idea anyway, composition is probably better.

[spalladino]

That's what I was going to suggest: either composition, or just declaring an alias if what you want is to have a friendlier name for a particular instantiation of a generic.

[ezrast]

Would further bug reports regarding generic inheritance be useful, or just noise at this point?

[RX14]

@ezrast Bug reports are always welcome

[Sija]

Could we strike through in description issues/prs which were closed/merged? /cc @asterite

[RX14]

This issue should be closed and made a project or label.

[miketheman]

#codetriage
This came up today.
It appears that all related issues pointed out here have been closed and released, so I'm recommending closing this issue.

[ezrast]

@miketheman, The kernel of the issue, that "the current implementation is very weak and needs a redesign", has not yet been addressed to my knowledge. Several related bugs remain in latest Crystal, such as #4059 (which was closed as a duplicate of this issue), #5290, and this:

module Base(T); end
module Derived; extend Base(Int32); end
arr = [Derived] of Base(Int32)
pp arr.first == arr.first # false
pp Derived == arr.first   # false
pp arr.first == Derived   # true

[RX14]

@ezrast please open as a seperate issue, that code shouldn't compile as Derived is Derived.class and Base(Int32).class. Derived.new wouldn't compile either, if it was a class and had a ctor that code would compile fine.

[miketheman]

Considering there's a new issue to track the Derived status, I think this issue could be closed.

[Sija]

@miketheman As far as I can see lot of issues have been closed (without resolution) in favor of this one, so it's kinda recursive situation. Closing this will leave 'em forgotten for the future.

[HertzDevil]

I reviewed every linked issue after #2665 (comment) and it seems the only ones that still break on master are #4086, #6760, and #10133. So once these are fixed I think we should close this meta-issue and rely on the kind:bug + topic:compiler:generics tags solely (or projects, but it seems nobody maintains them).

[straight-shoota]

I have re-opened those individual issues. It's probably easier to target them directly in upcoming PRs (in case a PR spans multiple, that works as well).