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
