assert semantic change proposal

[Tofu Ninja via Digitalmars-d]

On Wednesday, 6 August 2014 at 08:25:38 UTC, Walter Bright wrote:

Thank you for the well thought out response.

> I responded to the equivalent design proposal several times 
> already, with detailed answers. This one is shorter, but the 
> essential aspects are there. I know those negative aspects came 
> across because they are addressed with your counter:

I was not trying to attack you, but rather inform you. I think 
that is all I want to say on the subject so I am going to stop 
talking about it.

> 1. it's long with an unappealing hackish look

I find this a positive, the proposed assert has quite dangerous 
implications, having a slightly "hackish" look will serve to 
discourage using it when it is not obviously needed.

> 2. it follows in the C++ tradition of the best practice being 
> the long ugly way, and the deprecated practice is the 
> straightforward way (see arrays in C++)

That is implying that the best practice is your version of 
assert. As it can introduce undefined behavior, I find it hard to 
believe.

> 3. users will be faced with two kinds of asserts, with a subtle 
> difference that is hard to explain, hard to remember which is 
> which, and will most likely use inappropriately

This is why I think it would be best added as an annotation on 
assert. People who don't care enough to look up what the extra 
annotation does will just use assert by itself and have no risk 
of undefined behavior and it will behave as expected(similar to 
how it behaves in other languages).


> 4. everyone who wants faster assert optimizations will have to 
> rewrite their (possibly extensive) use of asserts that we'd 
> told them was best practice. I know I'd be unhappy about having 
> to do such to my D code.

This is a fare point but it would happen the same either way. If 
some one used assert expecting it to act like the C assert and 
found out it did not any more, they would be forced to go through 
though there code and change all the asserts. As this is a 
change, I am inclined to say we should favor the old version and 
not force users of the old version to update.

> This is not about my feelings, other than my desire to find the 
> best design based on a number of tradeoffs.

I was just trying to say that it is a possibility that should not 
be forgotten, I think I may have said it in a harsher way than I 
meant to, I apologize. The annotated assert was my attempt at a 
possible compromise.