Support + in key names
BrianHarris opened this issue · comments
I'm working on a system that allows for merging TOML files together. For example you could have a "Base" config and a platform specific "Override" config.
For scalars it's easy -- overwrite the old value. For arrays it's tricky though because we want the ability to add and remove elements.
I'd like the ability to prefix a key or table name with + to indicate it should be added to an existing array, or - to indicate it should be removed. For example:
[table]
+key=[ "These elements", " are added to an existing key" ]
-key=[ "These elements", " are removed from an existing key" ]
I can do it right now by enclosing the name in quotes, but it would be really nice to specify them with bare keys.
Alternatively, TOML could support explicit merging with += and -= operators, but that seems like a much bigger change.
Dashes can already be used in bare keys, including at the beginnings of key names. So we're just talking about the plus signs here. That said, I'm up-and-down about this proposal.
The simplest approach to fulfilling this enhancement request would be to add plus signs ("+") to the list of acceptable unquoted-key characters. So this would permit keys like apples+oranges to go without quotes, as well as keys beginning with plus signs, such as +one. Doing so would be simple, as plus signs don't have any other significant meaning in TOML at this time
This is being requested so that a file for an application intended to alter an existing configuration can also be written easily as TOML. But color me skeptical about making such documents easier to write. Since an application to make modifications to existing configs is certainly an extraordinary application, I am not sure if we ought to make it easier, just for that purpose.
Right Dave, The easiest way to accomplish what I need is to add "+" as an allowed character. I'm not sure what the disadvantages of doing that are. I read through #283 and all the issues it links to. I understand originally keys could contain anything, then it was proposed to restrict them to alpha-numeric only, but dashes were added because the Rust people needed them for Cargo. Adding + seems easy enough, but it could be a 'slippery slope' to allowing any character again.
Adding "+" as an allowed character feels pretty safe and reasonable to me. Besides this (obscure) use case it might also come handy in many other situations, allowing designers to name their keys "apples+oranges", "Musicians+Artists" etc.
I don't think that we risk a "'slippery slope" as long as the allowed characters remain limited to those printed on the keycaps of a standard US QWERTY keyboard.
Can I propose an alternative? Wouldn't it work to make use of the following configuration style, which IMO also makes it more clear to the reader what you're doing with the data? ("a + or - at the start of the key has special meaning" only works for those who are familiar with the configuration system already:
[table]
key.add = [ "These elements", " are added to an existing key" ]
key.remove = [ "These elements", " are removed from an existing key" ]this style also allows for many other typical schemes that you might come up with during configuration management-like tasks, for example:
[table]
key.replace = { search="$HOSTNAME", replace="production.example.com" }
key.insert = [ "tier1.example.com" ] # insert items at the start of the array
key.append = [ "tierx1.example.com", "tierx2.example.com" ] # append items to the end
key.dictFromQuery = "SELECT key, value FROM configuration WHERE env='production'"
key.unset = true
# ... etc ...Wouldn't these be more clear than the special meaning of "+" and "-" ?
Also, with that encoding, I could foresee issues with the way in which to use them:
[table]
+sub.key = [ 1, 2, 3 ] # would this be right?
sub.+key = [ 4, 5, 6 ] # or this one? Or maybe both?
sub.key.append = [ 1, 2, 3 ] # while this is crystal clear.
Good idea Maurice. In our particular system, the order of the arrays doesn't matter, but I can easily imagine systems where it does.
So, it's now much less important for my use case, but it might still be useful to support "+" in key names as Christian points out. At this point it's rehashing the arguments from #283 et al.
The + can be added easy enough, but the thing is: where does that end? In fact, the whole unicode space, except for the = sign and spaces might be considered useful to support.If + is useful, why not add for example %, & and * as well and what would be good reasons for adding additional characters? Slippery slope IMO. But luckily not my slippery slope ;-)
I like the bare key formatting as-is, since it does force one to use a simple naming scheme. However, when more elaborate naming is required, escaping the constraints by adding a few quotes does the trick.
At this point, I suggest we defer until v1.0 has been released. The addition of plus signs to bare keys isn't urgent, but may still be valuable.
apples+oranges
Hmm... I definitely don't think this is a good idea for a key.
Anyway, I'm gonna squat behind "I want to get 1.0 ready first" and defer on deciding about this for later. One thing I know for sure is that there's no slippery slope here -- + is likely the only symbol worth considering here. If there's any additional symbols folks can think of that might be useful, now would be a good time to flag them. :)
If added for the sake of the + sign being parsed as an addition operator, I believe this adds semantic confusion and drifts towards encouraging people to parse particular key names in a particular way, rather than as what they are, names.
The same does not exist for supporting it purely for its own sake, but I believe the wisdom of maintaining a deeply restricted syntax for bare key names continues to apply. The current selection of bare key legal characters encourages restricting ourselves to US-ASCII, and, better yet, URL-safe characters, preferably non-reserved ones. Of those, only a few aren't legal and also haven't been granted a meaning or permitted in bare keys already. So, I suppose I would have to put forward an argument for the tilde, ~, first.
Ok, spending some time to think through this -- @mmakaay's suggestion is a good one and I think @workingjubilee's point around not adding semantics to the keys (rather than treating them as a name) is a good one as well.
I think not expanding beyond -/_ is a reasonable thing to do. I'm going to go ahead and close this issue to reflect that.