How to Get Fired Using Switch Statements and Statement Expressions (2016)

I have a Good Fences Make Good Neighbors trick I use, and some people call it a Canary Build.

When contributors to two different modules keep running into contract violations, you set up a CI build that triggers when either of the modules is built. If it fails it means that something got broken. It doesn't stop the build pipeline, but it warns you that garbage is about to come out the other end.

There's a general dynamic between people where peer pressure does not work when the delay between action and consequence grows too long. Nobody truly internalizes how upset other people are when they are found out for something bad they did a year ago, a month ago, or in some cases days ago (hence why roommates fight so often about chores). But getting called out for something you did two hours ago has sorted out an awful lot of bad behavior.

And the nice thing about the Canary Build is that in many CI tools you can set it up and not give him any permissions.

I mean, that isn't exactly hideous code. Sometimes you need to check a variety of different conditions in sequence, and I don't think a switch statement works here.

So what if they're different types? It's not like your passing those variables to functions right there. And are we really so robotic that we can't understand different types in a conditional?

Except the recursive function bit. Why bother if its always false...

I gently encourage you to dust off your copy of the CIA Sabotage Field Manual and set about getting your tormenter fired.

At least he didn't put each one of those statements in separate classes to make you hunt for half a day to figure out what his code does.

Is there a bug in there? What's a better way to structure those tests, if they are logically valid?

Fucking hell that's a nightmare haha

I think you have your comments for 3 and 5 backwards.

If override can only be those 3 and they're all non-zero, and default is when override is 0, then the following seems clearer in my opinion.

  if (override ? override == THING1 : foo == 42) {
    code_here();
  } else if (override ? override == THING2 : bar & 0x42) {
    other_code();
  } else if (override ? override == THING3 : true) {
    more_code();
  }

The very article this thread is about talks about Duff's device. This comment confirms my suspicion that most HN readers, like me, read the comments before optionally reading the article.

It's also used to portably implement generators and coroutines. See https://www.chiark.greenend.org.uk/~sgtatham/coroutines.html More generally, the semantics are useful for machine code generation and translation.

Computed goto's are even more useful for the above, but they're an extension. I'd love to see computed goto's added to the C standard, but it's far too late to change the semantics of switch. Rather, just accept that their code flow semantics make them slightly more type safe syntactic sugar for goto--not just in how they're implemented, but in how they can be used.

*IOCCC

I sorta see where you're coming from, but I can't really see myself avoiding switch entirely in C. I do agree that it's very poorly designed since it makes it very easy to shoot yourself in the foot. It does make it very nice to write some things, in particular state machines. It can even be less error prone in these situations since compilers will (sometimes) warn if you don't match all possible values of an enum, which is nice if you add a state to your machine and forget to update it everywhere.

Fortunately these days there are compiler warnings to alleviate some of the risks. GCC with -Wextra will warn if you have an unmarked fallthrough in a switch for instance (but not with -Wall).

But beyond that I do agree that if I could go back in time and tell Dennis Ritchie to change some things about the language "make switch break by default and add a fallthrough keyword when you actually want the behaviour" would be very high on the list. I get why he made it that way in the first place (if you implement switch/case in assembly with a jump table you get basically the same behaviour by default and you need additional code to break) but it makes for poor ergonomics in C.

C is one of those languages (like JavaScript, arguably) that's stuffed full of so many foot-guns you can't possibly hope to make them all statically impossible. So strong conventions need to exist no matter what, and "don't put case statements below the first block" seems like an easy enough one to visually enforce.

Baloney. There is absolutely no need to reflexively avoid switch statements. Just don't do this kind of garbage with them.

Yes they can have side effects. It's Haskell and other "pure functional" languages that reduce or eliminate side effects.

Regarding terminology, this is something I find frustrating in some languages. C functions aren't all functions. Java's methods aren't really all methods on objects (is it really accurate to call a static method, which is called using the class name and not an object instance, a method?). Some languages do make these distinctions, though. Playing around with SPARK/Ada at home lately, it makes a strong distinction between procedures (no return) and functions (have a return value). Procedures look like:

  procedure Put_Line (A : Integer) is
  begin
    Put(A); New_Line;
  end Put_Line;

Functions look like:

  function Square (A : Integer) return Integer is
  begin
    return A * A;
  end Square;

Similarly, in Common Lisp there's a clear distinction between functions and methods (really multimethods) by way of how they're declared. Functions are singular, have no multiple dispatch based on type, where as you can have many implementations of the same method dispatched on type. Though, again, a function may not really be a function and could be more accurately called a procedure.

However, it probably makes sense for most people to think of everything as functions or everything as methods. At least it doesn't leave them asking "Which syntax do I use to declare this?"

> Are void functions not considered functions in functional programming?

There's usually a "Void" type that's inhabited by a single value to handle that case. In a void function, all inputs are mapped to that value.

void is the unit type, which has a single inhabitant, so those functions have a codomain; you can think of the unit type as the set containing the empty set. Sure, you don't explicitly write a return statement in C for `void` functions, but as long as the function still terminates, it can still be thought of as producing a value. Admittedly, not a very useful one, since all having a value of type void tells you is that whatever function produced it completed, but that mostly reflects the fact that `void` functions generally do other non-functional stuff; there's nothing inherently wrong with returning or having such a value, and it can be quite useful for generic code. For example, a map from keys to unit can be used to implement a set "for free."

Even in non-generic, purely functional code, the unit type is still useful--as the domain for a constant function! In most C-like languages, this is of course just represented by a function that takes no arguments, but type theoretically it's equivalent to taking a single void argument (or any number of void arguments, of course, since the Cartesian product of two sets with one inhabitant produces another set with one inhabitant). In strict functional languages that insist that everything has a type, you will often use this encoding explicitly, to implement thunks (call-by-name evaluation).

In partial languages (aka every language you're likely to practically use) or total languages which have the principle of explosion (which covers most of the remaining languages in existence), there is also the bottom type (the empty set) which has no inhabitants; this represents falsity or impossibility, which is computationally meaningful as a (perhaps not terribly informative) type for programs that can't return a value; for instance, nonterminating ones, or ones that always throw an exception. However, since in general you shouldn't be able to produce a closed value of that type, it can usually be freely cast to any other type you want, so many languages lack explicit syntax for it.

That said, it can still be convenient at times to have a way of explicitly talking about the empty type; for example, in Rust (behind a feature flag currently), if you use a sum type where all but one of the variants includes the bottom type `!`, the compiler will recognize that only one variant is possible, and allow you to directly extract data from the inhabited variant (and can optimize out the tag, or at least that's the intent). This is useful when writing generic code that has to implement an API that returns (for instance) a `Result<T, E>`, but your implementation doesn't have an error condition; in such cases, you can set `E = !`.

In total, dependently typed languages with the principle of explosion (which are certainly functional!), the type is also useful for another reason; a function from A to False is the equivalent (constructively anyway) of the negation of A, `~A`. Therefore, False ends up getting used quite a lot in type-level expressions, for the same reason as tests against the empty set occur a lot in set theory; even though strictly speaking you shouldn't be able to produce a closed value of type False (or else you should file a bug), when you're doing proofs by contradiction you can end up with one due to some false assumption in your context (which you can immediately use to prove that anything you wish derives from that context; this can be particularly useful to discharge impossible arms of pattern match expressions). This also happens implicitly in languages that perform flow-sensitive analysis of pattern match expressions; if they detect that one arm never returns (e.g. because it throws an exception or runs a loop that clearly doesn't terminate) they can implicitly assign it the bottom type, which can then be automatically cast to the type of the full expression.

In short: not only are function types with void (and even empty!) domain and codomain functional, they are actually remarkably useful :) In fact, they are so fundamental, that almost all of (standard) dependent type theory can be constructed from just three base types: the empty type, the unit type, and bool! It's a bit unfortunate that two of these three fundamental types don't have direct syntax in a lot of languages, but as you can see this is mostly because they are so ubiquitous that they are largely hidden within other language features.

I think the point is more the general technique, not this particular usage of it.

Regarding the ternary, nested ternary expressions aren't the most readable thing.

Regarding table lookup, sure but only if all values of y are sequential integers.

In the case of the lambda version, the compiler will fail if you forget a break statement or don't handle a possible case. Plus this way you can make x const, which can also prevent breaking other code further down.

It seems to me the extra safety it provides actually makes it harder for a novice to break your code?

Unless you mean strictly in the sense of "harder to break compilation", but I'm not sure that's a good thing (insert obligatory mention of Rust here)

if your novice dev cant understand the second example, he should be fired on the spot

An autoformatter will ruin the way you laid it out and make it look awful.

I'm sorry:

x = ["foo", "bar"][y]

C++ lambda. You can basically do this:

  auto succ = [](int i) { return i + 1; };

To make variables in the surrounding scope visible (i.e., create a closure) you have to specify that they're available and how. Grabbing a reference to all variables in scope you could do:

  int x = 0;
  auto inc_x = [&] () { return x++; };

This makes x available via reference so it can be modified. If you just want the value:

  int x = 0;
  auto always_one = [=] () { return x + 1; };

And you can constrain which variables are visible within the lambda:

  int x,y;
  auto foo = [&x] (auto n) { x += n; };

The return type can be determined by the compiler, or they can be made explicit (I chose not to). The first examples all returned integers, the last one has void return type.

That's a C++ lambda.

I try to be explicit and place a comment saying fall through if it is the intended behavior. This helps to inform the next person reading the code.

To be fair, that's gcc, not C.