Walter Bright <[email protected]> wrote: > On 10/4/2014 3:30 AM, Steven Schveighoffer wrote: >> On 10/4/14 4:47 AM, Walter Bright wrote: >>> On 9/29/2014 8:13 AM, Steven Schveighoffer wrote: >>>> I can think of cases where it's programmer error, and cases where it's >>>> user error. >>> >>> More carefully design the interfaces if programmer error and input error >>> are conflated. >>> >> >> You mean more carefully design File's ctor? How so? > > You can start with deciding if random binary data passed as a "file > name" is legal input to the ctor or not.
I think it helps to see contracts as an informal extension to the type system. Ideally, the function signature would not allow invalid input at all. In practice, that's not always possible and contracts are a less formal way to specify the function signature. But conceptually they are still part of the signature. And of course (as with normal contract-less functions) you are always allowed to provide convenience functions with extended input validation. Those should then be based on the strict version. For example take a constructor for an XML document class. It could take the (unvalidated) file path as string parameter. Or a file (validated that it exists) object. Or a stream (validated that it exists and is already opened). You can provide all three for convenience, but I think it's still good design to provide three _different_ functions. Contracts are not a magical tool to provide you all three variants in one function depending somehow on the needs of the caller. Tobi
