5 ms·

A comment "this CANNOT happen" has no value on itself. Unless you've formally verified the code (including its dependencies) and have the proof linked, such com

by skydhash 10mo ago

A comment "this CANNOT happen" has no value on itself. Unless you've formally verified the code (including its dependencies) and have the proof linked, such comments may as well be wishes and prayers. Yes, sometimes, the compiler or the hardware have bugs that violate the premises you're operating on, but that's rare. But most non pure algorithms (side effects and external systems) have documented failure cases.

JohnFen 10mo ago
> A comment "this CANNOT happen" has no value on itself. I think it does have some value: it makes clear an assumption the programmer made. I always appreciate it when I encounter comments that clarify assumptions made.
- skydhash 10mo ago
  Such comments rot so rapidly that they're an antipattern. Such assumptions are dangerous and I would point it out in a PR.
  - LegionMammal978 10mo ago
    Do you not make such a tacit assumption every time you index into an array (which in almost all languages throws an exception on bounds failure)? You always have to make assumptions that things stay consistent from one statement to the next, at least locally. Unless you use formal verification, but hardly anyone has the time and resources for that.
    - skydhash 10mo ago
      If such an error happens, that would be a compiler bug. Why? Because I usually do checks against the length of the array or have it done as part of the standard functions like `map`. I don't write such assumptions unless I'm really sure about the statements, and even then I don't.
      - tosapple 10mo ago
        How does one defend against cosmic rays? Keep two copies or three like RAID? Edit: ECC ram helps for sure, but what else?
        well_ackshually 10mo ago
        >How does one defend against cosmic rays? Unless you are in the extremely small minority of people who would actually be affected by it (in which case your company would already have bought ECC ram and made you work with three isolated processes that need to agree to proceed): you don't. You eat shit, crash and restart.
        tosapple 10mo ago
        Well, bitflip errors are more of a vulnerability for longer lived values. This could effect fukushima style robots or even medical equipment. ECC implemented outside of ram would save vs triplicate but it was just a question related to the-above idea of an array access being assumed as in+bounds. Thank you.
        JonChesterfield 10mo ago
        You run equivalent or equal calculations simultaneously on N computers and take majority wins, aircraft control or distributed filesystem style.
      - LegionMammal978 10mo ago
        > or have it done as part of the standard functions like `map`. Which are all well and good when they are applicable, which is not always 100% of the time. > Because I usually do checks against the length of the array And what do you have your code do if such "checks" fail? Throw an assertion error? Which is my whole point, I'm advocating in favor of sanity-check exceptions. Or does calling them "checks" instead of "assumptions" magically make them less brittle from surrounding code changes?
        skydhash 10mo ago
    - lmm 10mo ago
      > Do you not make such a tacit assumption every time you index into an array (which in almost all languages throws an exception on bounds failure)? Yes, which is one reason why decent code generally avoids doing that.
      - MobiusHorizons 10mo ago
        Are you saying decent code avoids indexing into arrays? Or are you saying it avoids doing so without certainty the bounds checks will succeed?
        lmm 10mo ago
        Decent code generally avoids indexing into arrays at all; if it does so then it does so in ways where the bound checks are so certain to succeed that you can usually explain it to the compiler (e.g. split an array into slices and access those slices).
        MobiusHorizons 10mo ago
        that is what I thought you were saying, and it doesn't make much sense to me. AFAICT the point of arrays as a data structure is to allow relatively cheap indexing at the cost of more expensive resizing operations. What else would you do with an array other than index into it? > e.g. split an array into slices and access those slices How is this not indexing with a little abstraction? Aren't slices just a way of packaging an array with a length field it a standard way? I'm not aware of many array implementations without a length (and usually also capacity) field somewhere , so this seems like a mostly meaningless distinction (ie all sclices are arrays, right).
        lmm 10mo ago
        > AFAICT the point of arrays as a data structure is to allow relatively cheap indexing at the cost of more expensive resizing operations. What else would you do with an array other than index into it? The main thing you do with arrays is bulk operations (e.g. multiply it by something), which doesn't require indexing into it. But yeah I think they're a fairly niche datastructure that shouldn't be privileged the way certain languages do. > How is this not indexing with a little abstraction? Aren't slices just a way of packaging an array with a length field it a standard way? Sure (well, offset and length rather than just a length) but the abstraction is safe whereas directly indexing into the array isn't.
- addaon 10mo ago
  But if you spell that `assert(false)` instead of as a comment, the intent is equally clear, but the behavior when you're wrong is well-defined.
  - eterm 10mo ago
    Better yet, `assert(false, message)`, with the message what you would have written in the comment.
    - addaon 10mo ago
      `assert(false)` is pronounced "this can never happen." It's reasonable to add a comment with /why/ this can never happen, but if that's all the comment would have said, a message adds no value.
      - eterm 10mo ago
        Oh I agree, literally `assert(false, "This cannot happen")` is useless, but ensuring message is always there encourages something more like, `assert(false, "This implies the Foo is Barred, but we have the Qux to make sure it never is")`. Ensuring a message encourages people to state the assumptions that are violated, rather than just asserting that their assumptions (which?) don't hold.
      - breatheoften 10mo ago
        what language are we talking about? If it's cpp then the pronounciation depends on compiler flags (perhaps inferred from CMAKE_BUILD_TYPE)
    - andrewf 10mo ago
      Swap the parameters around for C++ and similar langs where `assert(a, b)` evaluates the same as `(void) a; assert(b)`.
  - JohnFen 10mo ago
    I agree that including that assert along with the comment is much better. But the comment alone is better than nothing, so isn't without value.
- dllthomas 10mo ago
  Importantly, specifying reasoning can have communicative value while falling very far short of formal verification. Personally, I also try to include a cross reference to the things that could allow "this" to happen were they to change.
- AdieuToLogic 10mo ago
  >> A comment "this CANNOT happen" has no value on itself. > I think it does have some value: it makes clear an assumption the programmer made. To me, a comment such as the above is about the only acceptable time to either throw an exception (in languages which support that construct) or otherwise terminate execution (such as exiting the process). If further understanding of the problem domain identifies what was thought impossible to be rare or unlikely instead, then introducing use of a disjoint union type capable of producing either an error or the expected result is in order. Most of the time, "this CANNOT happen" falls into the category of "it happens, but rarely" and is best addressed with types and verified by the compiler.
AnimalMuppet 10mo ago
Worse: You may created the proof. You may have linked to the proof. But if anyone has touched any of the code involved since then, it still has no value unless someone has re-done the proof and linked that. (Worse, it has negative value, because it can mislead.)
- skydhash 10mo ago
  Not really. A quick git blame (or alternative) will give you the required information about the validity of such proof.
  - dullcrisp 10mo ago
    You must have some git plugin I haven’t heard about.
    - skydhash 10mo ago
      Git blame will show the commit and the date for each line. It’s easy to verify if the snippet has changed since the comment. i use Emacs and it’s builtin vc package that color code each block.
      - AnimalMuppet 10mo ago
        But you need the snippet and, potentially, the entire call tree (both up and down).
        dullcrisp 10mo ago
        And anything that can affect relevant state, any dependencies that may have changed, validations to input that may have been modified; it’s hard to know without knowing what assumptions the assertion is based on.
threethirtytwo 10mo ago
False it has value. It’s actually even better to log it or throw an exception. print(“this cannot happen.”) If you see it you immediately know the class of error is purely a logic error the programmer made a programming mistake. Logging it makes it explicit your program has a logic bug. What if you didn’t log it? Then at runtime you will have to deduce the error from symptoms. The log tells you explicitly what the error is.

JohnFen 10mo ago

> A comment "this CANNOT happen" has no value on itself. I think it does have some value: it makes clear an assumption the programmer made. I always appreciate it when I encounter comments that clarify assumptions made.

skydhash 10mo ago
Such comments rot so rapidly that they're an antipattern. Such assumptions are dangerous and I would point it out in a PR.
- LegionMammal978 10mo ago
  Do you not make such a tacit assumption every time you index into an array (which in almost all languages throws an exception on bounds failure)? You always have to make assumptions that things stay consistent from one statement to the next, at least locally. Unless you use formal verification, but hardly anyone has the time and resources for that.
  - skydhash 10mo ago
    If such an error happens, that would be a compiler bug. Why? Because I usually do checks against the length of the array or have it done as part of the standard functions like `map`. I don't write such assumptions unless I'm really sure about the statements, and even then I don't.
    - tosapple 10mo ago
      How does one defend against cosmic rays? Keep two copies or three like RAID? Edit: ECC ram helps for sure, but what else?
      - well_ackshually 10mo ago
        >How does one defend against cosmic rays? Unless you are in the extremely small minority of people who would actually be affected by it (in which case your company would already have bought ECC ram and made you work with three isolated processes that need to agree to proceed): you don't. You eat shit, crash and restart.
        tosapple 10mo ago
        Well, bitflip errors are more of a vulnerability for longer lived values. This could effect fukushima style robots or even medical equipment. ECC implemented outside of ram would save vs triplicate but it was just a question related to the-above idea of an array access being assumed as in+bounds. Thank you.
      - JonChesterfield 10mo ago
        You run equivalent or equal calculations simultaneously on N computers and take majority wins, aircraft control or distributed filesystem style.
    - LegionMammal978 10mo ago
      > or have it done as part of the standard functions like `map`. Which are all well and good when they are applicable, which is not always 100% of the time. > Because I usually do checks against the length of the array And what do you have your code do if such "checks" fail? Throw an assertion error? Which is my whole point, I'm advocating in favor of sanity-check exceptions. Or does calling them "checks" instead of "assumptions" magically make them less brittle from surrounding code changes?
      - skydhash 10mo ago
  - lmm 10mo ago
    > Do you not make such a tacit assumption every time you index into an array (which in almost all languages throws an exception on bounds failure)? Yes, which is one reason why decent code generally avoids doing that.
    - MobiusHorizons 10mo ago
      Are you saying decent code avoids indexing into arrays? Or are you saying it avoids doing so without certainty the bounds checks will succeed?
      - lmm 10mo ago
        Decent code generally avoids indexing into arrays at all; if it does so then it does so in ways where the bound checks are so certain to succeed that you can usually explain it to the compiler (e.g. split an array into slices and access those slices).
        MobiusHorizons 10mo ago
        that is what I thought you were saying, and it doesn't make much sense to me. AFAICT the point of arrays as a data structure is to allow relatively cheap indexing at the cost of more expensive resizing operations. What else would you do with an array other than index into it? > e.g. split an array into slices and access those slices How is this not indexing with a little abstraction? Aren't slices just a way of packaging an array with a length field it a standard way? I'm not aware of many array implementations without a length (and usually also capacity) field somewhere , so this seems like a mostly meaningless distinction (ie all sclices are arrays, right).
        lmm 10mo ago
        > AFAICT the point of arrays as a data structure is to allow relatively cheap indexing at the cost of more expensive resizing operations. What else would you do with an array other than index into it? The main thing you do with arrays is bulk operations (e.g. multiply it by something), which doesn't require indexing into it. But yeah I think they're a fairly niche datastructure that shouldn't be privileged the way certain languages do. > How is this not indexing with a little abstraction? Aren't slices just a way of packaging an array with a length field it a standard way? Sure (well, offset and length rather than just a length) but the abstraction is safe whereas directly indexing into the array isn't.
addaon 10mo ago
But if you spell that `assert(false)` instead of as a comment, the intent is equally clear, but the behavior when you're wrong is well-defined.
- eterm 10mo ago
  Better yet, `assert(false, message)`, with the message what you would have written in the comment.
  - addaon 10mo ago
    `assert(false)` is pronounced "this can never happen." It's reasonable to add a comment with /why/ this can never happen, but if that's all the comment would have said, a message adds no value.
    - eterm 10mo ago
      Oh I agree, literally `assert(false, "This cannot happen")` is useless, but ensuring message is always there encourages something more like, `assert(false, "This implies the Foo is Barred, but we have the Qux to make sure it never is")`. Ensuring a message encourages people to state the assumptions that are violated, rather than just asserting that their assumptions (which?) don't hold.
    - breatheoften 10mo ago
      what language are we talking about? If it's cpp then the pronounciation depends on compiler flags (perhaps inferred from CMAKE_BUILD_TYPE)
  - andrewf 10mo ago
    Swap the parameters around for C++ and similar langs where `assert(a, b)` evaluates the same as `(void) a; assert(b)`.
- JohnFen 10mo ago
  I agree that including that assert along with the comment is much better. But the comment alone is better than nothing, so isn't without value.
dllthomas 10mo ago
Importantly, specifying reasoning can have communicative value while falling very far short of formal verification. Personally, I also try to include a cross reference to the things that could allow "this" to happen were they to change.
AdieuToLogic 10mo ago
>> A comment "this CANNOT happen" has no value on itself. > I think it does have some value: it makes clear an assumption the programmer made. To me, a comment such as the above is about the only acceptable time to either throw an exception (in languages which support that construct) or otherwise terminate execution (such as exiting the process). If further understanding of the problem domain identifies what was thought impossible to be rare or unlikely instead, then introducing use of a disjoint union type capable of producing either an error or the expected result is in order. Most of the time, "this CANNOT happen" falls into the category of "it happens, but rarely" and is best addressed with types and verified by the compiler.

AnimalMuppet 10mo ago

Worse: You may created the proof. You may have linked to the proof. But if anyone has touched any of the code involved since then, it still has no value unless someone has re-done the proof and linked that. (Worse, it has negative value, because it can mislead.)

skydhash 10mo ago
Not really. A quick git blame (or alternative) will give you the required information about the validity of such proof.
- dullcrisp 10mo ago
  You must have some git plugin I haven’t heard about.
  - skydhash 10mo ago
    Git blame will show the commit and the date for each line. It’s easy to verify if the snippet has changed since the comment. i use Emacs and it’s builtin vc package that color code each block.
    - AnimalMuppet 10mo ago
      But you need the snippet and, potentially, the entire call tree (both up and down).
      - dullcrisp 10mo ago
        And anything that can affect relevant state, any dependencies that may have changed, validations to input that may have been modified; it’s hard to know without knowing what assumptions the assertion is based on.

threethirtytwo 10mo ago

False it has value. It’s actually even better to log it or throw an exception. print(“this cannot happen.”) If you see it you immediately know the class of error is purely a logic error the programmer made a programming mistake. Logging it makes it explicit your program has a logic bug. What if you didn’t log it? Then at runtime you will have to deduce the error from symptoms. The log tells you explicitly what the error is.