https://issues.dlang.org/show_bug.cgi?id=17438

Vladimir Panteleev <dlang-bugzilla@thecybershadow.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |dlang-bugzilla@thecybershad
                   |                            |ow.net
         Resolution|---                         |WORKSFORME

--- Comment #1 from Vladimir Panteleev <dlang-bugzilla@thecybershadow.net> ---
The documentation says:

Throws: A ConvException If an overflow occurred during conversion or if no character of the input was meaningfully converted.

"if no character of the input was meaningfully converted" is the key part, so at least for the example you presented, I don't see a problem.

--

https://issues.dlang.org/show_bug.cgi?id=17438

Brad Roberts <braddr@puremagic.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WORKSFORME                  |---

--- Comment #2 from Brad Roberts <braddr@puremagic.com> ---
Re-read the description of the parse family of functions I cut and pasted into the bug report (which is still what the page says).  The entire family is documented as not throwing.  One function does, and that it documents at the specific site of that variant doesn't give it license to violate the spec at the higher level.  One of them is still wrong, and it's that it throws.

--

https://issues.dlang.org/show_bug.cgi?id=17438

--- Comment #3 from Vladimir Panteleev <dlang-bugzilla@thecybershadow.net> ---
(In reply to Brad Roberts from comment #2)
> The entire family
> is documented as not throwing.

Where does it say that?

I think you're misinterpreting what "It does not throw if it could not convert the entire input" means. It does not mean "it does not throw, period". It also doesn't mean "It does not throw if it could not convert any part of the input". What it means is that if it finds a valid value at the start of the input, which it consumes and returns, it leaves the rest of the input in place, which is useful when you need to parse as much of a string (or character range) up until a non-specific separator or character not representing the value.

--

https://issues.dlang.org/show_bug.cgi?id=17438

Vladimir Panteleev <dlang-bugzilla@thecybershadow.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|---                         |WORKSFORME

--- Comment #4 from Vladimir Panteleev <dlang-bugzilla@thecybershadow.net> ---
The description of the function family, as quoted above, says "It does not throw if it could not convert the entire input." Personally I don't find that ambiguous, but I guess we do have a sample size of one of it being misinterpreted. I find it unambiguous because if you were to interpret it as "it does not throw", it would mean that 1) the last part of the sentence would be redundant as well as misleading, and would have no reason to be included; 2) as pointed out, it would contradict the individual functions' "Throws:" sections; 3) if the functions were to never throw, what would their return value be when absolutely no useful information was extracted from the input text?

Since as far as I can see this issue was filed out of a misinterpretation of the documentation, and there's been no reply to my last comment in over 24h, I guess the misunderstanding has been settled; either way, I don't see any actionable point here right now. If you think that the misunderstanding occurred due to something lacking in the documentation and can suggest a concrete improvement to the documentation that would avoid such a misunderstanding from occurring again, please reopen and/or submit a pull request.

(In reply to Brad Roberts from comment #2)
> Re-read the description of the parse family of functions I cut and pasted into the bug report (which is still what the page says).

Funny how you're telling people to re-read things when the misunderstanding was on your side. Let's be nice, OK? :)

--