All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to me as the review manager by email or DM. When contacting the review manager directly, please put "SF-0009" in the subject line.
Trying it out
If you'd like to try this proposal out, you can check out the pull request .
What goes into a review?
The goal of the review process is to improve the proposal under review
through constructive criticism and, eventually, determine the direction of
Foundation. When writing your review, here are some questions you might want to
answer in your review:
What is your evaluation of the proposal?
If you have used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?
More information about Foundation review process is available at
I think I agree with the "enforcing valid states" reasoning in "Alternatives Considered", but it seems like it would be useful to have some shared concept of what it means for a recurrence rule to be "valid". This could be as simple as an "isValid" property (with sufficient reasoning about what it means to be valid, such as do unused fields invalidate the configuration), but it may be more ergonomic to split this up into two types, a "recurrence rule definition" and a valid recurrence. The "definition" could handle the "being able to round-trip an invalid definition properly" requirement, but we could also have a type which guarantees that the parameters are sanely-specified.
I can see practical reasons to be strict about validity (i.e. when accepting user input interactively) and when to be lax (when reading from a database). Even in the latter case it may still be nice to be able to report "this event's recurrence has an unexpected definition".
An issue with validation is that there's a wide spectrum of how much we can validate, and an isValid property would require us to have a precise definition of what a "valid" rule is. For example, which one of these should we consider valid?
let rr1 = Calendar.RecurrenceRule(calendar: .current, frequency: .daily, weeks: [1])
let rr2 = Calendar.RecurrenceRule(calendar: .current, frequency: .yearly, months: [13]) // Repeat on the 13th month
let rr3 = Calendar.RecurrenceRule(calendar: .current, frequency: .yearly, months: [1, 2], days: [30]) // Repeat on the 30th of January and February
rr1 is a trivial case: per RFC-5545's definition of RRULE, weeks is unused when the frequency is .daily. It should not have been specified. But given that the algorithm is still well-defined in that case, is the rule invalid? Should we throw an error?
rr2 can produce results with a calendar that has more than 12 months. If the calendar is Gregorian, then it simply returns no results, because there won't be a 13th month in any year.
rr3 in the Gregorian calendar will produce occurrences on the 30th of January. Should we consider it invalid because February has been specified too, but no February has 30 days?
I am okay with adding such a property, but it would require a well-thought-out definition of validity. If the intention is to use it user input validation, that further complicates matters since a binary yes / no answer is not sufficient to inform the user on why their rule was considered invalid.
I would want this functionality exactly for the reasons you mentioned: this is something that is nuanced and should not be reinvented in multiple places. You are also correct that a Boolean property is probably not sufficient.
I would love for a detailed error, both when you construct something that may be nonsensical and when you attempt to use something sensical in a nonsensical way (like with an incompatible calendar), but I agree we’d need to think deeply about what is an error.
Given the complexity of validation, I would like to defer that to a later addition to this API once there's sufficient need demonstrated. If you have concrete suggestions of how we should approach validation, you can share here.
A middle ground could be to add logging in the implementation when some "invalid" rules are constructed, and that could aid developers in debugging recurrence rules. For example:
Calendar.RecurrenceRule: The weeks property was set for a recurrence rule with a daily frequency. weeks will be ignored.