No, that is not a sumtype, that's an array.

In the same sense "1e-12" is not a number, it's a string. Yes, it's a string that encodes a number in a certain notion, but for alle the tooling, the IDE, the libraries, etc. it will stay a string.

What I mean is, it is an array of a sumtype `number | string | object`. So precisely, you could call it a `list<number | string | object>`

Sum types =/= union types. Sum types are also called 'tagged' or 'discriminable' unions because they have some way to discriminate between them. That is, if you have an element a of type A, a is not part of the sum type A + B because it's missing a tag.

[5,"hello",3] has the type list (int ∪ string), not list (int + string). You can emulate the latter by manually adding a tag, but native support is much preferable.

I know the differences between untagged and tagged unions, I'm trying to provide a minimal example without distracting details but sure we can talk about tagged unions. Here is a list of tagged unions, so I once again point out that sum types are "supported" in JSON/ions just as much as any other data type:

    [
      {tag: "a", foo: 1},
      {tag: "b", bar: "hi", baz: 2},
      {tag: "a", foo: 3},
      {tag: "a", foo: 4},
      {tag: "a", foo: 5},
      {tag: "b", bar: "yo", baz: 6}
    ]

By that reasoning, why have structs? You can just make an array of size-2 arrays that give the key and the value.

Okay I'll admit, that's a good point.

That's a list union[number, string, object] or list[Any], not a sum type, no? This

`data X = A | B

[A, B, ...]`

Is a list containing a sum type: list[X]

There is no such thing in JSON or Ions as defining this "X" schema somewhere. So I may as well say that your [A,B,...] is a list[Any].

Now, I wouldn't actually call it a list of any, I would say you proved my point for me. Your example is functionally the same as mine. I would give this example:

`[A, B, ...]`

and say that that is a list of sum types. You may say "no no no! Only now is it a list of sum types!":

`data X = A | B

[A, B, ...]`

But my point is that there is no JSON/Ion equivalent of your `data X = A | B`. Everyone in this comment tree is confusing the data itself with out-of-band schema over that data. "Sumtype" is nothing more than a fiction, or a schema. Saying that JSON/Ions don't support sumtypes is like saying JSON doesn't support "NonNegativeInteger" type. Sure it does! Here are some: 1, 2, 3, 10. What tooling or type system you use outside of the data itself to enforce constraints on the data types is orthogonal to the data format itself.

> But my point is that there is no JSON/Ion equivalent of your `data X = A | B

No one disagrees - it's just that we complain about this. We _want_ to have such an equivalent.

> Saying that JSON/Ions don't support sumtypes is like saying JSON doesn't support "NonNegativeInteger" type.

Correct. But your conclusion is wrong. You seem to assume that no one has a problem with the fact that JSON doesn't support a "NonNegativeInteger" type. But I at least would happily use a format that explicitly supports that.

I mean, look at ION. Json doesn't support the concept of (restricted) integers, but ION extends JSON and offers this type. That's great, because it means if a library reads an integer field, it can map it to an integer and knows that there are constraints.

This is a _very_ relevant issue. Many json libraries in the past have had bugs or could be ddos-ed by feeding them json with large numbers, since the json spec does not constrain the size of numbers.

In that sense, ION could have _also_ added support for "NonNegativeInteger" or sumtypes, or other specific types, but they haven't. And since sumtypes are very fundamental, we complain about it more than we would complain about the lack of "NonNegativeInteger".

His point was type support and standard way of doing things. Using your argument we just need string type to represent everything.