Enum subsets in C#

After a few years of working with Haskell I've become nearly obsessed with expressing constraints in the type system. Although the C# type system isn't as expressive as Haskell's, preconditions, postconditions, ranges, complexity, and other things can be expressed. If the type is expressive enough then you don't even have to do any validation or checking when working with it because the compiler already guaranteed that the data is valid. One of the problems with C# enums is that they aren't real objects so they can't subclass; they're just pretty wrappers around primitives like ints or bytes. This means that if you only allow certain values of an enum then you have to manually check at runtime:

public void DeclareDayIsSpecial(DayOfWeek day)
{
  if (day == DayOfWeek.Sunday || day == DayOfWeek.Saturday)
    throw new ArgumentException("When declaring that a day is special, the day must be a weekday.", "day");
 
  Console.WriteLine("{0} is special.", day);
}

Even though you can't define an enum as a subclass of another and allow only that subclass, you can define an enum as subset of another.

public enum Weekday
{
   Monday = DayOfWeek.Monday,
   Tuesday = DayOfWeek.Tuesday,
   Wednesday = DayOfWeek.Wednesday,
   Thursday = DayOfWeek.Thursday,
   Friday = DayOfWeek.Friday,
}

Once you have this you can constrain your methods to just the valid subset of values.

public void DeclareDayIsSpecial(Weekday weekday)
{
  Console.WriteLine("{0} is special.", weekday);
}

The compiler won't allow you to use an invalid value so you have compile time documentation and feedback and can remove the runtime checks. This can be useful if you use enums in a scenario where only some values are valid. And since enums are wrappers around primitive types, you can safely cast from the subset (Weekday) to the superset (DayOfWeek).

Programming and a theory of mind

A couple days ago I realized that programming is by far the most social thing I do. Sure, I discuss things with other developers, QA, and business analysts, but that's a small part of my time. The vast majority of my time is spent looking at what is already there and trying to understand it. Not just what it does or how it does it, but why. And this requires a Theory Of Mind.

A theory of mind is when you realize that other people have their own mind and their own ideas that are separate and different from yours. Everything I see at work isn't some naturally occurring thing - it was created by someone, it has an intended purpose, a reason for being, some business or technical need that it meets. Much of my time is spent interacting with others but only when programming do I need to look into so many other minds at the same time, to find and understand the intent of the original developer, the business scenario being addressed, the reasons why it was done this way and not that way, and why it's still being done this way. Writing code generally isn't difficult, especially business apps, it's understanding the intent and reasons for the code that's tough. Like it says in Structure and Interpretation of Computer Programs, "Programs should be written for people to read, and only incidentally for machines to execute."