search

crystal-lang / crystal

The Crystal Programming Language
https://crystal-lang.org
Apache License 2.0
19.41k stars 1.62k forks source link

Generic inheritance is broken #2665

Open asterite opened 8 years ago

asterite commented 8 years ago

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:

And one pending decision:

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 commented 8 years ago

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 commented 7 years ago

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

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

spalladino commented 7 years ago

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

benoist commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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

RX14 commented 7 years ago

@ezrast Bug reports are always welcome

Sija commented 6 years ago

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

RX14 commented 6 years ago

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

miketheman commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

@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 commented 6 years ago

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

Sija commented 6 years ago

@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 commented 3 years ago

I reviewed every linked issue after https://github.com/crystal-lang/crystal/issues/2665#issuecomment-244066238 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 commented 3 years ago

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).