Crystal: 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:

• #2558 bug with generics inheritance
• #2376 mentions generics, the bug might be related to that
• #2283 Return type as generic base class is not allowed
• #1793 How does macro inherited work with generics
• #846 Bug with macro def and generic class inheriting non-generic class
• #2459 Can't type an instance variable as a generic module type
• #1473 Recursive alias does not match non generic subclass of generic type
• #1943 Variance with generic parent class
• #1944 Inheriting from generic class/struct ignoring the type causes segmentation fault
• #2051 Compiler error when subclassing HTTP::Handler with a generic class

And one pending decision:

• #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.