[pradocchia]

It still provides some of the same ergonomics. You can put away the mental cheat-sheet ("1: gold, 2: silver...."). Your IDE can find all uses of BookTypeId.Gold(), rather than textual occurrences of "1". Etc.

The static quality of enums is only one of their features, and sometimes a hindrance, and it good to have other options.

[andrea_s]

sure, but I can't see how this is supposed to increase discoverability of the API...

I see "here is something that looks like an enum, and its possible values are gold, silver and bronze. But you can also give 10, 42 or any number as a value and it will still work".

I don't mean to be overly critical (clearly this approach has worked well for the author), but I am a bit unsure about the perceived benefits.

[pradocchia]

Yeah, I'm not sure how much it increase discoverability, plus users pay the cognitive cost of quirky patterns.

I might have used an enum plus a second constructor to wrap the explicit conversation. I guess it depends on what's going on in the rest of the API.