Any type system for Ruby objects that isn’t based on message/method response signature (i.e eigenclass), but instead relies on module ancestors (or worse, class), is fundamentally misaligned with the architecture of the language.
A remarkably high proportion of folks that self-identify as Ruby aficionados will make this error.
I’m not even talking about respond_to? / method_missing tricks. If an object prepends a module to its singleton to become a proxy for something else, or a library offers refinements (which are lexical) so its clients may declaratively align method expectations, or (bad style, looking at you Rails, but nevertheless) just evals whatever method definitions it likes after messing with the three implicit contexts, then it should still pass.
Leaning on class and mixin is just one of the ways in which Ruby object anatomy evolves, and although that’s a familiar default to many, there are other styles in common use, especially in framework/library code. Any app relying on such a framework may either not pass, or may silently bypass, such type checking. And I foresee a myriad of edge cases if one slings around closures as a habit (why, yes I do).
Symbolic message passing is the basis of object collaboration in Smalltalkish OO, and in Ruby class/mixin is merely one of the ways to get there. The conceptual gap means that what you get from oversimplification isn’t just a half-baked type system, it also becomes an incomplete straitjacket for style.
Edit to add: after reviewing the internals of this library, note that for a dash of irony, it is indeed prepending modules to class singletons to redefine methods with proxy wrappers. That is to say, it could not type-check itself.
It's not always a good thing, but I love Ruby's ability to define new runtime-valid syntax that looks pretty much native to Ruby itself.
def method(thing: String | "default value")
the pipe operator seems to be defined here, as just a regular method: https://codeberg.org/Iow/type/src/commit/aaa079bf3dd2ac6b471... the type gets picked out by the module included in the class you want typechecked, which reads the default value from all methods (which is the "real" ruby syntax here, where `thing` is assigned a default value of the result of calling `String | "default value"`) and uses that for type checking.
I like that over-flexibility... it's regularly too clever and makes it difficult to follow the flow of an application, but I like it all the same.
One can be creative here, but at the end of the day, a lot of what is generated, is just a waste of time. People love to tinker. Then they move on, often before having written any documentation. This is also a curse in ruby - people hate writing documentation. There is a reason ruby lost to python - over-tinkering and dislike of documentation are two smaller reasons.
They should integrate this to ruby-core and make it even better by changing the parser and making it faster in terms of performance, as optimized as it can.
But I have a hard time believing ruby-core will want to hear community feedback... people have been talking about this for ages... Ruby is omakase?
RBS and Sorbet suck. One is very limited, the other isn't part of ruby-core and makes you rewrite the function arguments again, similar to Java's annotations... Doesn't look like Ruby at all, or DRY, mostly like a workaround!
LowType is what it should have been -- hard to believe we are in 2025 and we still don't have a decent, programmer-friendly solution in ruby-core.
Meanwhile Python has it right since a long time. No wonder it is so stagnated with people going for other stacks.
Ruby is slowly becoming what Perl did, a very niche language.
Ruby needs a Typescript. Leave ruby-core as it is. Let us write Ruby with type annotations, where the compiler does type checking, strips the annotations, and leaves us with plain runnable Ruby.
I agree with your analysis that RBS and Sorbet suck.
I disagree that this here should be part of ruby-core, largely because I don't think any of this type madness should infiltrate ruby.
Ruby does not necessarily follow "DRY" - that appears to have been coined by either DHH or the pickaxe guys. More than one way to do it, is kind of orthogonal to DRY too. Note: I do not disagree that DRY has value. What I am saying is that ruby's design does not necessarily follow DRY as a guiding principle.
> hard to believe we are in 2025 and we still don't have a decent, programmer-friendly solution in ruby-core.
I do not think the year has anything to do with it. If they suck - and types suck - then they should not be in ruby core. I understand you have another opinion, but that's the beauty - we have orthogonal opinions there. One says must be part of ruby core; the other says should not be part of ruby-core ever, no matter the year.
> Meanwhile Python has it right since a long time.
The question is: how many use it there?
> No wonder it is so stagnated with people going for other stacks.
Lack of types aren't the reason ruby declined. That is a wrong assumption here.
> Ruby is slowly becoming what Perl did, a very niche language.
That is true, but not due to lack of types. Python without types would
still be at rank #1 at TIOBE for instance. Your analysis is simply wrong
here.
Mixed feelings here. Type annotations are a thing Ruby lacks, that other languages have, that I like using in other languages. Ergo, I'd like to have them in Ruby, right?
My knee-jerk reaction is "yes I'd like that" but when I pause to think about how I actually write Ruby code... hmm. I tend to use Ruby when its flexible syntax and type system are helpful. How much would I actually benefit from something that restricts the flexibility of the type system?
Bear in mind, I'm not a "Ruby dev" per se. It's a well-loved tool in my mostly firmware-focused repetoire. I use it for little CLI tools, and toy game engines too (mri embeds into C really cleanly). Fun little things that most folks would use Python for, I just like Ruby better.
I had exactly this reaction when gradual typing came to Python. "Do we really need this??"
But over time, I've grown to love it. Programming is communication—not just with the machine, but with other developers and/or future me. Communicating what types are expected, what types are delivered, and doing so in a natural, inline, graceful way? Feels a big win.
But you use types not to communicate with other people - you use them to give more hints to the python interpreter. Otherwise you could use comments. :)
type annotations in python are essentially structured comments with special syntactic support and runtime introspection facilities (i.e. you can get at the annotations from within the code). they are explicitly not "types" as far as the interpreter is concerned, you can say e.g. `x: str = 42` and python will be fine with it. the value comes from tooling like type checkers and LSPs that work with the annotations, and from metaprogramming libraries like dataclasses and pydantic that introspect them at runtime and use them to create classes etc.
Sure you could just use in-program comments and/or external annotation files. There were a handful of standards for doing exactly that... NumPy, Google, RST/Sphinx, Epydoc, Zope, ...probably a few others I'm forgetting. And there were external "stub" definition files like `.pyi`. Not exactly code, but closely-linked metadata. Ruby seems to be trying something like that with its `.rbs` files.
IME not until there was a sufficiently clean, direct, and common way to add typing (PEP 484 and its follow-ons) did the community actually coalesce, standardize, and practically start to use type information on a broad basis. We needed there to be one default way of sufficient attractiveness, not 14 competing, often incompatible, and rather inconvenient options.
You may look at built-in typing as a way to communicate with interpreters, compilers, type-checking and linting tools, and/or editor language support engines. Certainly the old purely static typing languages looked at them this way, out of necessity. The compiler, linker, loader, ABI chain has to know the bit-width of your objects, and pronto, because they're going right on the stack!
But in a highly dynamic language that doesn't strictly need types to run the code, typing works as much a signal to future me and my colleagues and collaborators as it is to any mechanism or tool. It signals structure and intent that we'd otherwise have to intuit or decipher. That some tools can use it too, just as they do in fully static languages, is great and useful but not the whole enchilada.
I think you're 110% on the nose. Types in Ruby really depends on the use-case. I don't think your use cases fit the bill and types would be annoying if anything.
I work on big Ruby on Rails monoliths and I curse every day that I don't have types to work with. It's almost a requirement for large refactors.
This sentiment reflect the type of project worked on - small ones. As projects get bigger, more type information gets lost, and that's why it needs to be compensated, typically via automated (unit) testing.
After having worked with gradual typing, unless the application is very disciplined, IMO automated testing is not enough to document the code, as Ruby makes it very easy to use flexible data structures which very easily become messy.
Ruby has had "officiak" type annotations since 3.0.0 via RBS.
Exactly because of the concerns you described, RBS originally used only separate files for the type annotations, so it can be selectively and gradually applied. You can add Ruby signatures inline as comments as well, but frankly both options looks ugly, and so does many of the alternatives like Sorbet signatures.
I love these new approaches to type checking such as this and Literal[1]. I think they really show how far we could go with runtime ruby syntax.
For both though I have questions:
A. How do I use this day to day to improve my tooling and developer experience?
B. If at some point in the future I decide to get rid of this how easy is it to eject?
I've seen too many adandoned dependencies over the years to trust anything I can't easily remove when it's time to upgrade.
These runtime typing efforts look nicer than Sorbet but, as far as I can see, you still have to have complete test coverage to trigger runtime checks if you want to spot correctness issues before you deploy into production.
Sorbet doesn't have that problem right now. Maybe something clever using Prism might be a way round that?
>These runtime typing efforts look nicer than Sorbet but, as far as I can see, you still have to have complete test coverage to trigger runtime checks if you want to spot correctness issues before you deploy into production.
I think you're right, and if that's the case, aren't these libraries (Lowtype, Literal) more akin to Design by Contract mechanisms?
This is super interesting. Is it possible to turn the runtime checks off in certain environments? I would love to have these type checks just happen during unit tests, for example, and then no-op in production so that performance is unimpacted.
A side comment: I love that this is on Codeberg. I'm seeing more and more projects migrating there or originating there to begin with, and it's awesome. (And I've been doing that as well.)
I built portrayal[1] (a much simpler replacement for those dry libs), and was also experimenting[2] with runtime-enforced types based on this lib.
My general thoughts is that declaring types in Ruby is unnecessarily complicated, because you're basically just running values through pieces of boolean logic, and nothing else. Might as well make that explicit, which is what my experiment did. I didn't however publish the types library, but the concept was proven.
I wrote this controversial thought[1] once, but for what it's worth, it applied to me just as much as to anyone else. Projects like these type gems are incredibly fun and satisfying to build. Your vision is clear, you've seen types before, you're proficient enough with Ruby to do clever things. The work seems cut out for you. Go nuts!
Problem is, these kinds of solutions (I also see this in "service objects" world) take Ruby away from you, and offer you a whole new vocabulary. With time I started appreciating libraries that avoid solving a problem that plain Ruby can solve, because Ruby is incredibly clear and concise already. If you leave more opportunities for people to write plain Ruby, you will solve everything with much less library code.
I think that's where the fun of building goes against the end developer experience. Builders love "owning" everything. E.g, "No, don't write `&&`, I have a special way for you to compose types!"
These are general thoughts, but I'm happy to get concrete with specific examples too.
It's an interesting approach. From my skim, the way it works:
1. Parse the files with a Ruby parser, collect all method definition nodes
2. Using location information in the parsed AST, and the source text of the that was parsed, splice the parameters into two lambda expressions, like this[1]:
"-> (#{method_node.parameters.slice}) {}"
3. Evaluate the first lambda. This lets you reflect on `lambda.parameters`, which will tell you the parameter names and whether they're required at runtime, not just statically
4. In the body of the second lambda, use the `lambda.parameters` of the first lambda in combination with `binding.get_local_variable(param_name)`. This allows you to get the runtime value of the statically-parsed default parameters.
This is an interesting and ambitious architecture.
I had though in the past about how you might be able to get such a syntax to work in pure Ruby, but gave up because there is no built-in reflection API to get the parameter default values—the `Method#parameters` and `UnboundMethod#parameters` methods only give you the names of the parameters and whether they are optional or required, not their default values if they are optional.
This approach, being powered by `binding` and string splicing, suffers from problems where a name like `String` might mean `::String` in one context, or `OuterClass::String` in another context. For example:
class MyClass
include LowType
class String; end
def say_hello(greeting: String); end
end
MyClass.new.say_hello(greeting: "hello")
This program does not raise an exception when run, despite not passing a `MyClass::String` instance to `say_hello`. The current implementation evaluates the spliced method parameters in the context of a `binding` inside its internal plumbing, not a binding tied to the definition of the `say_hello` method.
An author could correct this by fully-qualifying the constant:
class MyClass
include LowType
class String; end
def say_hello(greeting: MyClass::String); end
end
MyClass.new.say_hello(greeting: "hello") # => ArgumentTypeError
and you could imagine a Rubocop linter rule saying "you must use absolutely qualified constant references like `::MyClass::String` in all type annotations" to prevent a problem like this from happening if there does not end up being a way to solve it in the implementation.
Anyways, overall:
- I'm very impressed by the ingenuity of the approach
- I'm glad to see more interest in types in Ruby, both for runtime type checking and syntax explorations for type annotations
> how you might be able to get such a syntax to work in pure Ruby, but gave up because there is no built-in reflection API to get the parameter default values
Any type system for Ruby objects that isn’t based on message/method response signature (i.e eigenclass), but instead relies on module ancestors (or worse, class), is fundamentally misaligned with the architecture of the language.
A remarkably high proportion of folks that self-identify as Ruby aficionados will make this error.
I’m not even talking about respond_to? / method_missing tricks. If an object prepends a module to its singleton to become a proxy for something else, or a library offers refinements (which are lexical) so its clients may declaratively align method expectations, or (bad style, looking at you Rails, but nevertheless) just evals whatever method definitions it likes after messing with the three implicit contexts, then it should still pass.
Leaning on class and mixin is just one of the ways in which Ruby object anatomy evolves, and although that’s a familiar default to many, there are other styles in common use, especially in framework/library code. Any app relying on such a framework may either not pass, or may silently bypass, such type checking. And I foresee a myriad of edge cases if one slings around closures as a habit (why, yes I do).
Symbolic message passing is the basis of object collaboration in Smalltalkish OO, and in Ruby class/mixin is merely one of the ways to get there. The conceptual gap means that what you get from oversimplification isn’t just a half-baked type system, it also becomes an incomplete straitjacket for style.
Edit to add: after reviewing the internals of this library, note that for a dash of irony, it is indeed prepending modules to class singletons to redefine methods with proxy wrappers. That is to say, it could not type-check itself.
v1.3 will export to RBS and then you'll get static type checking too via Steep
So it will be like RBS-inline but with actual types in the code instead of comments? Cool!
It's not always a good thing, but I love Ruby's ability to define new runtime-valid syntax that looks pretty much native to Ruby itself.
the pipe operator seems to be defined here, as just a regular method: https://codeberg.org/Iow/type/src/commit/aaa079bf3dd2ac6b471... the type gets picked out by the module included in the class you want typechecked, which reads the default value from all methods (which is the "real" ruby syntax here, where `thing` is assigned a default value of the result of calling `String | "default value"`) and uses that for type checking.I like that over-flexibility... it's regularly too clever and makes it difficult to follow the flow of an application, but I like it all the same.
> it's regularly too clever and makes it difficult to follow the flow of an application
Too much magic means nobody can understand the code anymore.
Most people who design DSLs don't understand this. It's a problem in ruby - ruby's syntax is so flexible that one ends up with kind of dialects in it.
I have something to learn here. How would you redesign the DSL to be less magical?
Though the ability to arbitrarily create first class syntax is why Rails is Rails, my favorite use case is FizzBuzz as a property of Integers. YMMV.
One can be creative here, but at the end of the day, a lot of what is generated, is just a waste of time. People love to tinker. Then they move on, often before having written any documentation. This is also a curse in ruby - people hate writing documentation. There is a reason ruby lost to python - over-tinkering and dislike of documentation are two smaller reasons.
They should integrate this to ruby-core and make it even better by changing the parser and making it faster in terms of performance, as optimized as it can.
But I have a hard time believing ruby-core will want to hear community feedback... people have been talking about this for ages... Ruby is omakase?
RBS and Sorbet suck. One is very limited, the other isn't part of ruby-core and makes you rewrite the function arguments again, similar to Java's annotations... Doesn't look like Ruby at all, or DRY, mostly like a workaround!
LowType is what it should have been -- hard to believe we are in 2025 and we still don't have a decent, programmer-friendly solution in ruby-core.
Meanwhile Python has it right since a long time. No wonder it is so stagnated with people going for other stacks.
Ruby is slowly becoming what Perl did, a very niche language.
Ruby needs a Typescript. Leave ruby-core as it is. Let us write Ruby with type annotations, where the compiler does type checking, strips the annotations, and leaves us with plain runnable Ruby.
I agree with your analysis that RBS and Sorbet suck.
I disagree that this here should be part of ruby-core, largely because I don't think any of this type madness should infiltrate ruby.
Ruby does not necessarily follow "DRY" - that appears to have been coined by either DHH or the pickaxe guys. More than one way to do it, is kind of orthogonal to DRY too. Note: I do not disagree that DRY has value. What I am saying is that ruby's design does not necessarily follow DRY as a guiding principle.
> hard to believe we are in 2025 and we still don't have a decent, programmer-friendly solution in ruby-core.
I do not think the year has anything to do with it. If they suck - and types suck - then they should not be in ruby core. I understand you have another opinion, but that's the beauty - we have orthogonal opinions there. One says must be part of ruby core; the other says should not be part of ruby-core ever, no matter the year.
> Meanwhile Python has it right since a long time.
The question is: how many use it there?
> No wonder it is so stagnated with people going for other stacks.
Lack of types aren't the reason ruby declined. That is a wrong assumption here.
> Ruby is slowly becoming what Perl did, a very niche language.
That is true, but not due to lack of types. Python without types would still be at rank #1 at TIOBE for instance. Your analysis is simply wrong here.
Mixed feelings here. Type annotations are a thing Ruby lacks, that other languages have, that I like using in other languages. Ergo, I'd like to have them in Ruby, right?
My knee-jerk reaction is "yes I'd like that" but when I pause to think about how I actually write Ruby code... hmm. I tend to use Ruby when its flexible syntax and type system are helpful. How much would I actually benefit from something that restricts the flexibility of the type system?
Bear in mind, I'm not a "Ruby dev" per se. It's a well-loved tool in my mostly firmware-focused repetoire. I use it for little CLI tools, and toy game engines too (mri embeds into C really cleanly). Fun little things that most folks would use Python for, I just like Ruby better.
I had exactly this reaction when gradual typing came to Python. "Do we really need this??"
But over time, I've grown to love it. Programming is communication—not just with the machine, but with other developers and/or future me. Communicating what types are expected, what types are delivered, and doing so in a natural, inline, graceful way? Feels a big win.
But you use types not to communicate with other people - you use them to give more hints to the python interpreter. Otherwise you could use comments. :)
type annotations in python are essentially structured comments with special syntactic support and runtime introspection facilities (i.e. you can get at the annotations from within the code). they are explicitly not "types" as far as the interpreter is concerned, you can say e.g. `x: str = 42` and python will be fine with it. the value comes from tooling like type checkers and LSPs that work with the annotations, and from metaprogramming libraries like dataclasses and pydantic that introspect them at runtime and use them to create classes etc.
Sure you could just use in-program comments and/or external annotation files. There were a handful of standards for doing exactly that... NumPy, Google, RST/Sphinx, Epydoc, Zope, ...probably a few others I'm forgetting. And there were external "stub" definition files like `.pyi`. Not exactly code, but closely-linked metadata. Ruby seems to be trying something like that with its `.rbs` files.
IME not until there was a sufficiently clean, direct, and common way to add typing (PEP 484 and its follow-ons) did the community actually coalesce, standardize, and practically start to use type information on a broad basis. We needed there to be one default way of sufficient attractiveness, not 14 competing, often incompatible, and rather inconvenient options.
You may look at built-in typing as a way to communicate with interpreters, compilers, type-checking and linting tools, and/or editor language support engines. Certainly the old purely static typing languages looked at them this way, out of necessity. The compiler, linker, loader, ABI chain has to know the bit-width of your objects, and pronto, because they're going right on the stack!
But in a highly dynamic language that doesn't strictly need types to run the code, typing works as much a signal to future me and my colleagues and collaborators as it is to any mechanism or tool. It signals structure and intent that we'd otherwise have to intuit or decipher. That some tools can use it too, just as they do in fully static languages, is great and useful but not the whole enchilada.
I think you're 110% on the nose. Types in Ruby really depends on the use-case. I don't think your use cases fit the bill and types would be annoying if anything.
I work on big Ruby on Rails monoliths and I curse every day that I don't have types to work with. It's almost a requirement for large refactors.
This sentiment reflect the type of project worked on - small ones. As projects get bigger, more type information gets lost, and that's why it needs to be compensated, typically via automated (unit) testing.
After having worked with gradual typing, unless the application is very disciplined, IMO automated testing is not enough to document the code, as Ruby makes it very easy to use flexible data structures which very easily become messy.
Ruby has had "officiak" type annotations since 3.0.0 via RBS.
Exactly because of the concerns you described, RBS originally used only separate files for the type annotations, so it can be selectively and gradually applied. You can add Ruby signatures inline as comments as well, but frankly both options looks ugly, and so does many of the alternatives like Sorbet signatures.
In fairness: RBS sucks though. This one here is a bit better than RBS.
Completely agree with you.
For some reason some people want to slap down types onto EVERY language. I call them the type-o-maniacs.
I love these new approaches to type checking such as this and Literal[1]. I think they really show how far we could go with runtime ruby syntax.
For both though I have questions:
A. How do I use this day to day to improve my tooling and developer experience?
B. If at some point in the future I decide to get rid of this how easy is it to eject?
I've seen too many adandoned dependencies over the years to trust anything I can't easily remove when it's time to upgrade.
These runtime typing efforts look nicer than Sorbet but, as far as I can see, you still have to have complete test coverage to trigger runtime checks if you want to spot correctness issues before you deploy into production.
Sorbet doesn't have that problem right now. Maybe something clever using Prism might be a way round that?
1. https://literal.fun/
>These runtime typing efforts look nicer than Sorbet but, as far as I can see, you still have to have complete test coverage to trigger runtime checks if you want to spot correctness issues before you deploy into production.
I think you're right, and if that's the case, aren't these libraries (Lowtype, Literal) more akin to Design by Contract mechanisms?
[dead]
This is super interesting. Is it possible to turn the runtime checks off in certain environments? I would love to have these type checks just happen during unit tests, for example, and then no-op in production so that performance is unimpacted.
Yes, there's config "config.type_checking = false" to turn type checking off per environment
[dead]
A side comment: I love that this is on Codeberg. I'm seeing more and more projects migrating there or originating there to begin with, and it's awesome. (And I've been doing that as well.)
More please! =)
I love it, I liked what dry-initializer and dry-struct do, and I wanted something similar but simpler than RBS or Sorbet.
I tried once myself to implement something like lowtype, but without success.
I built portrayal[1] (a much simpler replacement for those dry libs), and was also experimenting[2] with runtime-enforced types based on this lib.
My general thoughts is that declaring types in Ruby is unnecessarily complicated, because you're basically just running values through pieces of boolean logic, and nothing else. Might as well make that explicit, which is what my experiment did. I didn't however publish the types library, but the concept was proven.
[1]: https://github.com/maxim/portrayal
[2]: https://max.engineer/portrayal-guards-poc
First time I hear about this, I really like your guard approach. It's just quite plain ruby.
I'd be interested in hearing your opinions on other runtime approaches like contracts.ruby, literal.fun and LowType of course.
Appreciate it.
I wrote this controversial thought[1] once, but for what it's worth, it applied to me just as much as to anyone else. Projects like these type gems are incredibly fun and satisfying to build. Your vision is clear, you've seen types before, you're proficient enough with Ruby to do clever things. The work seems cut out for you. Go nuts!
Problem is, these kinds of solutions (I also see this in "service objects" world) take Ruby away from you, and offer you a whole new vocabulary. With time I started appreciating libraries that avoid solving a problem that plain Ruby can solve, because Ruby is incredibly clear and concise already. If you leave more opportunities for people to write plain Ruby, you will solve everything with much less library code.
I think that's where the fun of building goes against the end developer experience. Builders love "owning" everything. E.g, "No, don't write `&&`, I have a special way for you to compose types!"
These are general thoughts, but I'm happy to get concrete with specific examples too.
[1]: https://x.com/hakunin/status/1960016559750914097
How often do they release new versions? Looking forward to the rbs integration
So, it's like Python? If only Ruby had something like Pydantic, too.
What's the advantage of using this over RBS?
It's an interesting approach. From my skim, the way it works:
1. Parse the files with a Ruby parser, collect all method definition nodes
2. Using location information in the parsed AST, and the source text of the that was parsed, splice the parameters into two lambda expressions, like this[1]:
3. Evaluate the first lambda. This lets you reflect on `lambda.parameters`, which will tell you the parameter names and whether they're required at runtime, not just statically4. In the body of the second lambda, use the `lambda.parameters` of the first lambda in combination with `binding.get_local_variable(param_name)`. This allows you to get the runtime value of the statically-parsed default parameters.
This is an interesting and ambitious architecture.
I had though in the past about how you might be able to get such a syntax to work in pure Ruby, but gave up because there is no built-in reflection API to get the parameter default values—the `Method#parameters` and `UnboundMethod#parameters` methods only give you the names of the parameters and whether they are optional or required, not their default values if they are optional.
This approach, being powered by `binding` and string splicing, suffers from problems where a name like `String` might mean `::String` in one context, or `OuterClass::String` in another context. For example:
This program does not raise an exception when run, despite not passing a `MyClass::String` instance to `say_hello`. The current implementation evaluates the spliced method parameters in the context of a `binding` inside its internal plumbing, not a binding tied to the definition of the `say_hello` method.An author could correct this by fully-qualifying the constant:
and you could imagine a Rubocop linter rule saying "you must use absolutely qualified constant references like `::MyClass::String` in all type annotations" to prevent a problem like this from happening if there does not end up being a way to solve it in the implementation.Anyways, overall:
- I'm very impressed by the ingenuity of the approach
- I'm glad to see more interest in types in Ruby, both for runtime type checking and syntax explorations for type annotations
[1] https://codeberg.org/Iow/type/src/branch/main/lib/definition...
> how you might be able to get such a syntax to work in pure Ruby, but gave up because there is no built-in reflection API to get the parameter default values
what I have done successfully here https://github.com/radiospiel/simple-service/blob/master/lib... is to install a TracePoint which immediately throws, and then call the method. The tracepoint then receives the value of the default arguments.
Not pretty, and I wouldn't run this in production critical parts of a system, but it works.
[dead]
Looks a bit python inspired.
Also looks awful - not as bad as RBS but awful still.