Replace null with none, and add a some type.

[zkat]

Because of the whole billion dollar mistake thing, I was thinking we could allow special syntax for KDL to specifically mark any Values as "nullable"/"Option" types. These can well be treated on de/serialization as actual nullable types in languages like JavaScript that support it, or they may be translated to Option types in those that handle "absence" that way.

My main reasoning for introducing this as explicit syntax is to allow the distinction to be made explicit by those who want to, such as certain target languages (like Rust!) or schema languages intended to be used with KDL, which may want to do static verification of a KDL schema.

My proposed syntax is this:

my-node <> // None
my-node <1> // Some(1)
my-node <<1>> // Some(Some(1))
my-node <<>> // Some(None)

My intention is that in languages with null, which want to keep that logic, will represent <> as null, and <1> as a completely unwrapped 1. Same thing for any level of wrapping, so <<<<1>>>> would become 1 in those languages. Likewise, <<<>>> would just become a simple null. Languages or libraries which choose to go the "safe" route, though, will be able to represent these as Some(Some(Some(1))) and such.

What do y'all think?

[lulu-berlin]

Angle brackets have the advantage of being shorter than some(value), but still the question remains of whether you want the serialization format to enforce the difference between a required value and an optional value.

So, if my-node expects an optional number and the data holds a number, would it still be allowed to serialize it as

my-node 123

or only

my-node <123>

?

What about omitting the value altogether? Is that something you want to support, or rather require it to be explicit?

Is

my-node

equal to

my-node <>

?

[lilyball]

I would consider that to be a buggy implementation. There’s no benefit to be gained from turning something that has a very clear meaning into an error. Option<i64> is a union type equivalent to number | null, which is to say it’s inhabited either by a number or by null.

[lilyball]

“Oh sorry, you gave me a number, but I was expecting a construct where you told me explicitly that you had a number that wasn’t null”. I’ve never before heard of a textual serialization format that worked this way. And even strictly-typed programming languages don’t necessarily work this way. For example, Swift will “hoist” any value into an optional (or an optional optional, or optional optional optional, etc) as needed to typecheck. so I could say MyStruct(value: 123) and this works just as well as MyStruct(value: .some(123)).

[lulu-berlin]

@lilyball I feel ridiculed by your comments. It definitely doesn't encourage me to participate in this discussion and try to share my perspective. I'm going to check out from this conversation.

[lilyball]

I apologize, I’m not trying to ridicule you. I was attempting to illustrate why <123> and 123 must be treated the same by any code that deserializes into typed structs.

Edit: To be more clear, this is entirely my fault. I understand why you interpreted my comment that way, I phrased it poorly. I was trying to anthropomorphize a parser but I did so without considering how this may come across to the reader.

[lilyball]

I value your input and the last thing I want to do is drive you (or anyone else) away.

[lilyball]

KDL doesn’t have static typing. Given that, I don’t think there’s any value to be gained in trying to mark a value as Some(1). The fact that it’s an integer instead of null already provides this information. The only practical difference here is in the ability to represent something like Some(None), and I’m not convinced that’s worth adding this.

If you think about it, an optional type like Option<i64> is really just a union type like number | null. Dynamic typing already works with union types, so any hypothetical KDL schema language would likely just use union types to describe the options for a given value/property.

[zkat]

My thinking here is more about languages that want to be more explicit about it (like loose deserializations in Rust), but also when there comes a time when schema tools for KDL exist, and those would have more powerful tools to play with.

In the meantime, Just (hah) using <> for null and unwrapped values for not-null values will be good enough for most people. I just want this handy.

[lilyball]

I’m not convinced this is particularly useful for schemas. <1> and <<1>> and <<<1>>> are semantically equivalent to 1. The only distinction is <<>>, <<<>>>, etc and that seems like such an edge case. And this means “using up” angle brackets, preventing their use for some other feature.

[jlkiri]

I would agree with @lilyball and feel that this

The fact that it’s an integer instead of null already provides this information

is the biggest point. Although it's a different story if KDL itself will be used as a schema language. In JSON Schema (which I'm not very familiar with) it seems you can express a nullable string like this:

{ "type": ["string", "null"] }

which is much more verbose than type <"string">.

[lilyball]

Presumably that same syntax lets you write {"type": ["string", "number"]} too, which is to say it’s just defining a union type.