Issue #9999 has been updated by Josh Cheek.


**Regarding #1.**

> 1. Syntax of methods signatures

Matz says "optional typing should honor duck typing", which this hasn't discussed.

There is already a decent amount of code in existence which does optionally describe type information via documentation. It can't currently be turned on (as in actually acted on by verifying that the types described match reality).

It seems reasonable to me, then, to build on what people are already doing, and using the YARD documentation types (http://yardoc.org/types), here is that code analyzed and gemified (https://github.com/pd/yard_types).

Next, we'd have to decide, do you put that information in a params list, or before the sig like in normal docs? I'm going to advocate before the sig, because I suspect there is a potential for type information to become too verbose to fit nicely in the params list, and placing it before the sig is, again, closer to what people are already doing with docs.

If you like that idea, then the question becomes how to annotate it, is it additional Ruby syntax, or is it a new kind of magic comment? And again, I'll advocate a new kind of magic comment, because (1) it's closer to what people are already doing, (2) then this new feature becomes backwards compatible, because on older rubies it's just a normal comment (3) at this point, the implementation is so close to what documentation parsers are already doing anyway, that it might be possible for people's existing docs to suddenly become valid type verifications. Or, at the very least, they're incredibly close at this point.


**Regarding #3**

> 3. Implementation

I don't have a clue how leaving it up to a library would play out (ie, how well does this work for Python?) but I like that idea a lot. It would allow people to iterate on the capabilities provided in creative ways. Maybe it comes with a default Types::Off, but you can swap them out for Types::VerifyOnCall, allowing someone to swap them out for tests, or Types::CheckOnError, allowing them to turn off for prod, but then run type-checking if something blows up.


**A proposition: Interfaces**

I assume the purpose of this is to enable run-time type checking, which I'm not a big fan of, it seems like it would add a lot of overhead, and doesn't really feel like it can ever be correct -- in the sense that I probably can never adequately capture some types "takes an argument that implements :a, which takes 3 parameters and a block, a String, Fixnum, and something that responds to :to_s, but the String should have the additional method :status_code defined on its singleton class, which returns a Fixnum, and the block can take ...".

In other words, it seems like types need to capture the full path of everywhere that argument goes in code from this point forwards, and then also specify the param types and return types of every method we invoke. Unless we have an external definition that we are referencing back to, as is the case in your examples with `Stream r`. But that doesn't work for Duck typing, unless we also create interfaces.

Once we have interfaces, we could get useful things like:
1) Someone can specify this information much more tersely
2) Create test helpers like `assert_implements` for minitest, `expect(obj).to implement SomeInterface` for RSpec. Which would be super useful for anything that uses a plugin system with polymorphism. e.g. Capybara could turn Capybara::Driver::Base into such a thing (https://github.com/jnicklas/capybara/blob/304e2fbfe1e54702eb65f2a3feda1c7b9b99ff36/lib/capybara/driver/base.rb).
3) The potential exists to static type check everything. Well... at least in an incredibly large subset of code.

----------------------------------------
Feature #9999: Type Annotations
https://bugs.ruby-lang.org/issues/9999#change-48253

* Author: Davide D'Agostino
* Status: Assigned
* Priority: Normal
* Assignee: Yukihiro Matsumoto
* Category: 
* Target version: 
----------------------------------------
Hi all,

I know @matz is interested in introducing **type annotations** in ruby. More here: https://bugs.ruby-lang.org/issues/5583

I think it's time for ruby to get this.

Before working on a patch I would like to know:

1. Syntax of methods signatures
2. Syntax of variables guards (?)
3. Implementation

For point **1** I was thinking in some like:

~~~ruby
def connect(r -> Stream, c -> Client) ->  Fiber
def connect(Stream r, Client c) -> Fiber # quite sure this will make some reduce problems in the grammar
~~~

Before making a proposal consider: keyword arguments and default value collisions.

Then for point **2** I'm not sure if we want also check assignments but as before a syntax could be:

~~~ruby
r: Client = something # will throw an exception if something is not kind of Client
~~~

Finally, **implementation**. Do we want some in python style and then leave the programmer/library for the implementation **or** (and I'm for this) we want MRI do that, if so how?

Cheers!
DD

p.s. Sorry if this issue was already discussed but I didn't find anything except the link posted.



-- 
https://bugs.ruby-lang.org/