Effectively blocks are self-contained chunks of code. You can change things around them, but you can’t change how keywords work inside them. Because you’re crossing a method boundary when you call a block you’re not able to access next and break. (Or capture return.)

Ruby is defining scope here and C methods are not limited by the language they define.

Assuming you don't care whether a "next" was actually called, but only whether you've exited the block and whether or not you exited it via a break, you can do this check in a number of ways, but it I will agree it's a bit dirty that sometimes you do need to rely on standard library functionality rather than language constructs if you want to do these things.

Here's one way of doing it, since "break" within a Fiber triggers a LocalJumpError:

    def next_or_break(&block)
      Fiber.new(&block).resume
      :next_or_end_of_block_reached
    rescue LocalJumpError
      :break
    end

    p(next_or_break do next end)
    p(next_or_break do break end)

One way to think of about it is this: anonymous functions as originally implemented in early Lisps are code as an object, closures are code with its lexical environment as an object. You can think of a Ruby block as code with its lexical environment and its call stack as an object.

So they don't just handle return differently than closures, they have access to the call stack of the site where they're created like a continuation. This is why they handle return differently, but this is just one of the things that falls out from that. It also comes with other control flow features like "redo", "retry", "next", "rescue", "finally", and others. These are all call stack control (control flow) conveniences, just like return is. All of them can be thought of as being abstractions built on top of continuations (just ask a Scheme hacker).

Originally Ruby was basically a Lisp without macros, but with continuations, a Smalltalk like object system and a lot of syntactic affordances inspired by Perl, and other languages. Blocks are one of the conveniences built on top of the Lispy semantics.

Note that I'm explaining how blocks work as an abstraction (vidarh below explains how they work as a concretion, as implemented in MRI).

I think the "Building an intuition" section of my blog post[1] makes a good case for that.

  When dealing with loops, you have 3 nested constructs interacting: a wrapping function, a loop statement and the loop's body; and you have 3 keywords to choose where the flow of the code goes.

    return returns from the wrapping function
    break leaves the loop statement
    next / continue leaves loop's body

  When dealing with blocks or anonymous functions, it's instead 3 nested "functions" that are interacting: a wrapping function, a called function and an anonymous functions (or block).

    Ruby's blocks, let you use the same 3 keywords to choose where the flow of the code goes.

    return returns from the wrapping function (ex: my_func)
    break returns from the called function (ex: each, map)
    next returns from the block

  Quite consistent. But since we are talking about functions instead of statements (loop), return values are also involved. Allowing both break and next to provide a return value fits well in that model and is quite useful. The 3 keywords are basically return, but they have different targets.

What is the edge case? It seems to be there so that Ruby enumeration methods can provide the behavior expected of looping statements (which is kind of necessary if you want the looping statements to just be semantic sugar for enumeration methods so that they can work correctly with any enumerable.)

> Blocks should be nothing special.

"Special" compared to what?

Yes, you can. That's what ensure (the Ruby equivalent of "finally") is for. Or, better using File.open with a block where you do the work, which uses ensure under the hood.