parse

[Charles]

I've always disliked .NET's "parse" and "tryParse" approach for parsing things like ints, floats and decimals. The "parse" method throws an exception if it can't parse (bleck) and the "tryParse" method typically requires a local var declaration (bleck):

d as decimal
if decimal.tryParse(input, out d)
    print 'safe to use d: [d]'

What if parse returned a nilable type such as "int?", "float?" and "decimal?". Then you can just check the return value:

d = decimal.parse(input)
if d, print 'safe to use d: [d]'

Which also means you could use the "coalesce" operator if you wanted a default value for unparseable input:

d = decimal.parse(input) ? 0.0

I don't see any disadvantages over the existing parse+tryParse unless you really need to distinguish the exceptions (overflow vs. bad input, for example).

Unfortunately, the name "parse" is already occupied by the .NET library, so we would need a to sue different name like "decimal.parseable(input)", or tweak the compiler so that this new .parse obscures the original one.

Feedback?

[hopscc]

I've no strong feelings either way.
I agree about the exception throwing for parse failure since I dont see failure to parse as an exceptional condition (!)
The addition would be a little notational convenience.

I'd not obscure the existing names but provide some new/additional name
.parseOrNil
.tryParseOrNil
.cobraParse
...

[todd.a]

I do think it is exceptional from the point of view that if the data is trusted or you know what to expect then you might simply want to parse knowing that the operation would be successful. For example, you might have already validated the data. At least that is the context I use it mostly. On the other hand when you're unsure whether some operation would be successful you go with tryXXX methods (it's a fairly common practice in .NET APIs).

I like the idea of being able to provide a specified default via the null-coalesce operator.

I haven't thought about it enough but maybe to be on the safe side instead of obscuring the .NET method (interoperability with code that expects certain behavior maybe?), use a name like "read" or "scan". Those names are a bit funny because C uses scanf and Java Scanner uses readXX . I would agree that the verb "parse" best describes what is done so I prefer it from a strictly naming point of view.

[Charles]

I don't typically validate my input and then call parse--I do it in one operation. In my own applications, the input could always be "bad" because it comes from a file or a web form.

I currently think that hopscc suggestion of .parseOrNil is the best choice.

[Gameday]

Maybe have it take two parameters? The second one would be the value to be used in case something goes bad. A fallback.

[Charles]

I had initially thought in that direction, but the coalesce operator makes it rather easy to provide one and helps narrow the type. Here is what I mean:

i = int.parseOrNil(input) ? 0  # type infers as int
j = int.parseOrNil(input)      # type infers as int?

# now with default
i = int.parseOrDefault(input, 0)    # type infers as int?
j = int.parseOrDefault(input, nil)  # type infers as int?

In other words, if .parseOrDefault can take "int?" as a default value then its return value is always "int?" even when you provide a non-nil default. .parseOrNil also returns "int?" but when you write "... ? 0" or whatever to change the default, you narrow the type.

It's a subtle point, but a worthy one in a language that distinguishes between nilable and non-nilable types.

[CodexArcanum]

I think the name is a little wordy, but I can't think of anything better myself and it does have to be distinct. I definitely prefer the .parserOrNil version though, precisely because of the coalesce operator. If you need a default, it covers that, or you can just take the nil if that's what you need.