Issue #20063 has been updated by zverok (Victor Shepelev). It seems that the difference is not in whether they are required or optional but rather in "the second default evaluates even if the first one is already evaluated." ```ruby p example_with_optional(1, 2) #=> 1 ``` So when they are passed explicitly, the first assignment "wins." But when there are defaults, it seems that "what statements should be evaluated" is decided before the call (so when going to the second `_a`, it doesn't "see" that the variable doesn't need a default anymore, and just evaluates the second statement like an assignment): ```ruby def example_with_optional(_a = begin; puts "a1"; p binding.local_variables; 1 end, _a = begin; puts "a2"; 2 end) _a end # Prints: # a1 -- first block is called # [:_a] -- we already have a local var # a2 -- the second block is invoked nevertheless # 2 -- the result ``` I don't have a good mental model of what happens with explicitly passed arguments, though :) "Intuitively" it seems that it should be evaluated as two subsequent assignments to the same name, so the 2 should "win". ---------------------------------------- Bug #20063: Inconsistent behavior with required vs optional parameters https://bugs.ruby-lang.org/issues/20063#change-105665 * Author: jemmai (Jemma Issroff) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Using repeated anonymous parameters, gives different behavior with the parameters in the same order based on whether they are required or optional. ``` def example_with_optional(_a = 1, _a = 2) _a end def example_with_required(_a, _a) _a end p example_with_optional # 2 p example_with_required(1, 2) # 1 ``` It is unexpected that these two methods would return differently given the parameters are in the same order, based on whether they are optional or required. -- https://bugs.ruby-lang.org/