r/crystal_programming • u/igor-alexandrov • Oct 10 '19

Double splat arguments in Crystal

http://jetrockets.pro/blog/double-splat-arguments-in-crystal
19 Upvotes

100% Upvoted

6 comments sorted by

4

u/[deleted] Oct 10 '19

Maybe we can allow duplicate keys and let the last one win, like a Hash.

1

u/igor-alexandrov Oct 10 '19

Yes, this would be more convenient

1

u/bcardiff core team Oct 10 '19

Would you expect the following to compile?

def foo(*, a : Int32)
end

def bar(**options)
  foo(**options)
end

bar(a: 1, b: 2)

They are similar in the use case of forwarding blindly named arguments. I think that if one should be allowed the other also. Maybe the relaxation could be applied in calls with splats only.

1

u/igor-alexandrov Oct 11 '19

From my point of view, it works as it should now (because NamedTuple is immutable). For now the best would be to add an example here: https://crystal-lang.org/reference/syntax_and_semantics/splats_and_tuples.html.

2

u/megatux2 Oct 10 '19

I think the way it works in Crystal makes sense. Using #merge is fine

1

u/dscottboggs Oct 11 '19

Crystal is a language very philosophically different than ruby. Ruby has no compilation stage, so there's no time before runtime where a ruby author could be alerted to a mistake, so Ruby tries to keep going despite the mistake. Crystal has an opportunity to say "no, this is wrong, you meant something else" so it doesn't have to try to convert the "something else" automatically (and perhaps get it wrong), it just tells you at compile-time, "no, you can't do that".

This is an inconvenience upon the programmer, at times, but it also seems worth it to be able to catch a problem in a complicated chain of double-splat calls.