Checking function parameters in Phobos

[bearophile]

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