Define maybeparse(T,x)::Union{Nothing,Some{T}}

[adkabo]

Background

A number of functions in Base and packages return T or nothing, often written before Julia had Some{T}. Callers of these functions are not always able to tell whether the computation failed or successfully returned a value of nothing.

Proposal

I want to use this pattern:

y = maybeparse(T,x)::Union{Nothing,Some{T}}
return isnothing(y) ? nothing : handle(something(y))

tryparse doesn't wrap the successful value in Some. maybeparse would do so and would be a replacement for that function to be recommended in new code.

This function isn't strictly necessary since we already can distinguish using try parse(T,x) catch but it would be nice to have an exceptionless version that can be used in expression contexts like pattern matching.

Naming

maybeparse is a bit long so it could be mayparse.

References

• A blog post about why this wrapping is good
• A similar issue for get WIP/RFC: add 2-argument get returning Union{Nothing,Some} #34821
• A similar issue for maybetake! add maybetake! and tryput! #41966 by @tkf
• A similar issue for findfirst findfirst on dictionaries returns ambiguous result #29565 (Mentioned in comment below.)
• A tryparse issue Define parse in terms of tryparse #43149

[nalimilan]

An alternative solution which would fit better with the current API would be to write tryparse(Some{T}, x) instead of maybeparse(T, x). I think we should make a general design choice regarding whether we want to add maybe* functions or use a different pattern.

EDIT: see also #29565 where we need a syntax to call findfirst and get a Union{Some, Nothing} result.

[adkabo]

I don't like the idea of adding syntactic overhead (Some{T}) to buy correctness, so my preference is to move away from the current API rather than trying to stick with it. The downside is growing API surface, the impact of which can be addressed here by soft-deprecating the old version in the docs.

[tkf]

I've been wondering about something similar but a bit generalized version: Can we have a consistent convention/API for Union{Some{T},Nothing}-valued and "result/either type"-valued ¹ functions?

We have the f! naming scheme for destructive functions and it has been working quite nicely in practice. Likewise, it's nice to have a standard way to tell that a given function uses a certain convention or API. It's perhaps more true for maybe-valued and result-valued functions than f! because we can have a standard toolset for composing such functions like Rust's and_then and or_else.

tryparse(Some{T}, x) instead of maybeparse(T, x)

I don't think this can work if we want to make it possible to generalize tryparse-like API to non-Numbers because tryparse(Some{Int}, "Some(1)") is ambiguous.

Footnotes

1. By result type I'm talking about something like Union{Ok{T},Err{E}} with struct Ok{T}; value::T; end and struct Err{E<:Exception}; value::E; end. There's a latest summary and discussion by @jakobnissen in [ANN] ErrorTypes.jl - Rust-like safe errors in Julia - Package Announcements / Package announcements - JuliaLang and also my exploration around this topic https://github.com/tkf/Try.jl. ↩

[jakobnissen]

First, let me say that I am completely, totally on board with having a concerted effort to create a well-thought out system for result types in Julia. These kinds of systems are great in any language, but Julia seems to be uniquely suitable for creating a nice result type system due to its type system.

The current situation with Some and Nothing seems designed ad hoc with a whole bunch of edge cases, and is not exactly ideal. I don't think the maybeparse proposal is helpful in getting us to a more general, principled design. It would just be one more incomplete design.

With regard to a naming scheme for failable functions, I would prefer using type annotation on functions for this instead of a naming convention. Not only are type asserts easy to read and do not introduce new syntax or concepts, they actually assert that the function returns a result type instead of just suggesting it. Further, they can optionally say exactly which result type.