List of Phobos functions that allocate memory?

[Meta]

On Friday, 7 February 2014 at 23:45:06 UTC, Jonathan M Davis 
wrote:
> On Friday, February 07, 2014 23:01:46 Meta wrote:
>> 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.
>
> How is that any better than returning an invalid dchar with a 
> specific value?
> In either case, you have to check the value. With the 
> exception, code doesn't
> have to care. If the string is invalid, it'll get a 
> UTFException, and it can
> handle it appropriately, but having to check the return value 
> just adds
> overhead (albeit minimal) and is error-prone, because it 
> generally won't be
> checked (and if it is checked, it complicates the calling code, 
> because it has
> to do the check).

We have had this discussion at least once before. A hypothetical 
Option type will not let you do anything with the wrapped value 
UNTIL you check it, as opposed to returning null, -1, some 
special Unicode value, etc. Trying to use it before this check is 
necessarily a compile-time error. This is both faster than 
exceptions and safer than special "error values" that are only 
special by convention. I recall that you've worked with Haskell 
before, so you must know how useful this pattern is.

> Code that doesn't want to risk a UTFException being thrown can 
> validate up
> front - and that validator function return bool and _not_ 
> throw. But having
> decode not throw is going to be error-prone. It also doesn't 
> help performance-
> wise, because it still has to do all of the same validity 
> checks as it
> decodes. It's just that instead of throwing, it returns an 
> error value. I
> really think that having decode throw on invalid Unicode is the 
> right
> decision, and I don't see what we gain by making it not throw.
>
> - Jonathan M Davis