dmd -betterC

[Moritz Maxeiner via Digitalmars-d]

On Wednesday, 21 June 2017 at 13:53:02 UTC, MysticZach wrote:
> On Wednesday, 21 June 2017 at 10:51:39 UTC, ketmar wrote:
>> there, of course, *IS* The difference. besides the aesthetical 
>> one (seeing failed condition immediately "clicks" in your 
>> head, and generic "assertion failed" message is only 
>> frustrating), there may be the case when source code changed 
>> since binary was built. here, line number gives you zero 
>> information, and you have to checkout that exact version, and 
>> go check the line. but when failed condition dumped, most of 
>> the time it allows you to see what is wrong even without 
>> switching to the old codebase (yes, "most of the time" is from 
>> RL -- it is literally *most* of the time for me, for example).
>
> How would you solve this issue? By pure chance, we're debating 
> this exact same issue right now in the DIP1009 thread [1].
>
> Solutions:
>
>  1. Make more informative asserts the compiler default. This 
> threatens performance, which argues against it.
>
>  2. Status quo. Make people use whatever asserts they want, 
> e.g. fluent asserts [2]. This would mean that H.S Teoh's 
> proposed syntax for DIP1009 [3] would carry less weight, and 
> the existing proposal would carry more. Elegance is sacrificed 
> for the sake of versatility.
>
> [...]

The verbose (existing) syntax already allows such versatility. I 
see little reason to make the new syntax support that as well, 
since there is (AFAIK) no proposal to drop the verbose syntax 
(and I would be against dropping it, anyway).
I would prefer this:
- Keep the verbose (already existing) syntax with assert 
statements in brace-delimited in/out blocks for people who need 
versatility over elegance
- Make the new syntax elegant for the common cases (as discussed 
in the DIP 1009 round 1 review thread), dropping explicit asserts
- Decouple the semantics of contract checking for the new syntax 
from assert's implementation and define those semantics similar 
to what I wrote here[1]
- Regarding contract conditions printed verbatim on failure: I 
would support that in the implementation sketched by [1] via a D 
version like `PrintViolatedContracts` and not couple that with 
regular asserts at all

[1] 
http://forum.dlang.org/post/vgxvdpqcjobngmzrvnml@forum.dlang.org