Safe versions for built-in number conversion functions #749
Safe versions for built-in number conversion functions
I propose we add safe versions for built-in number conversion functions.
The existing way of approaching this problem in F# is writing these functions yourself.
They would also check if the value being converted is out of range, e.g.
Pros and Cons
The advantages of making this adjustment to F# are
The disadvantage of making this adjustment to F# is more functions to learn.
Estimated cost (XS, S, M, L, XL, XXL): S
Related suggestions: (put links to related suggestions here)
Affidavit (please submit!)
Please tick this by placing a cross in the box:
Please tick all that apply:
referenced this issue
Jun 11, 2019
I don’t think this is needed as we get the out param mapped to a bool in a pattern match, that’s works quite nicely.…
On Tue, 11 Jun 2019 at 17:27, Phillip Carter ***@***.***> wrote: Generally I'm not opposed. Thoughts @dsyme <https://github.com/dsyme> ? How often do you find yourself needing something like this and being annoyed by having to write a pattern match expression instead? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#749?email_source=notifications&email_token=AAEPXSQULMFMUTQ4RAXMHDDPZ7G7FA5CNFSM4HW73D7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXNW2MQ#issuecomment-500919602>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEPXSR7WUH3VMX6JIYN3VTPZ7G7FANCNFSM4HW73D7A> .
I always wish that the
Here's another thought: does
Why do we try to effectively unsafely parse/cast values into an
This proposal is actually about two things, number parsing and number conversion.
For value conversion, we should possibly stick with
Does built-in in this case mean part of a library, or does it mean that the compiler itself is expanded with functionality? I'm asking because I would generally be skeptical to adding this sort of functionality to a compiler if it might just as well be in a library. But I know far too little about the F# compiler to have opinions.
This should be in FSharp.Core, which is the F# standard library, like with the existing
I find myself writing and snipping these few wrapper functions for Xxx.TryParse and maybe some other, over and over again, for new solutions and LINQPad scripts. I imagine I'm not the only one. So yes, it would be nice not having to do that anymore.
"But what about second breakfast?" asked Pippin.
I live in Norway, and currently write software dominantly for the local market. I frequently need to read text with numeric data. These numbers sometimes use comma as decimal separator, and sometimes period, and sometimes I have to cater for both possibilities with a bit of trickery. The localization settings of the computer is irrelevant, because they can be quite random and you never know when the user changes them or for what reason. That's how the real world is, and I can't do anything about it. So to solve the task properly, I can't normally use
This means that I'd like the tryInt and siblings to have the same possibilities as Int32.TryParse with overloaded siblings. We can't overload functions, but we can create e.g. tryIntBlah (where Blah is something nice I'm not smart enough to think of right now) that takes an additional Globalization.NumberStyles. As the first parameter, so piping is nice.
Likewise. If we add them to FSharp.Core it seems they should exactly correspond to
It's tricky though