I much prefer separate files for type declarations. Or at least the ability to define them separately. Type annotation takes away from readability. I like keeping the types and code separate.
The upside of external files is pure incremental implementation that touches no other tooling and requires no buy-in.
I don't see how having to switch files to know that `input` is a `User` increases readability, though. It seems like straight-forward impl-simplicity trade-off, not one of user ergonomics.
That can be covered by the editor to give the user some hint by referencing the external file but for the user, having have to keep adding it on a separate file seems pretty annoying as you need to keep declarations synched in 2 files.
Also how do you type something in an inline function?
Separating type definitions from code can be considered as contributing to readability of idiomatic Ruby on one hand, and type definitions on the other, taken separately on their own—by not imposing constraints on either syntax.
IDEs will likely be able to seamlessly peek/go to RBS type definition on any Ruby identifier in any case.
Do you mean for Ruby specifically or in general? I've found that it's much easier to (safely, accurately) read, use, and extend e.g. a TypeScript file than its JavaScript counterpart, even when provided with a .d.ts file.
I don't disagree, but I think it's a very minor issue given that it's trivial to use color to highlight code these days. By comparison having to switch between two files (and keep them in sync!) when making changes is a far bigger usability concern.
Type annotations aren't inline in all languages. If you're writing Haskell or Elm, as a few examples, then you get static types without having to write them out and if you do write them out they sit above the function that uses them.
