List of Phobos functions that allocate memory?
Jonathan M Davis
jmdavisProg at gmx.com
Sat Feb 8 19:54:06 PST 2014
On Saturday, February 08, 2014 18:03:54 Meta wrote:
> On Saturday, 8 February 2014 at 11:24:56 UTC, Dmitry Olshansky
>
> wrote:
> > 08-Feb-2014 03:01, Meta пишет:
> >> 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:
> >> You could always return an Option!char. Nullable won't work
> >> because it
> >> lets you access the naked underlying value.
> >
> > This is ridiculously distracting suggestion and simply has no
> > merits whatsoever.
> >
> > To underline how impractical this suggestion is: currently
> > every code out there expect dchar out of .front not some magic
> > animal called 'Option!char'.
>
> I'm not actually suggesting a replacement. Just wishful thinking
> on how the function could've been better designed.
I don't see how returning Nullable!dchar would improve decode function at all.
Currently, it throws on invalid UTF, so you don't have to check the return
value, and your code can avoid caring about decode errors except for the
points where you put your catches (which are generally in far fewer places
than the number of places that decode gets called - be it directly or
indirectly). On the other hand, with Nullable!dchar, you'd have to always
check the result or risking hitting an assertion when you don't check the
result (or ending up with dchar.init in -release). I don't see how that's
better than the current situation at all. It just makes decode harder to use.
And Dmitry's suggestion is better than both. We end up returning the Unicode
character specifically intended to designate bad encodings (\uFFFD) such that
you don't even have to care that there was a decode error. You just decode the
string and use it. It will just be one more character in the string that
doesn't match what you're looking for for find and the like, and pretty much
nothing should choke on it. Anything which then cares about Unicode validity
can use isValidUnicode (once we have it) to validate the string instead of
relying on decode to throw. It will clean up string processing in the face of
invalid Unicode quite nicely.
So, I don't see how using Nullable!dchar as you suggest would ever have been a
better design.
- Jonathan M Davis
More information about the Digitalmars-d
mailing list