To Enum or not to Enum...

I'm using a library that accepts an integer as a parameter.  The value for the integer is really arbitrary -- it's a utility library and the consumers of the library decide what they want this integer value to represent.

For my application, I needed this integer to represent the reason some values were being filtered out of a set of data.  I originally defined an Enum for my values:

enum RowStatus
{
    BadMap,
    BadBaro,
    BadCA50
}

But while using this enum made my code more readable, I had to cast my enum members to an integer every time I used them (since, after all, that was the signature of the method).  So I tossed out the enum and reverted back to good old 'constant' values (even used the old ALLCAPS style):

private const int BAD_MAP = 0;
private const int BAD_BARO = 1;
private const int BAD_CA50 = 2;

But that bothered me.  I really wanted to use an enum since I personally thought it made the code look cleaner and was easier to read.  But how would all that casting affect things?

I whipped up a small C# console app that reproduced my situation: taking a method that accepts an integer and passing both an integer and an enum to it (cast as an integer).  Compiled it and whipped out ILDASM.  Result?  Exact same code (no casting was generated).  Doesn't really surprise me now that I see the results -- I mean, enums are integers by default anyway.

I guess it would be nice if the C# compiler would let you use an integer-based enum in place of an integer (without needing the cast to int).  I don't see where this would be a problem.  The other way is definitely a no-no -- I would not want an integer to be used in place of an enum.  But since an integer-based enum is just a set of symbolic names for integer values, what is the harm in allowing it to be used in a method that accepts an integer?