Libmill: Go-Style Concurrency in C
The macro should be called <i>select</i>, since that&#x27;s what Go calls it. (Of course I know there is a POSIX function (not C) by that name; so what).<p>This &quot;choose {&quot; &quot;end }&quot; business is an awful way to design the macro. If you need nesting that involves a block, with prolog and epilog material on either or both ends, you just have to hide that into the macro:<p><pre><code>  selbegin;

    out(ch, int, 42):
      foo();
    in(ch, int, i):
      bar(i);
    otherwise:
      baz();
    
  selend;
</code></pre>
I don&#x27;t understand the downvotes. I have 30 years of (continous!) C experience. This is the best practice for doing a macro like this.<p>This &quot;end }&quot; business has improper nesting, visually. The <i>choose</i> is outside of the braces, the <i>end</i> is within; it is scatter-brained. There is no error checking for a forgotten <i>end</i>.<p>I&#x27;m looking at the implementation and it&#x27;s looking quite weird! <i>choose</i> simply expands into <i>mill_choose_init__</i>, and <i>end</i> expands into <i>mill_choose_end__</i>.  The definitions of these seem as if they should pair together:<p><pre><code>  #define mill_choose_init__ \
      {\
          mill_choose_init_(MILL_HERE_);\
          int mill_idx = -2;\
          while(1) {\
              if(mill_idx != -2) {\
                  if(0)


  #define mill_choose_end__ \
                      break;\
                  }\
              }\
              mill_idx = mill_choose_wait_();\
          }

</code></pre>
But, oops, look at the obvious lack  of balance in the braces.<p><pre><code>   mill_choose_init__ {

   mill_choose_end__ }
</code></pre>
we are putting a brace after the if (0)  which balances the one after break, and the final missing brace that balances the one opened internally in mill_choose_init__.<p>There are best practices to design this sort of macrology that don&#x27;t require the user put braces in weird places to balance the inconsistencies in macro expansions.<p>Speaking as a professional, I would not pass this in a code review.<p>That we have to use a flaky preprocessor in order to get a half decent syntax is already a significant regret. We must not compound the regret by allowing the macrology to be less than as good as it can be.