On Tuesday, 20 June 2017 at 23:43:47 UTC, Walter Bright wrote:
> Those strings eat up space and are of pretty marginal utility. Don't want to make assert's so bloatsome that people are discouraged from using them.

Ah, so that's why you exclude the strings in -betterC whose main reason for existing is targeting resource-limited microcontrollers, yet include them now in a default build, which is aimed at main computers with gigabytes of space. I understand now.


...oh wait it currently does EXACTLY THE OPPOSITE. If you are seriously concerned about the bytes, why include them in -betterC?

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.

 3. Allow an additional compiler flag for more informative, but heavier asserts, e.g. `-release=informativeAsserts`.

 4. Allow a pragma in the code, e.g. `pragma(asserts, none/regular/informative)` for what kinds of asserts are to be used at a given moment.

 5. ???

[1] http://forum.dlang.org/post/mailman.3531.1498022870.31550.digitalmars-d@puremagic.com
[2] http://fluentasserts.szabobogdan.com/
[3] http://forum.dlang.org/post/mailman.3511.1497981037.31550.digitalmars-d@puremagic.com

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?

i did in aliced: just added printing of `assert` condition. that's all. no variable dumps, no other things -- just `.toChar()` the condition, and print it. and you know what? it is *surprisingly* effective, eats *no* additional compiler resources, and solved all the problems with "dumb asserts" i had.

for some reason people insisting on printing every thing that is possible to print in `assert`. it is rarely interesting IRL, 'cause most of the time it will print nonsence anyway. failed assert usually means either that something went *very* wrong long before it, or it is almost immediately obvious *what* exactly is wrong, without dumping garbage variables.

p.s.: `assert` is not there to debug your code, it is there to *guard* your code. if it is not clear what is wrong from printing ONLY failed condition (without variable values), then you have to debug it "for real".

On Wednesday, 21 June 2017 at 14:00:33 UTC, ketmar wrote:
> i did in aliced: just added printing of `assert` condition. that's all. no variable dumps, no other things -- just `.toChar()` the condition, and print it. and you know what? it is *surprisingly* effective, eats *no* additional compiler resources, and solved all the problems with "dumb asserts" i had.

You use it to locate the assert?

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

On Tuesday, 20 June 2017 at 04:45:21 UTC, Walter Bright wrote:
> Please file bugzilla issues for remaining problems.

I'll do you one better: https://github.com/dlang/dmd/pull/6922

It is a trivial patch to hack fix the big issue I have. Then the real fix is what Lucia is working on, based on her dconf talk. But since betterC is a hack fix in the first place, I say pull that in with your PR and together, we have a *working* "better C".

Then, the last thing from my complaint list (which I wrote in TWID and emailed to you back October) is that struct destructors don't work....

On Wednesday, 21 June 2017 at 15:37:03 UTC, Adam D. Ruppe wrote:
> Then, the last thing from my complaint list (which I wrote in TWID and emailed to you back October) is that struct destructors don't work....

https://github.com/dlang/dmd/pull/6923


If you want bugzilla entries you can make them yourself from the patches. But these two follow up fix the issues I laid out in that first one you linked to earlier.

On 6/21/2017 6:21 AM, Adam D. Ruppe wrote:
> If you are seriously concerned about the bytes, why include them in -betterC?

All I did was make them do what the host C compiler does.

On 6/21/2017 9:24 AM, Adam D. Ruppe wrote:
> If you want bugzilla entries

It isn't a question of me "wanting" bugzilla entries or me "liking" bugzilla (as another member recently put it). It's our process so that issues can be logged, tracked, changelogs compiled, etc. Please follow our process.


> you can make them yourself from the patches.

I can do everything. But that doesn't scale at all, and progress on D would grind to a virtual halt if I tried.