From: akr@... Date: 2018-09-17T05:22:22+00:00 Subject: [ruby-core:89037] [Ruby trunk Feature#14183] "Real" keyword argument Issue #14183 has been updated by akr (Akira Tanaka). I have an idea to separate positional arguments and keyword arguments without incompatibility. Basic idea is introducing an flag, keyword_given, which means the last argument is a Hash object which represent keyword argument. (The name, keyword_given, is inspired from block_given? method.) The flag will be true if method call uses k => v, k: v, "k": v or **h and all keys of the Hash object constructed from them are symbol. (I think hash separation is not good idea.) The flag is referenced by a new Ruby method (keyword_given?) and C level function (rb_keyword_given_p). This doesn't break anything because it just add new method (and new C function). This makes the confusion of positional/keyword arguments solvable. But I don't say the confusion is solvable easily (or by-default). Programmers must use the flag carefully. If we want to solve the confusion by default, we need to change method invocation behavior incompatible way. However positional/keyword separation by the flag makes possible to change behavior incrementally. If a method is changed to use keyword_given?, only the method is changed. We can discuss the situation about the actual method. If Ruby-level method definition/invocation behavior is changed (def m(h) end cannot receive m(:k=>0) for example), it affects many applications. However method definition/invocation behavior contains several points which can refer the flag. We can discuss how big/small incompatibility and how big/small benefits for each one. ---------------------------------------- Feature #14183: "Real" keyword argument https://bugs.ruby-lang.org/issues/14183#change-74064 * Author: mame (Yusuke Endoh) * Status: Open * Priority: Normal * Assignee: * Target version: Next Major ---------------------------------------- In RubyWorld Conference 2017 and RubyConf 2017, Matz officially said that Ruby 3.0 will have "real" keyword arguments. AFAIK there is no ticket about it, so I'm creating this (based on my understanding). In Ruby 2, the keyword argument is a normal argument that is a Hash object (whose keys are all symbols) and is passed as the last argument. This design is chosen because of compatibility, but it is fairly complex, and has been a source of many corner cases where the behavior is not intuitive. (Some related tickets: #8040, #8316, #9898, #10856, #11236, #11967, #12104, #12717, #12821, #13336, #13647, #14130) In Ruby 3, a keyword argument will be completely separated from normal arguments. (Like a block parameter that is also completely separated from normal arguments.) This change will break compatibility; if you want to pass or accept keyword argument, you always need to use bare `sym: val` or double-splat `**` syntax: ``` # The following calls pass keyword arguments foo(..., key: val) foo(..., **hsh) foo(..., key: val, **hsh) # The following calls pass **normal** arguments foo(..., {key: val}) foo(..., hsh) foo(..., {key: val, **hsh}) # The following method definitions accept keyword argument def foo(..., key: val) end def foo(..., **hsh) end # The following method definitions accept **normal** argument def foo(..., hsh) end ``` In other words, the following programs WILL NOT work: ``` # This will cause an ArgumentError because the method foo does not accept keyword argument def foo(a, b, c, hsh) p hsh[:key] end foo(1, 2, 3, key: 42) # The following will work; you need to use keyword rest operator explicitly def foo(a, b, c, **hsh) p hsh[:key] end foo(1, 2, 3, key: 42) # This will cause an ArgumentError because the method call does not pass keyword argument def foo(a, b, c, key: 1) end h = {key: 42} foo(1, 2, 3, h) # The following will work; you need to use keyword rest operator explicitly def foo(a, b, c, key: 1) end h = {key: 42} foo(1, 2, 3, **h) ``` I think here is a transition path: * Ruby 2.6 (or 2.7?) will output a warning when a normal argument is interpreted as keyword argument, or vice versa. * Ruby 3.0 will use the new semantics. -- https://bugs.ruby-lang.org/ Unsubscribe: