Question to seek clarification on the definition of "..." in type signatures

Hi! I have a question regarding ..., specifically relating to https://github.com/ruby/rbs/pull/2540 / https://github.com/ruby/rbs/issues/1293

Prior to seeing this, I thought that:

• ... is used to denote overloaded method type signatures in the same class/module
• Overriding a type signature from a class or module overwrites the parent signature, and it is no longer possible to reference it

After seeing this, I realise I possibly didn't understand ..., as it looks to me that:

• ... is also used to denote "defer to the parent type signature", similar to the super keyword in Ruby
• ... only denotes super if there are no real method overloads

Take the following examples:

module Foo
  def call: -> Integer
end

class Example1
  include Foo
  def call: -> Float | ...
end

class Example2
  include Foo
  def call: -> Float | ... 
end
class Example2 # Overload/re-open
  def call: -> Symbol
end

It looks to me (by RBS and Steep) that:

• Example1 uses ... to denote "super", and has type -> Integer | -> Float
• Example2 uses ... to denote "overload", and has type -> Float | -> Symbol

I think that it would be great to hear what the intention of ... is, but I'll also just mention a couple of my thoughts on it:

• It feels problematic to me that a library may wish to use ... to denote super, but then the super functionality can be overridden if a user of the library adds an actual overload of the method signature.
• Re-using ... to denote super could lead to confusion when reading type signatures - it is no longer clear whether this means the type signature is overloaded, or whether it is referring to super, especially if you have to know/understand if there are any re-openings of the class/module.
• I think having a separate syntax for super may be better here for behaviour and readability

Thanks :)

Start by reading pull request #2540 and issue #1293, then compare their discussion with the Example1 and Example2 signatures in this issue. Done means reaching an explicit resolution of whether ... denotes inherited signatures, overloads, or both, and whether the behavior or its documentation needs clarification.