4 ms·

Why is "defer" not considered "explicitly declaring control flow" if the documentation describes it correctly?

naasking 4y ago
Because the control flow happens implicitly at the end of the block, not explicitly as with goto, loop, if-statements, etc. A deferred statement can also have arbitrary time and space complexity, so it's not like a variable going out of scope at the end of a block which is constant time. It furthermore requires invocation of all deferred statements while unwinding the stack upon calling exit(). See the details here: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2589.pdf https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2589.pdf
- yazaddaruvala 4y ago
  > Because the control flow happens implicitly at the end of the block Why is this different than any loop in C? or function without a return? Wouldn’t it be more explicit and very minimal overhead to instead always use a goto at the end of a looping block? Even tho C allows while loops (as a mistake - all control flow should be explicitly defined at the end of the block), why aren’t you - as a best practice - using an explicit goto and if block instead of while / for?
  - naasking 4y ago
    > Why is this different than any loop in C? or function without a return? Because it's non-local control flow. Did you just ignore my whole comment where I pointed out where cases like exit() unwinds the stack, invoking deferred block in each caller up the call chain back to the root? Does for/while do that?
    - yazaddaruvala 4y ago
      I really did read it, I just really believe that your biases are clouding your critical thought about this. > invoking deferred block in each caller up the call chain back to the root Yes if the caller writes N defers in the same function or across M functions then the code will run N defers. Why is this any different than nesting N loops, in the same function or across M functions? It’ll still run N end of block control flow statements without them being “explicit”. At the end of the day “explicit” typically is really just a replacement for saying “familiar with the previous documentation, don’t change things”. Anyways, that’s all I can put into this conversation. Please just try to consider that you’re conflating familiarity with simplicity and leverage System 2 to really ask yourself if what you’re favoring is valuable to the group or just the NIMBY.
      - naasking 4y ago
        I honestly can't summarize the extra runtime complexity any more clearly than I already have. The original poster was very clear about keeping the runtime complexity down for various well-motivated reasons. They are correct that if you want more runtime support for high-level features, then C is perhaps not the language for you.

Because the control flow happens implicitly at the end of the block, not explicitly as with goto, loop, if-statements, etc. A deferred statement can also have arbitrary time and space complexity, so it's not like a variable going out of scope at the end of a block which is constant time. It furthermore requires invocation of all deferred statements while unwinding the stack upon calling exit(). See the details here: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2589.pdf https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2589.pdf

yazaddaruvala 4y ago
> Because the control flow happens implicitly at the end of the block Why is this different than any loop in C? or function without a return? Wouldn’t it be more explicit and very minimal overhead to instead always use a goto at the end of a looping block? Even tho C allows while loops (as a mistake - all control flow should be explicitly defined at the end of the block), why aren’t you - as a best practice - using an explicit goto and if block instead of while / for?
- naasking 4y ago
  > Why is this different than any loop in C? or function without a return? Because it's non-local control flow. Did you just ignore my whole comment where I pointed out where cases like exit() unwinds the stack, invoking deferred block in each caller up the call chain back to the root? Does for/while do that?
  - yazaddaruvala 4y ago
    I really did read it, I just really believe that your biases are clouding your critical thought about this. > invoking deferred block in each caller up the call chain back to the root Yes if the caller writes N defers in the same function or across M functions then the code will run N defers. Why is this any different than nesting N loops, in the same function or across M functions? It’ll still run N end of block control flow statements without them being “explicit”. At the end of the day “explicit” typically is really just a replacement for saying “familiar with the previous documentation, don’t change things”. Anyways, that’s all I can put into this conversation. Please just try to consider that you’re conflating familiarity with simplicity and leverage System 2 to really ask yourself if what you’re favoring is valuable to the group or just the NIMBY.
    - naasking 4y ago
      I honestly can't summarize the extra runtime complexity any more clearly than I already have. The original poster was very clear about keeping the runtime complexity down for various well-motivated reasons. They are correct that if you want more runtime support for high-level features, then C is perhaps not the language for you.