Aliases for Union{T, Nothing} and Union{T, Missing}?

Does Julia (v1.0) define or is there a convention for aliases for Union{T, Nothing} and Union{T, Missing}?
For example

const Maybe{T} = Union{T,Nothing}
const Option{T} = Union{T, Missing}

I am aware of wrapper type Some{T}, but that is used for the value nothing as opposed to Union{T,Nothing} which is used for values that are absent.

1 Like

There are no such aliases predefined.
Missing refers to a data element that may not be available, rather than an option.
const Maybe{T} = Union{T, Nothing} (or similar) is used in Haskell

1 Like

What would be a more suitable alias for Union{T, Missing}?

const Maybe{T}      =  Union{T, Nothing}
const MaybeData{T}  =  Union{T, Missing}
1 Like

So now we have

Maybe{T}     # value present or absent
Some{T}      # always a value including the value nothing
MaybeData{T} # value present or missing
DataValue{T} # ?

The Julia manual has the section []. There it says “To represent missing data in the statistical sense (NA in R or NULL in SQL), use the missing object.” QueryVerse uses DataValue{T} for this.
What is the semantic difference between MaybeData{T} and DataValue{T} ?

I thought there was a proposal to parse T? as Union{T,Missing}, but I can’t find it.


No. I don’t what DataValue{T} is in the context of your question. That was added into QueryVerse long before the Missing and Nothing state-of-affairs had been settled. While I have no doubt it is useful for David … it is not used outside of that as far as I know.

I was offering my opinion on how to capture the semantics of “the value of that cell or that row or that column is either present or it is missing” in a compact way that is similar to the use/construction of Maybe{T}.

I recall that.

Sorry for nitpicking. Going from Julia v1.0 forward, is there a need to go beyond the following?

Maybe{T}     # value present or absent
Some{T}      # always a value including the value nothing
MaybeData{T} # value present or missing
1 Like

Julia 2.0 reserves the right to go beyond any present
(until then, you should be good with those three)


I think that extensions don’t break 1.0, so in theory they would be OK.

That said, I prefer Union{T, Missing} & similar. I am sure I would have a hard time remembering which of Maybe, Option, and other variants corresponds to which singleton (as the discussion demonstrates, this is not intuitive at all); just as I don’t remember precedence tables so I try to avoid relying on them.

1 Like

I was responding to the question, not advocating syntax.

1 Like

It’s been discussed a lot of times, but people do not always agree as to whether it should be reserved for Union{T,Missing} or Union{T,Nothing}.

Until then I wouldn’t recommend using custom aliases as it would make code inconsistent from one project to another.


Despite my original question, I actually agree with this. Clarity is more important than number of characters.

1 Like

Sometimes less characters does lead to clarity though.
I wouldn’t advocate it all the time,
but I think that

const Opt{T} = Union{Missing, T}
struct Metadata
    published_date::Opt{Union{Date, DateTime, String}}
    create_date::Opt{Union{Date, DateTime, String}}
    modified_date::Opt{Union{Date, DateTime, String}}

is clear than

struct Metadata
    shortname::Union{Missing, String}
    fullname::Union{Missing, String}
    website::Union{Missing, String}
    description::Union{Missing, String}
    author::Union{Missing, Vector{String}}
    maintainer::Union{Missing, String}
    license::Union{Missing, String}
    published_date::Union{Missing, Date, DateTime,String}
    create_date::Union{Missing, Date, DateTime, String}
    modified_date::Union{Missing, Date, DateTime, String}
    paper_cite::Union{Missing, String}
    dataset_cite::Union{Missing, String}
    dataurls::Union{Missing, Vector}

Because it is just less verbose, so it is easier (for me at least) too see what is going on.

However, such sortage structs are not a particularly common use case.

(Though this type has a number of other issues, that will cause it to be not nesc great for performance; those are irrelevant in this question)


I think it would be nice to have one for either, maybe T? and T??, or something like that. There should be a good mnemonic, though, so they wouldn’t be too easy to confuse (^T, ?T) ???

Crazy idea:
Infix notation for Union.

julia> ∪ᵀ(x...) = Union{x...}
∪ᵀ (generic function with 1 method)

julia> Int ∪ᵀ Nothing
Union{Nothing, Int64}

julia> Int ∪ᵀ Missing
Union{Missing, Int64}

∪ᵀ is just a placeholder.

1 Like

Hmm. Maybe, it’s just that T? seems so nice, and terse. Too bad we need two of them.

T? is great. And it should really be for Union{Missing, T}.


In general,
a short hand for Union{T, Nothing}
does not seem that important

Since one is not supposed to propagate nothings,
thus making Union{T,Nothing} function type constraint,
a struct field type, or a type parameters should be much rarer than
the case of Union{T, Missing}

Generally Union{T,Nothing} is most common only as a return type hint,
I would think.
And return type hints are rarely required, since the return type is
automatically determined.

I expect anything that sometimes returns nothing to have that nothing dealt with close to the source,
not passed around for ages.