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

New to Julia
1

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
2

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
3

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

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

@JeffreySarnoff
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 [Frequently Asked Questions · The Julia Language]. 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} ?

6

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

2 Likes
7

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}.

8

I recall that.

9

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
10

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

2 Likes
11

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
12

I was responding to the question, not advocating syntax.

1 Like
13

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.

2 Likes
14

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

1 Like
15

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
    shortname::Opt{String}
    fullname::Opt{String}
    website::Opt{String}
    description::Opt{String}
    author::Opt{Vector{String}}
    maintainer::Opt{String}
    license::Opt{String}
    published_date::Opt{Union{Date, DateTime, String}}
    create_date::Opt{Union{Date, DateTime, String}}
    modified_date::Opt{Union{Date, DateTime, String}}
    paper_cite::Opt{String}
    dataset_cite::Opt{String}
    dataurls::Opt{Vector}
    datachecksums::Any
end

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}
    datachecksums::Any
end

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)

5 Likes
16

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) ???

17

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
18

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

19

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

2 Likes
20

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.

4 Likes