Andrei Alexandrescu:
There's been recent discussion herein about what parameter
validation method would be best for Phobos to adhere to.
Currently we are using a mix of approaches:
1. Some functions enforce()
2. Some functions just assert()
3. Some (fewer I think) functions assert(0)
4. Some functions don't do explicit checking, relying instead
on lower-level enforcement such as null dereference and bounds
checking to ensure safety.
Each method has its place. The question is what guidelines we
put forward for Phobos code to follow; we're a bit loose about
that right now.
I think Phobos should rely much more on Contract Programming
based on asserts. This could mean Dmd automatically using a
Phobos compiled with asserts when you compile your D code
normally, and automatically using a assert-stripped version of
Phobos libs when you compile with -release and similar.
In other situations enforce and exceptions are still useful.
(b) sort() offers a SortedRange with its goodies. We also have
assumeSorted that also offers a SortedRange, but relies on the
user to validate that assumption.
I'd like another function, that could be named validateSorted()
that returns a SortedRange and always fully verifies its range
argument is actually sorted, and throws an exception otherwise.
So it doesn't assume its input is sorted. It's like a isSorted +
assumeSorted.
(c) A variety of text functions currently suffer because we
don't make the difference between validated UTF strings and
potentially invalid ones.
Often I have genomic data or other text data that is surely ASCII
(and I can accept a run-time exception at loading time if it's
not ASCII). Once such text is in memory I'd like to not pay for
UTF on it. Sometimes you can do this with
std.string.representation, but there is no opposite function
(http://d.puremagic.com/issues/show_bug.cgi?id=10162 ). Also in
Phobos there are several string/char functions that could be made
faster if the input is assumed to be ASCII. To solve this problem
in languages as Haskell they usually introduce a new type like
AsciiString. In past I have suggested to introduce such string
wrapper in Phobos.
Then, we'd have a CleanUTF type or something that would
guarantee the string stored within has been validated.
In recent talks Bjarne Stroustrup has being advocating a lot such
usage of types for safety in C++11/C++14, and functional
programmers use it often since lot of time. OcaML programmers use
such style of coding to write "safer" code all the time.
Too many types make the code harder (also because D doesn't have
de-structuring syntax in function signatures and so on), but few
strategically designed structs can help.
Bye,
bearophile
