5 ms·

> Regardless, "Month" tells me it's a "month" whereas "int" tells me "lol get fucked I ain't telling you shit" I disagree. Is "Month" a 1-based month ordinal?

> Regardless, "Month" tells me it's a "month" whereas "int" tells me "lol get fucked I ain't telling you shit" I disagree. Is "Month" a 1-based month ordinal? A 0-based month index? A string containing user input that should be preserved in it's original form to avoid data loss (be that "jan", "JAN", "January", "1", ...)? Memoized? An indirect reference to OCR data? Do I even have a guarantee it's on the Gregorian calendar, or am I in the context of some calendar app that might support chinese lunar calendars? Is it JSON serializable? Is it a localization placeholder? Is it an integer typedef that means different things in different contexts, including "months ago" in some relative timestamp formatting code? "Month" tells me jack shit that the function and variable names didn't. "int" at least tells me I can math it, and that if I'm dumb enough to have memcpy-serialized code, I have a potential porting hazard in the form of endian issues - and size variance if I'm dumb enough to target an ILP64 platform. Based on personal experience, these are far more likely bugs for me to encounter and need to fix than any that would be caught by stronger month typing. There is a place for stronger types - I'm not complaining about Rust's SystemTime/Instant/Duration trifecta and more - but "Month" ain't it. It's a bridge too far, too pointless - it is the wrong abstraction. And, yes, you can math on months. For indexing into arrays of localized strings, for conversion to/from epoch... I've written some really nasty .natvis visualizers that rendered absolute timestamps as PST timestamps for debug convenience, and it involved a whole lot of rather redundant and duplicated math in that horror of an XML format which would be made 10 times worse by extra "help" in the form of strong types to be unwrapped. > I'd just hover over it in my IDE and it'd tell me what it is. This works until some jerk buries it in #ifdef soup and causes your IDE to lie. Perhaps uint8_t - except on windows where it might be int for "backwards compatability". Or perhaps multiple definitions in different independent contexts (be that different namespaces or different included headers.) I've seen stupider shit frequently enough that the habit of spending more time performing a more thorough check than a simple hover will be time well spent. > you can pretty easily fix all of the users of a "Month" type Nah, that kind of underbaked leaky misabstraction isn't going to be properly thought out well enough to simply fix by merely poking at the type (and I'm confident in assuming it will be an underbaked leaky misabstraction on account of the lack of value provided.) You're going to have to actually audit all use of that type for dumb abstraction-breaking assumptions that make it brittle and fragile if you so much as sneeze on it's layout. A saving grace here: so little code will actually bother to use it, that it actually shouldn't be too terrible. Probably.

Jtsummers 4y ago
You really think having a type tells you less than having an int? Is the int 0 or 1 based? You don't know. Does the int handle rollover? Nope, you have to. Of course, that's the C way. Worse is better. Fuck sensible type systems and use of them. Let the world burn. You can look up types, with a bare int you have to pray someone documented it and that they were consistent.
- MaulingMonkey 4y ago
  > You really think having a type tells you less than having an int? In the case of "Month", yes. Give me stronger types for dates or timespans or instants though. > Does the int handle rollover? Nope, you have to. Rollover tends to need handling at the date level to carry the year, so let's be honest, "Month" won't handle rollover properly on it's own either.
  - kllrnohj 4y ago
    > Give me stronger types for dates or timespans or instants though. So the guideline you're vigorously arguing against you don't actually disagree with at all, you just really, really hate Month for seemingly no reason. Maybe give the guideline a read rather than just the 2 line snippet someone else posted? > "Month" won't handle rollover properly on it's own either. It does by not offering math operators in the first place, avoiding the entire possibility of a rollover from the outset. Or it could throw on rollover so it's at least an runtime exception instead of a silent failure.
kllrnohj 4y ago
> Is "Month" a 1-based month ordinal? A 0-based month index? Unlike with an bare int, a "Month" type has places to actually document all that. So your counter argument, which is entirely the same for an int anyway, is utterly absurd. > This works until some jerk buries it in #ifdef soup and causes your IDE to lie. I don't really know what your point even is here. Your ide or code base is bad, therefore everyone should share your pain? If your ide can't resolve it then go look up the docs the old fashioned way. It's the same end result of a wrapper type being vastly superior to a bare int. I can make a comment in a header or a man page or whatever for a "Month" type to answer all your questions. I could never do the same for an "int" variable. It really sounds like you're just wanting to obsessively nitpick the specific example of "Month" than anything about what the guideline is even saying. If you're just too lazy to make a Month then sure knock yourself out. But at least be honest that you're just being lazy in the now with a hope it doesn't bite you later, don't pretend you're making an actually better or more readable decision. We all take the lazy out from time to time.

Jtsummers 4y ago

You really think having a type tells you less than having an int? Is the int 0 or 1 based? You don't know. Does the int handle rollover? Nope, you have to. Of course, that's the C way. Worse is better. Fuck sensible type systems and use of them. Let the world burn. You can look up types, with a bare int you have to pray someone documented it and that they were consistent.

MaulingMonkey 4y ago
> You really think having a type tells you less than having an int? In the case of "Month", yes. Give me stronger types for dates or timespans or instants though. > Does the int handle rollover? Nope, you have to. Rollover tends to need handling at the date level to carry the year, so let's be honest, "Month" won't handle rollover properly on it's own either.
- kllrnohj 4y ago
  > Give me stronger types for dates or timespans or instants though. So the guideline you're vigorously arguing against you don't actually disagree with at all, you just really, really hate Month for seemingly no reason. Maybe give the guideline a read rather than just the 2 line snippet someone else posted? > "Month" won't handle rollover properly on it's own either. It does by not offering math operators in the first place, avoiding the entire possibility of a rollover from the outset. Or it could throw on rollover so it's at least an runtime exception instead of a silent failure.

kllrnohj 4y ago

> Is "Month" a 1-based month ordinal? A 0-based month index? Unlike with an bare int, a "Month" type has places to actually document all that. So your counter argument, which is entirely the same for an int anyway, is utterly absurd. > This works until some jerk buries it in #ifdef soup and causes your IDE to lie. I don't really know what your point even is here. Your ide or code base is bad, therefore everyone should share your pain? If your ide can't resolve it then go look up the docs the old fashioned way. It's the same end result of a wrapper type being vastly superior to a bare int. I can make a comment in a header or a man page or whatever for a "Month" type to answer all your questions. I could never do the same for an "int" variable. It really sounds like you're just wanting to obsessively nitpick the specific example of "Month" than anything about what the guideline is even saying. If you're just too lazy to make a Month then sure knock yourself out. But at least be honest that you're just being lazy in the now with a hope it doesn't bite you later, don't pretend you're making an actually better or more readable decision. We all take the lazy out from time to time.