Allow duplicate keys

[axos88]

Yeah, it's against the spec right now, but changing it shouldn't break any clients, since this used to be behaviour that broke.

Seems like there were a few questions raised before about this:

BurntSushi/toml#186
#350

For my use case I would like to be able to concatenate toml files (default.toml + override.toml), and end up with a valid toml file.

My take on the rules would be:

1. If a value is specified directly ( foo.bar = 42), overwrite the value
2. If a table is defined twice, merge any new entries into the table, and for collisions see rule "Special Characters" is undefined. #1
3. If an array element is defined in the override.toml, add it to the end (this actually works today).

    [[ foo.bar]]
      x = 1
    [[ foo.bar]]
      x = 2

4. If an array is redefined (foo.bar = [1,2,3]), that's a value definition see rule "Special Characters" is undefined. #1
5. In case of mixed elements, the latter one defines wether it should be added or overwritten, but actually I think this brakes the parser.

  foo.baz = [1,2,3]
  [[ foo.bar]]
    x =  1
  [[ foo.baz]]
    x = 2                    // foo.bar ends up being [1,2,3,{x = 2} ]
  foo.bar = [4]           // well... I'd expect foo.bar to become [{x=1}, 4], but i think that's not going to parse correctly, and if winds up in foo.baz.

Let me know your thoughts.

[eksortso]

You may be working with a non-compliant parser when you describe what you say used to work. But the specification is explicitly clear on this point:

Defining a key multiple times is invalid.

And a TOML document with duplicated keys will always be invalid. There is no benefit in making things more elaborate than that.

But, that wouldn't prevent you from loading two or more TOML documents and chaining them together in your application. Based on what you've written, I think you could define that chaining behavior pretty well.

[axos88]

The one I said that is working are things that are okay according to the spec. adding elements to arrays.

Basically my first sentence was that I'm aware that things that I am suggesting are currently against the spec, but unless there is an actual point on why it's defined like that (other than "no!"), I don't see why it wouldn't be beneficial to relax the restrictions to allow more flexibility.

[eksortso]

The one I said that is working are things that are okay according to the spec. adding elements to arrays.

That makes sense, okay.

I don't see why it wouldn't be beneficial to relax the restrictions to allow more flexibility.

Flexibility comes at a cost. For instance, we have three ways of defining tables in the spec, and it took us a very long time to reach a consensus on the behaviors that these different syntaxes follow. For a standard whose core purpose is to be minimal and obvious, we bent over backwards to make it that much more flexible.

[yyny]

I like this feature, but I think it should be optional. As in, the spec should word it as "An implementation MAY support duplicated keys. If an implementation supports duplicated keys, it should {insert a reasonable behaviour for duplicate keys here})"

[pradyunsg]

My take on the rules would be:

These rules can create an "action at a distance" behaviors, are context dependent and introduces complexity. All of these are things I'd like to avoid in TOML. Disallowing duplicate keys keeps the semantics simpler, making it easier for implementations, authors of configuration files and enhances readability. I'd like to preserve these behaviors.

For users that want behaviors like you've described, they can use tables and have application-side logic for implementing such behaviors.

TOML won't be introducing duplicate keys for such use-cases.

[pradyunsg]

TOML won't be introducing duplicate keys for such use-cases.

I'm going to close this issue for this reason.