Making preconditions better specified and faster

[Caspar Kielwein via Digitalmars-d]

On Sunday, 18 December 2016 at 21:58:57 UTC, Andrei Alexandrescu 
wrote:
> On 12/18/2016 04:24 PM, Caspar Kielwein wrote:
>> On Sunday, 18 December 2016 at 10:47:42 UTC, Stefan Koch wrote:
>>> On Sunday, 18 December 2016 at 09:32:53 UTC, Caspar Kielwein 
>>> wrote:
>>>> On Thursday, 15 December 2016 at 18:48:22 UTC, Andrei 
>>>> Alexandrescu
>>>> wrote:
>>>>> https://issues.dlang.org/show_bug.cgi?id=16975
>>>>
>>>> I'd love if preconditions where available at the caller. 
>>>> This would
>>>> make it possible to use preconditions for input scrubbing, 
>>>> even in
>>>> release builds with disabled asserts.
>>>
>>> That is exactly what they are not for.
>>
>> I know that contracts are for specifying guarantees and 
>> conditions in
>> regards to correctness of a program.
>
> A simple way to look at this is: a program may build and run 
> with all contracts disabled. If correct, there should be no 
> change in semantics. Is a contract therefore a right place to 
> make sure your files are not corrupt etc? -- Andrei

I'll try clarify what I mean.
I absolutely agree that contracts assert the correctness of the 
program and not of user inputs.

When I pass user inputs to functions with preconditions, I need 
to validate these inputs to make sure the function call and thus 
my program is correct.
The code for this validation is often redundant to the 
specification of the precondition in it's logic. It of cause has 
a very different effect and often different syntax.
I'd like to write something like:
try{
foo.verified(x);
} catch {
...
}
To manually call the check of the precondition and avoid the 
duplication and possibility of missing a case.

Another case (which hits me in my job writing c++) is when I call 
performance critical code from (legacy) code with dubious 
correctness. I'd like to have all asserts enabled at the caller 
side to catch bugs, without the performance hit of enabling 
asserts within a numeric kernel.