On 08/03/14 17:06, Walter Bright via Digitalmars-d wrote:
> On 8/2/2014 1:06 PM, Artur Skawina via Digitalmars-d wrote:
>> There's nothing wrong with `assume`, it's very useful for optimizations.
>> But it's too dangerous to tack `assume` onto `assert`. If they are kept
>> separate then it's at least possible to carefully audit every 'assume'.
>> People *will* use them for micro-optimizations, and they *will* make
>> mistakes.
>
> This seems contradictory. You say it is fine to have assume affect
> optimization, i.e. insert bugs if the assumes are wrong, but not fine to
> check at runtime that the assumes are correct?
I'm saying there's nothing wrong with having an assume(-like) directive;
by default `assume` should of course check the condition at RT just like
`assert` does [1].
I'm against _redefining_ `assert` to mean `assume`. In practice there will
always be a possibility of an assert failing at RT due to eg a different
environment or inputs[2]. If programs always were perfect and absolutely
bug-free, asserts and diagnostics would never be required at all...
Do you really think that it is unreasonable to expect that, in a language
called *D*, a very well known decades old C concept isn't redefined?
That wouldn't be appropriate even for a language called "Mars"...
Of course everybody initially expects that an 'assert' in D acts like
the C equivalent. There isn't anything in the "spec" (ie dlang.org) that
even hints at D's assert being different. ("[...] if the result is false,
an AssertError is thrown. If the result is true, then no exception is
thrown.[...]"). I just looked at the "contracts" page for the first time
ever, and found this: "assert in function bodies works by throwing an
AssertError, which can be caught and handled". That could reasonably be
interpreted to mean that a failing assertion in D still leaves the program
in a well defined valid (!) state.
Most people who are already aware of `assert` will know a definition like
this one: http://pubs.opengroup.org/onlinepubs/009695399/functions/assert.html
"assert - insert program diagnostics [...] The assert() macro shall insert
diagnostics into programs".
Nobody expects that disabling diagnostics introduces undefined behavior.
Hence, slightly inaccurate or not 100% up-to-date asserts are not considered
a real problem. And they are not a problem. Except in D?
artur
[1] An `__assume` that never checks at RT would also be useful for low-level
code, where failure is not an option.
[2] Asserts are not for /directly/ validating inputs, yes, but inputs are
often necessary to get the program to an invalid state.
