List of Phobos functions that allocate memory?

Meta jared771 at gmail.com
Fri Feb 7 15:01:46 PST 2014


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.


More information about the Digitalmars-d mailing list