Logical implication

One of the early stumbling blocks people run into when learning traditional Aristotelian logic is the idea that “a false proposition implies any proposition”. Let’s briefly review material implication, and then I’ll talk about what the implications of material implication are to programming.
Continue reading

When would you use & on a bool?

UPDATE: A commenter points out that today is the 200th anniversary of the birth of George Boole; I had no idea when I scheduled this article that it would be so apropos. Happy birthday George Boole!


Here’s a little-known and seldom-used fact about C# operators: you can apply the & and | operators to bools, not just to integers. The & and | operators on bools differ from && and || in only one way: both operators always “eagerly” evaluate both operands. This is in marked contrast to the “lazily” computed evaluation of the && and || operators, which only evaluate their right hand argument if needed. Why on earth would you ever want to evaluate the right hand side if you didn’t need to? Why have this operation at all on bools?

A few reasons come to mind. First, sometimes you want to do two operations, and know whether both of them succeeded: Continue reading

Inferring from “is”, part two

In part one I gave a bunch of reasons to reject the proposed feature where the compiler infers additional type information about a local variable when inside the consequence of a conditional statement:

if (animal is Dog)
{
    animal.Bark(); 
    // instead of ((Dog)animal).Bark();
}

But the problem still remains that this is a fairly common pattern, and that it seems weird that the compiler cannot make the necessary inference.

A number of readers anticipated my denouement and made some of the same proposals I was going to make in this part. Let’s go through a few of them; see the comments to the previous article for a few more.

Continue reading

Inferring from “is”, part one

In last week’s episode of FAIC I was discussing code of the form:

if (animal is Dog)
    ((Dog)animal).Bark();

Specifically, why the cast was illegal if the variable tested was of generic parameter type. Today I want to take a bit of a different tack and examine the question “why do we need to insert a cast at all?” After all, the compiler should know that within the consequence of the if, the variable animal is guaranteed to be of type Dog. (And is guaranteed to be non-null!) Shouldn’t the code simply be:

if (animal is Dog)
    animal.Bark();

Continue reading

Casts and type parameters do not mix

Here’s a question I’m asked occasionally:

void M<T>(T t) where T : Animal
{
  // This gives a compile-time error:
  if (t is Dog)
    ((Dog)t).Bark(); 
  // But this does not:
  if (t is Dog)
    (t as Dog).Bark();
}

What’s going on here? Why is the cast operator rejected? The reason illustrates yet again that the cast operator is super weird.
Continue reading

Nullable comparisons are weird

One of the C# oddities I noted in my recent article was that I find it odd that creating a numeric type with less-than, greater-than, and similar operators requires implementing a lot of redundant methods, methods whose values could be deduced by simply implementing a comparator. For an example of such, see my previous series of articles on implementing math from scratch.

A number of people commented that my scheme does not work in a world with nullable arithmetic (or, similarly, NaN semantics, which are similar enough that I’m not going to call out the subtle differences here.) That reminded me that I’d been intending for some time to point out that when it comes to comparison operators, nullable arithmetic is deeply weird. Check out this little program: Continue reading