Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Define parse in terms of tryparse #43149

Open
jakobnissen opened this issue Nov 19, 2021 · 0 comments
Open

Define parse in terms of tryparse #43149

jakobnissen opened this issue Nov 19, 2021 · 0 comments
Labels
docs This change adds or pertains to documentation

Comments

@jakobnissen
Copy link
Member

Historically, parse was created before tryparse in Julia. However, tryparse is more fundamental and generally useful, since it allows the caller to handle badly formatted strings. The caller can then decide whether to error or handle the input in another way. By erroring when nothing is returned, tryparse can easily be turned into parse - but it is not easy the other way around.

I propose that we:

  • Define parse in terms of tryparse by adding the following fallback definition:
function parse(::Type{T}, s::AbstractString) where T
    y = tryparse(T, s)
    y === nothing && throw(ArgumentError("Cannot parse as $T: \"$s\""))
    return y
end
  • Recommend users to implement tryparse(::Type{T}, s::AbstractString) and only implement parse if they need a custom error message.

This way, the user gets both parse and tryparse, only having to implement one function, and as an added bonus, we emphasize that users should implement the more efficient tryparse as the primary mechanism.

@vtjnash vtjnash added the docs This change adds or pertains to documentation label Nov 19, 2021
jakobnissen added a commit to jakobnissen/julia that referenced this issue Jan 19, 2022
Malformed strings must be expected when parsing. In that case, `parse`
throws an error, which means handling it neccesitates catching, which
is slow an un-idiomatic in Julia. For this reason, `tryparse` was added.

Because `parse` can generically be derived from `tryparse`, if we implement
`parse` in terms of `tryparse`, then implementing the latter give both methods
for free, such that the caller has control over how to handle failures.

This PR adds a fallback definition of `parse` which calls `tryparse`, and
adds a generic docstring to both functions that explain that users should
implement `tryparse` for custom types.

Previously, the `parse` documentation in both docstring and manual implied
that only numbers were being parsed, e.g. `Base.parse` was listed under
"Numbers" in the manual, and the generic docstring referred to numbers.
This PR moves the manual entry to "Strings" and clarifies that the old
docstring refers to parsing numbers only.

See also: JuliaLang#43149
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
docs This change adds or pertains to documentation
Projects
None yet
Development

No branches or pull requests

2 participants