Reviews are an important part of the Swift-Foundation evolution process. 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 include proposal name in the subject line.
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
Swift-Foundation. When writing your review, here are some questions you might want to
answer in your review:
What is your evaluation of the proposal?
Does this proposal fit well with the feel and direction of Swift-Foundation?
If you have used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?
More information about Swift-Foundation review process is available here.
Why are the format style static members named iso8601Components when the related HTTP date format style proposal uses http for both the Date and DateComponents format styles?
The reason is that the name becomes ambiguous when used in the RegEx parser.
let testSuiteLog = Regex {
"Test Suite '"
Capture(OneOrMore(.any, .reluctant)) // name
"' "
TryCapture {
ChoiceOf { // status
"started"
"passed"
"failed"
}
} transform: {
String($0)
}
" at "
Capture(.iso8601(timeZone: gmt, // *** HERE
includingFractionalSeconds: true,
dateTimeSeparator: .space))
Optionally(".")
}
For consistency, then, I renamed all of them to iso8601Components.
Looking back, I think the HTTP proposal actually missed this extension on RegexComponent completely, which is why it didn't have the same ambiguity.
I propose we name the RegexComponent extensions to include the components names and leave it off of the others - both for ISO8601 and for HTTP.
@available(FoundationPreview 6.2, *)
extension DateComponents.HTTPFormatStyle : CustomConsumingRegexComponent {
public typealias RegexOutput = DateComponents
public func consuming(_ input: String, startingAt index: String.Index, in bounds: Range<String.Index>) throws -> (upperBound: String.Index, output: DateComponents)?
}
@available(FoundationPreview 6.2, *)
extension RegexComponent where Self == DateComponents.HTTPFormatStyle {
/// Creates a regex component to match an HTTP date and time, such as "2015-11-14'T'15:05:03'Z'", and capture the string as a `DateComponents` using the time zone as specified in the string.
public static var httpComponents: Date.HTTPFormatStyle
}
and
@available(FoundationPreview 6.2, *)
public extension FormatStyle where Self == DateComponents.ISO8601FormatStyle {
static var iso8601: Self
}
This change as proposed is probably the way to go, but it seems the alternative considered is narrow and deliberately unworkable.
By contrast, another plausible alternative to consider would be keeping the current behavior and add a second flag named lenient[FractionalSeconds]Parsing or something like that (default for backwards compatibility: false), such that the truth table for parsing would be as follows:
I started investigation on this feature assuming that the second flag would be the only way to go. It was not "deliberately" unworkable. It just became obvious through developing and using it that adding a truth table with several flags was not worth the complexity.