Skip to content

Conversation

cmcaine
Copy link
Contributor

@cmcaine cmcaine commented Nov 17, 2022

# Good
parse(Int, "5") == tryparse(Int, "5") == 5
parse(Int, '5') == 5

# Bad!
tryparse(Int, '5') # MethodError, tryparse not defined for Char

This PR lets tryparse parse AbstractChars in the same way that parse does.
This PR also documents that parse accepts characters as well as strings.

@brenhinkeller brenhinkeller added the strings "Strings!" label Nov 17, 2022
@cmcaine
Copy link
Contributor Author

cmcaine commented Dec 30, 2022

This is still good to go. CI failure seems unrelated.

@cmcaine cmcaine closed this Mar 14, 2023
@cmcaine cmcaine reopened this Mar 14, 2023
@cmcaine
Copy link
Contributor Author

cmcaine commented Mar 14, 2023

I've rebased this and updated the first post to better describe the issue. The CI failures still seem like false positives.

Could this be flagged for triage, please?

@ViralBShah ViralBShah added parser Language parsing and surface syntax triage This should be discussed on a triage call labels Oct 28, 2023
@adienes adienes removed the triage This should be discussed on a triage call label Sep 14, 2025
@adienes
Copy link
Member

adienes commented Sep 14, 2025

I'm not sure this needs triage; it needs a reviewer 🙂

making parse and tryparse accept the same argument types certainly seems sensible enough to me.

A character can be used in place of a string for Integer types.

this is a bit clunky. maybe instead make the first line in the docstring Parse a string (or character) as a number.

@cmcaine
Copy link
Contributor Author

cmcaine commented Sep 16, 2025

I think I might have copied that line of the docstring from parse.

I'm happy with your suggestion. Are you happy with the code, besides that docstring change?

@adienes
Copy link
Member

adienes commented Sep 16, 2025

yes, it looks good to me. to be completely proper, we should add a compat annotation like

!!! compat "Julia 1.13"
    `tryparse(type, AbstractChar)` requires at least Julia 1.13.

@cmcaine
Copy link
Contributor Author

cmcaine commented Sep 17, 2025

Cool. I think it should be

tryparse(<:Integer, AbstractChar) requires at least blah

Cos other types in 3rd party code may define parse or tryparse for other types.

I'm happy for you or someone else to male these small changes and merge this PR.

@adienes
Copy link
Member

adienes commented Sep 19, 2025

closes #45640

@cmcaine
Copy link
Contributor Author

cmcaine commented Oct 1, 2025

this is a bit clunky. maybe instead make the first line in the docstring Parse a string (or character) as a number.

I remember why I wrote it this way now, it's because parse(Float64, "1") works, but parse(Float64, '1') doesn't.

I could fix that by removing the type restriction.

@adienes
Copy link
Member

adienes commented Oct 1, 2025

FYI, it's possible #59603 might end up subsuming this PR as it also adds this method (+ some performance improvements). sorry to have your thunder stolen 🙂. if you are interested in helping review that it could be helpful. of course if there ends up being no motion there for a while we could merge this anyway

@cmcaine
Copy link
Contributor Author

cmcaine commented Oct 1, 2025

Cool, well I guess we'll see what happens. I'm not precious about someone else fixing this!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

parser Language parsing and surface syntax strings "Strings!"

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants