Checking function parameters in Phobos

[growler]

On Wednesday, 20 November 2013 at 00:01:00 UTC, Andrei 
Alexandrescu wrote:
> 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

I'm not a Phobos dev. but as a user of Phobos and coming from 
C/C++ I'd like to see...

Less enforce and more debug-only contracts in the std lib, with 
opt-in run-time checks for release builds.

That way I can decide on a function-by-function basis or globally 
at compile time whether the run-time checks occur in release 
builds.

For example, given:

1. FracSecs(long x)
2. FracSecs!Args.verify(long x)

In debug 1. would always have full run-time checking enabled. In 
release builds 1. would only have essential run-time checks, 
preferably none. I can then opt-in for run-time checks in release 
builds using 2.

There would also be a version(ArgsVerify) so I can turn on 
run-time checks globally at compile time in release builds (maybe 
the --debug flag allows this already, not sure).

Of course this unfortunately requires even more work from Phobos 
devs and I'm not a D expert so I don't know how viable it would 
be.

Whatever is decided I'm looking forward to see what you guys come 
up with because I'm currently using Phobos as my "Idiomatic D" 
reference guide.

Thanks G.