Return types of implemented abstract methods are not enforced by compiler, why?

Hello! I am confused a little about return types of abstract methods, simple example:

abstract class Base
  abstract def something : String
end

class Descendant < Base
  def something
    123
  end
end

puts Descendant.new.something

Playground: https://play.crystal-lang.org/#/r/772l

Why the compiler doesn’t push me for a bad return type of method “something” in Descendant class? Thanks!

This is a known issue, https://github.com/crystal-lang/crystal/issues/3546

1 Like

Adapt to the compiler’s standards, not the other way around. Time is gold, don’t waste it!

I understand that different return types will be detected in another places in the code by the compiler - OK, I am almost comfortable with this.

It’s a fairly frequented question/issue on the github.

So, writing return types is completely waste of time, right? Maybe documentation purposes? What is better then, write return types in abstract methods as documentation purposes, or suggest return types with meaningful method names - like: abstract def name_string ? I am just not sure what is the right way in Crystal.

It’s just a missing feature but I don’t know to implement it correctly.

But maybe, who knows, one of these days I send a PR to implement it.

1 Like

Like this one ;-)

6 Likes