Matz,
Very good keynote today. I enjoyed looking at some of the new features you
are playing around with. I was very existed about lvar_propagate, and am
hoping I can convince you to give it another chance :)

Here's why: In my ideal world, blocks behave transparently to the end user.
There would be no difference between:

if foo == bar
  # stuff
end

and

Util.if(foo == bar) do
  # stuff
end

For the most part, this works, and is why Ruby can have a for/in syntax that
appears to many new users as a special language construct when it in fact
only wraps a block. This ability is key to Ruby's power over other
languages, because frameworks and other utility libraries can add new
"language features" easily. Python, in contrast, is specifically *against*
this sort of power.

Adding lvar_propagate (along with restoring 1.8 constant lookup behavior)
would remove the one remaining roadblock to having blocks that are true
stand-ins for language features. In the context of current Ruby, I can see
why the functionality seems ugly, but consider what you have to do in Ruby
1.8:

x = nil
something do
  x = 42
end
# access x

I think this is *uglier* than:

something do
  x = 42
end
# access x

In particular, I think the fact that this functionality would allow you to
implement method versions of Ruby language features is a compelling reason
to do it. What's most interesting to me is that it doesn't appear to have
any obvious user-facing drawbacks. Since the functionality is not currently
available, the only potential breakage would be:

something do
  x = 41
end
# code that specifically expects "x" to raise an exception

which seems like enough of an edge-case as to be considered insignificant.

-- 
Yehuda Katz
Developer | Engine Yard
(ph) 718.877.1325