Closed NorfairKing closed 9 months ago
This PR would make it easier to work with months-of-year as names, while more difficult to work with them as numbers. I believe the latter is the more common case, so a net negative.
The "footgun" in the current design (using a month-of-year outside the range 1..12) is already obvious to anyone using the library, and is mirrored by "footguns" for day-of-month, hour-of-day, etc., which this PR does not (and of course should not) address.
Finally, this PR would break a lot of existing code.
@AshleyYakeley you make an excellent point wrt breakage.
I'd be happy to close this and make a new PR with only the following
MonthOfYear
synonym back into Int
parseMonthOfYearIndex
and monthOfYearIndex
functions.MonthOfYear
sum typeThat way backward incompatibility is minimised because fromGregorian
/toGregorian
remain unchanged, and users don't need to define their own MonthOfYear
type that then clashes in the namespace with the type synonym.
Would such a PR be more acceptable?
This PR exists to show that I'm happy to do the work necessary to resolve #134
Current status: The code compiles, but with warnings and failing tests.
At this point I want to acknowledge that resolving #134 is a nontrivial amount of work. The internals of the time library become slightly more complex in order to prevent footguns and runtime errors for users. There are also minor performance improvements in some places and regressions in others.
I understand that, as the maintainer @AshleyYakeley, you are in your right to close this PR without comment or even ignore it entirely. However, I would strongly urge you to consider how many footguns and runtime issues this change can prevent, in the interest of the library's users.
I also understand that this PR will likely cause some ruffled feathers, so I want to make it extra clear that I mean no offense toward anyone who disagrees with my technical viewpoint on this matter. I only want to make an effort towards a less dangerous technical solution.