Syntactic sugar for types

[andrey2185]

Is this the correct code to add syntactic sugar for types?

Base.:(|)(X::Type, Y::Type) = Union{X,Y}
Base.:(|)(X::TypeVar, Y::Type) = Union{X,Y}
Base.:(|)(X::Type, Y::TypeVar) = Union{X,Y}
Base.:(|)(X::TypeVar, Y::TypeVar) = Union{X,Y}

at first glance everything works

const Maybe{T} = T | Nothing

function foo(x::Maybe{T|S}) where {T<:Integer, S<:AbstractFloat}
    typeof(x)
end

foo(1)

x = Vector{Int|Float32}(undef, 10)

@. foo(x)

Base.@kwdef struct Foo{T<:Integer|AbstractFloat}
    x::Maybe{T} = nothing 
    y::(T|String) = "asd"
end

Foo{Int}()

How else can I test it?

[giordano]

@andrey2185

Is this the correct code to add syntactic sugar for types?

Base.:(|)(X::Type, Y::Type) = Union{X,Y}
Base.:(|)(X::TypeVar, Y::Type) = Union{X,Y}
Base.:(|)(X::Type, Y::TypeVar) = Union{X,Y}
Base.:(|)(X::TypeVar, Y::TypeVar) = Union{X,Y}

Note that technically that’s type piracy as you don’t own the function name nor the argument types, don’t do that.

[andrey2185]

I mean to do pull request in julia with this code

[jar1]

Check this thread

Proposed alias for union types

The | character is used in a few different languages as a concise way to specify type unions, like in TypeScript, Scala, PHP 8+, Python 3.10+, and (sort of) Haskell. I was curious to hear what people’s initial thoughts would be on having this as a concise way to create Unions. This would be completely backwards-compatible of course; Union by itself would still be Union. Currently | is used for OR, which has close connections to type unions in formal logic (h/t @mkitti in this). Because of this …

[Benny]

@giordano

that’s type piracy as you don’t own the function name nor the argument types,

Instead one could define a new | function in a package and import that, and it would be usable without extending Base.:| and making sure nothing broke. Would be strange to sacrifice bitwise-or for that symbol though.

[aplavin]

@Benny

Would be strange to sacrifice bitwise-or for that symbol though.

No need to sacrifice anything – MyPackage.(|) could just fall back to Base.(|) whenever arguments are not types.

[MilesCranmer]

@Mason’s InfixUnions.jl has | available with basically the same implementation in case you want to use an already-registered package instead: GitHub - MasonProtter/InfixUnions.jl

It creates a new function | rather than pirating Base.:(|). Generally you should avoid defining new methods for functions in Base on types that are also in Base. You should only do one or the other (new function on types in Base OR extend a function in Base on new types)

[stevengj]

@andrey2185

I mean to do pull request in julia with this code

IMO, it’s unlikely to be accepted in the base language. See a long discussion here: Proposed alias for union types - #17 by stevengj

I think the main reason that these proposals have come up only recently, more than a decade into Julia’s development, is type1 | type2 syntax has recently been adopted and popularized in Python. But “spell things more like Python” has never been a huge priority for Julia, especially in cases like this where we have a longstanding existing syntax as well as a longstanding resistance to “punning” (having an operator like | mean two completely different things).

[MilesCranmer]

@stevengj

I think the main reason that these proposals have come up only recently, more than a decade into Julia’s development, is type1 | type2 syntax has recently been adopted and popularized in Python. But “spell things more like Python” has never been a huge priority for Julia

Within the lengthy thread on this topic are some comments discussing precisely this point, so I think we should avoid rehashing things. I also have no energy left for this topic (having given up long ago)

@andrey2185 At the end of the day, the nice thing about Julia is that you can just overload | in your config/startup.jl file to use this syntax in your REPL. And if wanting to use it in a package you can just depend on InfixUnions.jl.