Add NamedTuple#merge(other : NamedTuple)

[Papierkorb]

Hi,

Today in #crystal-lang a user required a possibility to merge two named tuples.
Their use-case was to call methods with named arguments from inside a RESTful API, while being able to easily set default values (or force other arguments to certain values).

Sample code

# Read arguments from user
args = NamedTuple(user: String, password: String).from(rest_arg_hash)

# Force the `server` argument to a value
call_args = args.merge(server: "auth.my-service.com")

# And easily call the actual method
authenticate(**call_args)

Using this, one can easily do dynamic invocation on methods, possibly backed by further user-defined macro magic ;)

Behaviour

Takes two named tuples (The other can be kw-args style, or a proper named tuple), and merges keys and values from both into a new named tuple. If both tuples define a value for the same key, the value from the other is kept.

Cya

[oprypin]

Please use {{k.stringify}} and not "{{k}}". I think this is not safe.

[makenowjust]

Also, please use {{k.symbolize}} and not :"{{k}}".

[need47]

I have been long waiting on this. Currently I have my own merge method. Glad to see it built-in stdlib.

[Papierkorb]

Now using stringify and symbolize

[sdogruyol]

I also had a similar case. Having a merge for NamedTuple would definitely help.

[asterite]

Duplicate of #2634

I think I prefer the implementation of #2634

[Papierkorb]

#2634 blows up if both tuples have a value with the same key.

[emancu]

@Papierkorb that was the main idea, I was trying to compose NamedTuples instead of merging them, so if you duplicate a key, it shouldn't compile.

In #2634 you can see a comment explaining why I discarded the merge function, however, I found really useful any implementation, so happy to see this merged :)

[Papierkorb]

@emancu I totally see the worth in both methods, and I'd like to see both merged.

[straight-shoota]

Actually I think there are three reasonable methods of combining two NamedTuples:

• merge: Creates a new NamedTuple type with the union of all keys. For the same key, values from one overwrite those of the other. Different types for the same key should either fail or combine them to a union type (?). The inversion should return the same NamedTuple type with possibly different values (iff keys are intersected). Add NamedTuple#merge(other : NamedTuple) #4688
• +: Creates a new NamedTuple type with the union of all keys. Fails if other and self share a key. The operation is commutative. Merge named tuples #2634
• update: Creates a new instance of self's NamedTupe type with values of self updated with those of other. other's keys need to be a subset of self's keys. Inversion is only valid if the key sets are identical. The behavior is similar to merge but it ensures that no additional keys are added and preserves the types from self. Add NamedTuple#update(other : NamedTuple) to merge values but keep type #4727

For update there is no PR yet and I don't think it has been proposed before. I am not sure if the key and type safety provided over merge adds much because mismatching types will either result in type errors elsewhere or shouldn't be to much of a concern.

[Sija]

@straight-shoota If I understand correctly there's no PR for update because NamedTuple is meant to be immutable.

[straight-shoota]

Of course it is. I'm sorry if this was misunderstanding, it would mean to create a new instance of the same NamedTuple type with updated values. I'll try to improve the wording on that.

[Sija]

@Papierkorb Would be sad to have this PR buried, so 🏓

[asterite]

@Papierkorb Could you re-format the source files? It's only failing because of that.

[Sija]

Redundant line.

[Papierkorb]

@asterite Ah shoot, I'm away from home this week-end. Would it be okay if I do it on Monday?

[asterite]

@Papierkorb Of course! Take your time :-)

[Papierkorb]

Like this? Or should I fixup the original commit?