> So, then the user calling the library with foo(3.5) will get a runtime error (or, ok, maybe even a compile time error).
I'm not sure I understand this. See below, but the larger point here is that the type can never lie -- names can and often do because there's no checking on names.
I think what is being proposed is something similar to
newtype Accuracy = Accuracy Float
and then to have the only(!) way to construct such a value be a function
mkAccuracy :: Float -> Maybe Accuracy
which does the range checking, failing if outside the allowable range.
Any functions which needs this Accuracy parameter then just take a parameter of that type.
That way you a) only have to do the check at the 'edges' of your program (e.g. when reading config files or user input), and b) ensure that functions that take an Accuracy parameter never fail because of out-of-range values.
It's still a runtime-check, sure, but but having a strong type instead of just Float, you can ensure that you only need that checking at the I/O edges of your program and absolute assurance that any Accuracy handed to a function will always be in range.
You can do a similar thing in e.g. C with a struct, but unfortunately I don't think you can hide the definition such that it's impossible to build an accuracy_t without going through a "blessed" constructor function. I guess you could do something with a struct containing a void ptr where only the implementation translation unit knows the true type, but for such a "trivial" case it's a lot of overhead, both code-wise and because it would require heap allocations.