I really like that this doesn't rely on the typed sigil of the file now 🎉

Does the VM behave differently if we define a block param or if we skip it? It's a little odd that we have to define a block param in order to declare that we don't accept one, and I wonder if there's any potential runtime overhead for this.

Does the VM behave differently if we define a block param or if we skip it?

Yes, defining and not using a block param slows the program down:

❯ hyperfine 'ruby unused_block_param.rb' 'ruby no_block_param.rb'
Benchmark 1: ruby unused_block_param.rb
  Time (mean ± σ):      2.379 s ±  0.043 s    [User: 2.287 s, System: 0.017 s]
  Range (min … max):    2.330 s …  2.457 s    10 runs

Benchmark 2: ruby no_block_param.rb
  Time (mean ± σ):      1.502 s ±  0.037 s    [User: 1.419 s, System: 0.015 s]
  Range (min … max):    1.447 s …  1.591 s    10 runs

Summary
  ruby no_block_param.rb ran
    1.58 ± 0.05 times faster than ruby unused_block_param.rb

unused_block_param.rb

# typed: true

def foo(&blk)
end

i = 0
while i <= 100_000_000
  foo
  i += 1
end

**no_block_param.rb**

```ruby
# typed: true

def foo
end

i = 0
while i <= 100_000_000
  foo
  i += 1
end

It's a little odd that we have to define a block param in order to declare that we don't accept one

You can declare and type this block parameter manually, but the user does not have to. All methods with signatures (including all those in # typed: strict files) whose method definitions do not declare block parameters and thus whose sigs don't provide a type for those block parameters will get an implicit T.noreturn type.

This test just proves that it's possible to write that annotation manually, if you wanted.

I wonder if there's any potential runtime overhead for this.

The thing I wonder is whether it's possible to have runtime overhead in a method that uses the block param.

In all my tests, whether or not you explicitly name the block parameter doesn't matter for performance, as long as you don't do something like blk.call.

If there is a slowdown in this case, that's a case against annotations, because the act of adding an annotation slows things down. This is a separate issue from this PR, but there are two options:

• Maybe it's sufficient to land the changes in this PR: Allow & to specify anonymous block parameter types #9768 (because you can't materialize a Proc object if the block parameter isn't a syntactically valid variable name.
• If that's not sufficient, maybe we could extend the spirit of those changes to allow specifying a type for "&": ... in the signature, even if the block parameter was omitted in the method def.

update It looks like there is overhead

❯ rg -A 1 def
yield_no_name.rb
3:def foo
4-  yield

named_but_yield.rb
3:def foo(&blk)
4-  yield

blk_call.rb
4:def foo(&blk)
5-  blk.call

The errors changing to being about NilClass values is a little misleading. Is there any way that we could catch these and give a more specific message?

We could, though if you don't pass a block to a method, the block parameter is nil at runtime.

The alternative I can think of seems overkill: we could LoadArg to a special type like Sorbet::Private::Static::NoBlock and attempt to catch uses of that type in dispatchCallSymbol. But it would leak into all calls to isSubType if we don't also guard all of those calls.

I will say that the "does not exist on NilClass" is at least much less confusing than the first version of this that I threw together, which left the type as T.noreturn... the dead code errors were very confusing (and it also caused problems with hover, because it would make code look dead, but the dead code errors would be silent).

I see you approved this, so I'm going to go ahead and land this, but if you have feedback async for how you think we should improve this lmk.