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