11–20 of 21 posts
I believe this is just about the behavior of std.debug.assert. You can pretty easily have a different kind of assert that disappears in release builds (if you want).
> you can implement your own version that internally checks a build-time flag, approximating C/C++ behavior
Asserts in any language must not be added willy-nilly but following a specific methodology viz. Design By Contract (DbC) - https://en.wikipedia.org/wiki/Design_by_contract DbC was first introduced in Eiffel but the ideas can be used in any language. See the following; 1) Design by Contract and Assertions - https://www.eiffel.org/doc/solutions/Design_by_Contract_and_... 2) Applying "Design by Contract" (pdf) - https:/…
I really like the Oracle tutorial on Java asserts. https://docs.oracle.com/javase/8/docs/technotes/guides/langu... And I'm pretty happy with its design considering its age. Notably this is not a function call and indeed things are not called unless you enable it. Contrast with Zig. So I guess you will only suffer from code bloat if you never enable them. The tutorial mentions the dangers of side effects. But it also…
I really like the Oracle tutorial on Java asserts. https://docs.oracle.com/javase/8/docs/technotes/guides/langu... And I'm pretty happy with its design considering its age. Notably this is not a function call and indeed things are not called unless you enable it. Contrast with Zig. So I guess you will only suffer from code bloat if you never enable them. The tutorial mentions the dangers of side effects. But it also…
"And I'm pretty happy with its design considering its age." Java did the right thing for assertions but then completely failed for the analoguous issue when it comes to logging. I admit that logging is more complex because you often want it configurable dynamically at runtime. But I'd argue that the language should not be in your way if all you need is a compile time decision and the contortions we made for logging t…
Asserts in any language must not be added willy-nilly but following a specific methodology viz. Design By Contract (DbC) - https://en.wikipedia.org/wiki/Design_by_contract DbC was first introduced in Eiffel but the ideas can be used in any language. See the following; 1) Design by Contract and Assertions - https://www.eiffel.org/doc/solutions/Design_by_Contract_and_... 2) Applying "Design by Contract" (pdf) - https:/…
(For what it's worth I didn't downvote you.)
Asserts in any language must not be added willy-nilly but following a specific methodology viz. Design By Contract (DbC) - https://en.wikipedia.org/wiki/Design_by_contract DbC was first introduced in Eiffel but the ideas can be used in any language. See the following; 1) Design by Contract and Assertions - https://www.eiffel.org/doc/solutions/Design_by_Contract_and_... 2) Applying "Design by Contract" (pdf) - https:/…
There's more to design-by-contract than asserts, and DbC isn't the only way to use asserts. Most languages lack proper support for design-by-contract. (For what it's worth I didn't downvote you.)
The point is that when using asserts you think about correctness w.r.t. specifications and nothing else. To think of it as simply validating arguments or in terms of effects on optimization is quite the wrong thing to do.
PS: I don't bother about upvotes/downvotes but am often reminded of the following Sherlock Holmes quote when i see HN's reaction to deeper subjects ;-)
Pshaw, my dear fellow, what do the public, the great unobservant public, who could hardly tell a weaver by his tooth or a compositor by his left thumb, care about the finer shades of analysis and deduction!"
Earlier quoted context omitted.
There's more to design-by-contract than asserts, and DbC isn't the only way to use asserts. Most languages lack proper support for design-by-contract. (For what it's worth I didn't downvote you.)
DbC is the Policy (i.e. what/why) and Asserts are the Mechanism (i.e. how) ( https://en.wikipedia.org/wiki/Separation_of_mechanism_and_po... ) DbC can be implemented in any language that provides an assert-like mechanism (whether named "assert" or not). An Assert merely validates the state of a program at a particular point during execution. You use it to steer the program to go through only the correct subset of the…
The ideal way to do runtime-checked DbC is not with simple asserts, it's with proper first-class preconditions and postconditions at the language level.
It wouldn't be nice to have to manually ensure that both old and new states of variables are in-scope for postcondition checking. I can imagine that being not just tedious, but error-prone.
> An Assert merely validates the state of a program at a particular point during execution.
Some aspect of the program's state, yes, and hopefully that's all it does.
Interesting to think about the edge-cases here though. Depending on the language, it could accidentally side-effect, or even invoke undefined behaviour, and so actively derail the program. Can't blame DbC for that though, that's a question of language safety.
> You use it to steer the program to go through only the correct subset of the state space of the program
I'm not sure I follow here. You don't use asserts to steer flow-control, you use them to check aspects of program state.
> You could do this pre/post every executable statement (i.e. write proof of correctness)
That doesn't constitute a proof of correctness, no more than last time you and I discussed this. [0] Depending on the language, it wouldn't even necessarily prove the correctness of that particular trace, as you haven't proven that you haven't accidentally invoked undefined behaviour.
You hold a minority opinion on this, please stop presenting it as settled fact.
> The point is that when using asserts you think about correctness w.r.t. specifications and nothing else. To think of it as simply validating arguments or in terms of effects on optimization is quite the wrong thing to do.
I'm not sure why you'd think I don't already know that.
Asserts in any language must not be added willy-nilly but following a specific methodology viz. Design By Contract (DbC) - https://en.wikipedia.org/wiki/Design_by_contract DbC was first introduced in Eiffel but the ideas can be used in any language. See the following; 1) Design by Contract and Assertions - https://www.eiffel.org/doc/solutions/Design_by_Contract_and_... 2) Applying "Design by Contract" (pdf) - https:/…
Asserts in any language must not be added willy-nilly but following a specific methodology viz. Design By Contract (DbC) - https://en.wikipedia.org/wiki/Design_by_contract DbC was first introduced in Eiffel but the ideas can be used in any language. See the following; 1) Design by Contract and Assertions - https://www.eiffel.org/doc/solutions/Design_by_Contract_and_... 2) Applying "Design by Contract" (pdf) - https:/…
As a contrast to Zig: C3 is strongly invested in contracts and is able to use them for static analysis at compile time to some degree.
A user raised some confusion with the wording about Contracts in your documentation which was not answered and is still there. I think it should be fixed since there are lots of people who are confused about contracts and how it differs from error handling. Add to this people's confusion about asserts at runtime and how the optimizer may mess it up and you have a veritable rat's nest of confused thoughts/opinions.
Is your approach to static analysis/verification something like what Frama-C does? I had always wished somebody would wrap C/C++ with a full blown static analysis/verification plus runtime framework and make everything into a single integrated whole like for example the Dafny language. Everything should be doable in a single implementation language with annotations as needed.