checkedint call removal

[Johannes Pfau via Digitalmars-d]

Am Sat, 02 Aug 2014 12:19:41 -0700
schrieb Walter Bright <newshound2 at digitalmars.com>:

> On 8/2/2014 6:20 AM, Artur Skawina via Digitalmars-d wrote:
> > The bug was _introduced_ by the assert, the code was 100% correct.
> 
> Asserts are part of the code, and writing incorrect asserts is
> writing buggy code.
> 

Just some meta points:

I just want to point out that nobody wants to hear 'your code was buggy
anyway' after a compiler update broke working code. A few months ago
you and Andrei were talking about PR and you often said that D is now
'stable' and 'ready for production'. But we still hear claims on reddit
and other sites that D is unstable, breaks code with every release, etc.

And you still think that changing the behavior of assert is a good
idea? Even if assert was always meant to work like this, even if the
spec clearly defined it this will be a PR disaster. People don't care
what was in the spec, the only thing they know is the code worked
before, now it doesn't work anymore ==> blame it on the
compiler/language.

Just envision the situation when somebody post on reddit 'My code has
been broken by this compiler release' then spents quite some
time to track it down and complains about the assert changes? Will you
then reply 'You're code was broken anyway'?

What about Scott Meyers basically telling us that we should make the
language 'predictable' for the users? Doesn't the existence and size of
this discussion already prove that making assert work like assume will
be unexpected for many people? You even admitted that in other
languages assert has a different meaning. You argued against the name
'volatile' cause it has a different meaning in other languages. How
does this not apply to assert/assume? You might ask for Scotts opinion
about this case if you don't believe the people in this thread.

Does anybody have some numbers about the (best case) performance
benefits? Do such performance benefits only manifest if we place assume
everywhere or do we have 'hot' code paths? If we have 'hot' code paths,
adding 'assume' is easy to do. If we have to place assume everywhere
then this is an argument for reusing assert. Making such a decision
without any numbers, based only gut feeling is not a good idea.


(Also regarding DIP65 and other issues with inconsistencies in the
language it's amazing how we absolutely can't break code there, but in
this case it's OK, because the code was already broken anyway. You
could probably construct such an argument for every breaking change and
this makes breaking changes unpredictable and will reinforce the
image of D as an unstable language)