$ super -version &&
echo 'null' | super -s -c "
values
typeof(cast(this, <int64>)),
typeof(cast(this, <float64>)),
typeof(cast(this, <bool>)),
typeof(cast(this, <string>)),
typeof(cast(this, <bytes>)),
typeof(cast(this, <ip>)),
typeof(cast(this, <net>)),
typeof(cast(this, <time>)),
typeof(cast(this, <duration>)),
typeof(cast(this, <[int64]>)),
typeof(cast(this, <set[int64]>)),
typeof(cast(this, <map{string:int64}>)),
typeof(cast(this, <{a:int64}>))
" -
Version: v0.3.0-123-g0213c531c
<int64|null>
<float64|null>
<bool|null>
<string|null>
<bytes|null>
<ip|null>
<net|null>
<time|null>
<duration|null>
<null|[int64]>
<null|set[int64]>
<null|map{string:int64}>
<null|{a:int64}>
This is effectively a cosmetic issue, but it's been cited as a possible area for UX improvement since being able to spot if a union is nullable may be something users will often want to do. In a brief group discussion there was agreement that it would be nice to standardize here, but there were also some concerns that a change might put the type order in the SUP output out of sync with the underlying type order in BSUP that developers may be familiar with.
It's been noted that in SUP output a
nullin union types is placed last if alongside a primitive type but first if alongside a complex type.Details
Repro is with super commit 0213c53.
This is effectively a cosmetic issue, but it's been cited as a possible area for UX improvement since being able to spot if a union is nullable may be something users will often want to do. In a brief group discussion there was agreement that it would be nice to standardize here, but there were also some concerns that a change might put the type order in the SUP output out of sync with the underlying type order in BSUP that developers may be familiar with.