How default parameters are interpreted when default values are empty hashes - ruby-on-rails

Question

I was reading this SO question: https://stackoverflow.com/a/4402761/2379703 and the last post showing the rails render impl was interesting. It's signature is:
def render(options = {}, locals = {}, &block)
If the first argument is a plain string, it assigns that to options and the rest is interpreted as a hash and assigned to locals. For example:
render('partial_name', key: 'value', key2:, 'value2')
Which results in:
options = "partial_name"
locals = {key: 'value', key2:, 'value2'}
If you just pass key/value pairs, it assumes you passed a single argument of a hash and assigns it all to options and leaves locals empty:
render(partial: 'partial_name', key: 'value', key2", 'value2')
Which results in:
options = {partial: 'partial_name', key: 'value', key2:, 'value2'}
locals = {}
So my question really comes down to is: What is the logic that ruby uses to figure out which parameter gets assigned what when there are multiple optional parameters? Furthermore, it seems that hashes make the answer to this question more interesting since hashes clearly don't need to be delimited with outer {} when passed in as arguments.
A secondary observation, in a test where I used the same signature for a test method like render, and I passed the following in:
render(key: 'value', key2: 'value2', 'string')
And that results in a syntax error:
test_hash_param.rb:15: syntax error, unexpected ')', expecting =>
Why is this? Why doesn't it assign the two key/value pairs to options and sets locals to 'string'?
However this works as I assumed it would:
render({key: 'value', key2: 'value2'}, 'string')

Answer 1

Firstly, you can only pass hash without {} brackets as a last argument to the method. Otherwise it would be much harder for interpreter to find out where does one param ends and another starts.
Having that said, when ruby sees a list of hash-like arguments at the end of argument list, it will always treat it as a single hash. Hence in your example only options have assigned value, as locals has not been passed and default value has been used. There are a lot of issue you can find here here on stackoverflow being result of that. If you need to pass two separate hashes, you need to wrap at least first of them in brackets (and naturally the second one as well if it is not the last argument)

Answer 2

because you're passing hashes without boundaries, ruby has to make decisions about how to interpret them. instead of picking an arbitrary place to divide your key:value pairs into two hashes, it will just group them all in one hash. that means:
render( foo: "bar", hello: "world", "bananas")
gets read as one hash, because it can't tell where you want to end the hash. 'bananas' gets included as a key(because strings can be keys) and pops a syntax error because you didn't assign it a value.
options and locals don't have to be hashes though, because ruby variable types are dynamic. their default value is an empty hash, but if you pass two strings, they'll both be assigned strings. when you pass one string, that gets assigned to options because it is a complete variable. when you pass a symbol/string and a hash rocket though(or a symbol with the colon flipped), you're telling ruby "this is the start of a hash" so it starts looking for key:value pairs. in order to end that hash before the end of your arguments so that you can pass another argument, you have to explicitly tell ruby to stop looking for key:value pairs.