And I remain unconvinced that any of those "natural fits" add value.
> Do you?
Yes.
> Someone could have added a #define int float after all.
That would be straight up undefined behavior. Can't redefine keywords. Even a badly defined "i32" is clearly buggy enough that even the most foolish coworkers won't do it, and cleaning up after the outright malicious is at least more straightforward.
You're trying to say that the likelyhood of stupid tech debt from weird backwards compatability nonsense, and straight up intentional chaos, but I don't buy that you even believe it yourself. I have seen plenty of the former in real codebases, and a tiny fraction of the latter. Even the broken-ass codebases that I've worked on that have invoked undefined behavior by redefining keywords haven't gone as dumb as #define int float.
I've seen #define true 1 though.
> Except if you are assingning one month property from another month property you have to check the documentation for both that they math (and not just almost match). Whereas with a strong type the compiler checks that for you.
Even if you have two type-matched "Month" properties, if they belong to dates in different timezones, there's a good chance you've just written a bug by forgetting to account for the difference - and that's a far more likely bug to slip through the cracks than mixing up month index and month ordinal. And when you don't have type-matched "Month" properties, the author will likely write the same code they would've with integers, just with a bunch more casts, if only because they don't want to eat the recompiles of touching a date/time header that gets included goodness knows how far and wide.
Putting it another way: I'd argue that the manipulation of individual months is already inherently not type safe, as it lacks enough context to be type safe.
The most natural fit for the Month type here is an enum, enum class or something that wraps one with additional functionality. And while sure you could have enum Month { }; and then use Month(0) for january or whatever, that's just deliberate obfuscation and not what anyone reasonable would do for normal code. And it's still not worse than an int.
> No, I've eliminated several possibilities with a plain int that you've conveniently left unquoted.
Do you? Someone could have added a #define int float after all. Your arguments that just because someone could obfuscate the type in some way that that inherently makes using a Month type bad is just that: absurd.
> Oh gee, is that an `int` month property that states it's range? Yes. Yes it is. And I don't have to drill further into the documentation to look at the type of the property, and can just look at the property? Bonus points!
Except if you are assingning one month property from another month property you have to check the documentation for both that they math (and not just almost match). Whereas with a strong type the compiler checks that for you.