Issue #20405 has been updated by jez (Jake Zimmerman). There seems to be some revival of this in the context of type checkers, and Hiroya Fujinami graciously asked for my opinion on the Sorbet Slack. I'll chime into say this: One of the best parts of Ruby is how much freedom it gives you at runtime. DSLs! Metaprogramming! Reflection! The staggering flexibility Ruby provides at runtime has been key to its success. Relegating all type annotations to comments **deprives** all Ruby programs the chance to do something interesting _at runtime_ with the type annotations. This is why Sorbet uses `T.let(exp, Typ)` for type annotations: it lets people choose whether they want to also have these type annotations checked at runtime or to have the annotations be only static. Overwhelmingly we see that users of Sorbet adopt it because it allows for both static and runtime checking. Stepping back, inline comments are a useful language feature in general! Tons of languages support inline comments: they have intrinsic value regardless of whether people use them for type annotations. Don't take this as a vote against adding this feature which is useful on its own. But that being said: support is growing among Rubyists wanting to opt into type annotations in their Ruby code—look no further than the previous comments on this thread. Given that support, it's worth considering what a truly excellent solution to type annotations in Ruby would look like. We can learn from the evolution of other languages! For example, Python originally relegated type annotations to comments, only to run up against some **fundamental shortcomings**. Python's [PEP 526](https://peps.python.org/pep-0526/#rationale), which introduced first-class variable annotations, has a section listing shortcomings of the comment-based approach. The two most notable in my mind are:
- Since type comments aren’t actually part of the language, if a Python script wants to parse them, it requires a custom parser instead of just using `ast`.
- It’s impossible to retrieve the annotations at runtime outside of attempting to find the module’s source code and parse it at runtime, which is inelegant, to say the least.
That is: the PEP recognized the value of having access to type annotations directly in the VM itself—both for third-party tools that want to parse them, and for application code that wants to reflect on them at runtime. As much as I and basically everyone else **can't stand** Sorbet's `T.let` syntax, until there is something better directly in the Ruby VM, Sorbet will be forced to continue providing `T.let`. Parsing type annotations in comments is fundamentally a partial solution. For further context about the need for runtime type checking, I'd love if you would read my post titled [Past, Present, and Future of Sorbet Type Syntax](https://blog.jez.io/history-of-sorbet-syntax/). Discussion of first-class type annotation syntax for Ruby is off topic in a thread about inline comments, so I will withdraw from further discussion in this thread. But I would love to re-engage with the Ruby core team and the wider community elsewhere to discuss this. ---------------------------------------- Feature #20405: Inline comments https://bugs.ruby-lang.org/issues/20405#change-112984 * Author: nobu (Nobuyoshi Nakada) * Status: Open ---------------------------------------- I propose a new inline comment syntax. ```ruby p (| This is a comment (| and nested one |) /:|) (:|) #=> :| ``` -- https://bugs.ruby-lang.org/