Checking function parameters in Phobos

[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.

A second, just as interesting topic, is how to design abstractions for 
speed and safety. There are cases in which spurious checking is 
prohibitively expensive if not necessary, so it should be avoided where 
necessary. Examples:

(a) FracSecs(long x) validates x to be within range. The cost of the 
validation itself is about as high as the payload itself (which is one 
assignment).

(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.

(c) A variety of text functions currently suffer because we don't make 
the difference between validated UTF strings and potentially invalid ones.

Walter and I are thinking of fostering the idiom in which types (or 
attributes?) are used as information about validation, similar to how 
assumeSorted works. Building on that, we'd have a function like "static 
FracSecs assumeValid(long)" inside FracSecs (no need for a different 
type here). Then, we'd have a CleanUTF type or something that would 
guarantee the string stored within has been validated.


Please chime in with ideas!

Andrei