yes, though it's basically an optional argument hash. AFAIK, you can't do required named arguments without weird hacks, or specifically checking the arguments. For example:
irb(main):007:0> def foo(bar: bar, baz: Object.new); [bar, baz]; end
=> nil
irb(main):008:0> foo(bar: 1)
=> [1, #<Object:0x007fcaa40db4e0>]
irb(main):009:0> foo(baz: 1)
NameError: undefined local variable or method `bar' for main:Object
from (irb):7:in `foo'
from (irb):9
from /Users/aaron/.local/bin/irb:12:in `<main>'
irb(main):010:0>
This hack makes the "bar" parameter required, but only because the value is evaluated when the method is called, and you get a NameError (rather than an ArgumentError).
I run edge ruby against rails daily. The main incompatibilities I've hit in Ruby 2.0 are what methods respond_to? searches (I've blogged about that here: http://tenderlovemaking.com/2012/09/07/protected-methods-and... ), and the `Config` constant has been removed (which is sometimes an issue for C extensions).
EDIT
Just thought of this for the required args:
irb(main):001:0> def foo(bar: (raise ArgumentError), foo: Object.new); [bar, foo]; end
=> nil
irb(main):002:0> foo(bar: 1)
=> [1, #<Object:0x007fc65a882f48>]
irb(main):003:0> foo(foo: 1)
ArgumentError: ArgumentError
from (irb):1:in `foo'
from (irb):3
from /Users/aaron/.local/bin/irb:12:in `<main>'
irb(main):004:0>
You could probably define a private method like `required` or some such, like this:
irb(main):001:0> def required(name); raise ArgumentError, "missing param: %s" % name; end
=> nil
irb(main):002:0> def foo(bar: required(:bar), foo: Object.new); [bar, foo]; end
=> nil
irb(main):003:0> foo(bar: 1)
=> [1, #<Object:0x007fcfea143338>]
irb(main):004:0> foo(foo: 1)
ArgumentError: missing param: bar
from (irb):1:in `required'
from (irb):2:in `foo'
from (irb):4
from /Users/aaron/.local/bin/irb:12:in `<main>'
irb(main):005:0>
So it's syntactic sugar? What a shame. The whole point is having the language handle it so its default behavior is well-known and uniform and not implement umpteenth patterns and validations[0].
Well, it does actually define locals. But, IIRC, it uses the symbol hash parsing productions, so the default values are required. The only way to specify required parameters (without the above hacks) is to do a traditional method definition:
irb(main):001:0> def foo(bar, baz: Object.new); [bar, baz]; end
=> nil
irb(main):002:0> foo(1)
=> [1, #<Object:0x007fbc39161ed8>]
irb(main):003:0> foo(1, baz: 10)
=> [1, 10]
irb(main):004:0> foo(baz: 10)
ArgumentError: wrong number of arguments (0 for 1)
from (irb):1:in `foo'
from (irb):4
from /Users/aaron/.local/bin/irb:12:in `<main>'
irb(main):005:0>
Agree with you. Didn't we learn from C++ that multiple inheritance is good in theory but in practice a horrible idea? Ruby already lets you be 'magical' in too many ways.
> Didn't we learn from C++ that multiple inheritance is good in theory but in practice a horrible idea?
No, we learned from C++ that C++ multiple inheritance is an atrocity. Python's MI works in a clear and obvious way, similar[0] to how the Ruby inheritance chain is clear and obvious. MI really doesn't fit Ruby though, and IMHO would look too bolted on.
Most of the time the problem is people beating the platform they develop on into submission, instead of embracing it by getting a clear picture of what happens.
[0] As _why said[1], python and ruby are damn close: you can easily get something similar to Ruby's modules and inject them dynamically in the inheritance chain: https://gist.github.com/3951273
Magic is bad, but multiple inheritance isn't magic; it's clear and obvious, the only potential wrinkle being method resolution order when two superclasses define the same method, which is fine as long as it's consistent and documented.
Almost all of the problems with multiple inheritance in C++ are to do with the static type of an instance, and go away in a language where everything is virtual by default, as in ruby.
Sometimes you want to express multiple is-a relationships at the same time. In that case, composition is a hack, and multiple inheritance is a better match for the concept.
I prefer having more options how my objects behave than fewer.
But, since Ruby 2.0 does not and will not have multiple inheritance, this is all off-topic.
I believe this also includes the bitmap marking GC changes which will make the GC copy-on-write friendly. This is pretty important for a lot of folks running Ruby web servers.
How is "Ruby 2.0.0 feature freeze" an inaccurate title?
I ask because it has been common to use that terminology with Python releases for as long as I can remember, as well as with other projects I've worked on or am familiar with. We would have said the CPython 3.3.0 feature freeze was in June, with the final release happening last month.
Btw, slightly misleading title. It kind if implies that 2.0.0 is out.