This is useful for default options. You merge a named tuple with the default values for some options with the user provided values for some of them.

I would prefer a merge method for this instead of +. The problem is that addition is commutative, and a merge is not. This gives the false impression that it will be commutative.

By the way, this implementation does not work in cases where the two tuples have the same key (those are the ones where commutativity is broken)

{a: 1, b: 2} + {b: 3, c: 4}  # compile error. expected:  {a: 1, b: 3, c: 4}

I don't know how to implement this.

I'm not sure about the default values usecase, normally you would

def foo(*, a = 1, b = 2)
end

@lbguilherme the main intention was to compose NamedTuples and add well defined pairs and keep the immutability.

This is useful for default options. You merge a named tuple with the default values for some options with the user provided values for some of them.

As @jhass mention, you probably want to use the following snippet for default values

def foo(*, a = 1, b = 2)
end

I would prefer a merge method for this instead of +. The problem is that addition is commutative, and a merge is not. This gives the false impression that it will be commutative.

I prefer the merge method too, but I discarded that name because:

• Tuple already defines a + and I wanted to keep the same API
• Using merge may confuse you with the Ruby method, where you can override values or mutate the object
• The false impression of commutative you mention

By the way, this implementation does not work in cases where the two tuples have the same key (those are the ones where commutativity is broken)

I know and that is expected. You can't define NamedTuples repeating a key neither.
I'm not trying to make NamedTuples behave as a Hash.

The reason that I was looking for a method like this is that I'm writing an ORM where the attributes are stored as a NamedTuple instead of a Hash.
I'm still working on that code, but I got stuck because the lack of this feature (or my programming skills ^^)

Here is an example of the code using this cool feature and why I want it.

def save
  @attributes = {name: "emancu", profession: "programmer"}

  id = DB.persist @attributes

  @attributes = {id: id} + @attributes
end

But that creates a union of named tuples, which you won't be able to splat later. I think hashes are more suitable for this use case.

Note that I'm not against merging named tuples, and I think it can even be done if keys repeat, I'm just not sure named tuples should be used in places where a Hash is more useful.

@asterite You are right, maybe that is not the best code example.

Here's an implementation that preserves the values on the other merged named tuple.

Code:

struct NamedTuple
  def self.new(**options)
    options
  end

  def merge(other : NamedTuple)
    merge_implementation(other)
  end

  private def merge_implementation(other : U)
    {% begin %}
      NamedTuple.new(
        {% for key in (T.keys + U.keys).uniq %}
          {% if U.keys.includes?(key) %}
            {{key}}: other[:{{key}}],
          {% else %}
            {{key}}: self[:{{key}}],
          {% end %}
        {% end %}
      )
    {% end %}
  end
end

a = {x: 1, y: 2}
b = {z: 3}

c = a.merge(b)
p c
p typeof(c)

d = {x: 10}
e = a.merge(d)
p e
p typeof(e)

@asterite do I need to update this PR with your suggested code or you are going to add it manually ?

@emancu We still need to define what semantics we want for the method, if we decide to include it. What happens with duplicated keys? If we look at Hash, it keeps the last key, so for me NamedTuple should do the same. If you want to combine tuples maybe we can have + that "adds" two named tuples. But I'm not sure, I'd need to see some use cases.

#triage
When we last left off, this issue is waiting for @emancu to provide some more use cases to further the discussion of how the implementation of the NamedTuple +/merge method might work.

I guess we can close this PR now that #4688 was merged.

@emancu Indeed. Gracias! :-)

I don't think this should be closed just because #4688 was merged, see #4727 (issue comment) and #4688 (issue comment).

Looks like #4727 and #4688 have been closed now FWIW. Thanks for doing this guys, I was about to request the same thing. See also https://groups.google.com/d/msg/crystal-lang/YnoO8GMovKQ/2ZWF3_IfDAAJ