Description
This is an proposal to remove the constraint that "Data types may not be mixed" from TOML's array syntax, making arrays heterogeneous – just like they are in JSON, JavaScript, Python etc. It is a spin-off of #553 which originally went into the opposite direction (proposing to make array typing "deep" instead of "shallow", as it currently is) but then received various comments making the case for heterogeneous arrays. I'm collecting these arguments here (and adding some new ones) so that the case for heterogeneous arrays can be discussed independently of the "deep vs. shallow" question (which in #553 has already been labeled as "post-1.0").
First, I agree that it's a good practice to reserve arrays for items of the same type. But, as @demurgos pointed out, items that conceptually are of the same type might be reasonably expressed in ways that correspond to different types in TOML. For example, contributors to a code package:
[package]
contributors = [
"Foo bar <foo@bar.com>",
{ name = "Baz Qux", email = "baz@qux.com", url = "baz.qux.com"},
]Or uplink servers in a private package manager:
[uplink]
servers = [
"https://srv1.uplink.com/",
{ url = "https://private.uplink.com/", auth_token = "..." },
]All these examples might be rewritten using arrays of inline tables with one or more fields. But if many of these tables essentially require just a single field that may be considered needlessly cumbersome. If app writers want to allow their contributors (or whatever else an array is used for) to specify their credentials either compactly as "Name <email>" or more verbosely as { name = "...", email = "..." } (with the second syntax also allowing other, optional fields which are not supported by the first syntax), why shouldn't they? Note that they don't have to make that choice – if they want to standardize on a single syntax, that's fine. But if they want to allow alternative syntaxes, I'd consider that a legitimate choice which should not be prohibited by an arbitrary decision of the TOML spec authors.
Another problem of the typing restriction is that TOML has two numeric types, while, mathematically speaking, all numbers are numbers which might be written in different ways (e.g. 2, 2.0, 4/2 are three ways of writing the same number). But since TOML has no "array of numbers", users have to decide whether they want an "array of integers" or an "array of floats" and then write all numbers in the same fashion. Hence the following perfectly logical array is currently illegal:
values = [0.1, 0.2, 0.5, 1, 2, 5, 10, 20, 50] # ILLEGAL, but why??This is more restrictive than even strongly typed languages such as C or Java, which will autoconvert int to float (or similar) as needed.
double values[] = {0.1, 0.2, 0.5, 1, 2, 5, 10, 20, 50}; // LEGAL, and why not?And forcing people who care about numbers but not about how their internal representation in computer memory might look like to add ".0" to every plain number just because some other numbers require a fractional part is just plain odd.
So, let's drop the problematic typing restriction and make array values free. Heterogeneous arrays haven't hurt the popularity of JSON or Python, neither will they TOML's.
Also, note that arrays of tables and of inline tables are already free – TOML neither forces all of them to have the same keys, nor does it force every key to map to the same type of value. Since tables are untyped, lets be consistent and un-type arrays as well.
Schema validation (which keys are in a table? which type does each of them have? which type or types are allowed in an array? how many values are required or allowed in an array? etc.) is best left to an external schema validator (see #116) or application logic. TOML can at most make a very bad job of it, so there is no point in trying.
I know this is a non-breaking change so it could be delayed until TOML 1.1. However, 1.0 might well be the "gold standard" for a long time so I would urge to seriously consider this for inclusion into 1.0 (ping @mojombo @pradyunsg @eksortso @demurgos).