On Friday, 7 February 2014 at 22:57:26 UTC, Jonathan M Davis
wrote:
On Friday, February 07, 2014 20:43:38 Dmitry Olshansky wrote:
07-Feb-2014 20:29, Andrej Mitrovic пишет:
> On Friday, 7 February 2014 at 16:27:35 UTC, Andrei
> Alexandrescu wrote:
>> Add a bugzilla and let's define isValid that returns bool!
>
> Add std.utf.decode() to that as well. IOW, it should have an
> overload
> which returns a status code
Much simpler - it returns a special dchar to designate bad
encoding. And
there is one defined by Unicode spec.
Isn't that actually worse? Unless you're suggesting that we
stop throwing on
decode errors, then functions like std.array.front will have to
check the
result on every call to see whether it was valid or not and
thus whether they
should throw, which would mean extra overhead over simply
having decode throw
on decode errors. validate has no business throwing, and we
definitely should
add isValidUnicode (or isValid or whatever you want to call it)
for validation
purposes. Code can then call that to validate that a string is
valid and not
worry about any UTFExceptions being thrown as long as it
doesn't manipulate
the string in a way that could result in its Unicode becoming
invalid.
However, I would argue that assuming that everyone is going to
validate their
strings and that pretty much all string-related functions
shouldn't ever have
to worry about invalid Unicode is just begging for subtle bugs
all over the
place IMHO. You're essentially dealing with error codes at that
point, and I
think that experience has shown quite clearly that error codes
are generally a
bad way to go. Almost no one checks them unless they have to. I
think that
having decode throw on invalid Unicode is exactly what it
should be doing. The
problem is that validate shouldn't.
- Jonathan M Davis
You could always return an Option!char. Nullable won't work
because it lets you access the naked underlying value.
