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 DM. When contacting the review manager directly, please include proposal name in the subject line.
Trying it out
If you'd like to try this proposal out, you can check out the implementation branch.
What goes into a review?
The goal of the review process is to improve the proposal under review
through constructive feedback. When writing your review, here are some questions you might want to answer in your review:
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
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 Swift-Foundation review process is available at
Overall I’m excited to see this fill a gap between the CF APIs and nicer Swift APIs! One clarifying question:
This feature can be freely adopted and un-adopted in source code with no deployment constraints […]
For platforms where availability/deployment versions are relevant (Darwin platforms), is this suggesting that these new declarations will not be introduced with availability / will be back deployed in some way? Since there aren’t availability declarations or attributes like @backDeployed or @_alwaysEmitIntoClient on the proposed API in the document, I wanted to confirm the intention here around whether the proposal is suggesting that the implementations should be back deployed to older OS versions or if these will come with availability.
I think this proposal has converged well—congrats to the author for working so diligently through all the feedback!
I agree that adopting IANA names with an explicit ianaName label and using case-insensitive but otherwise strict matching as proposed here is probably the best way to go, in terms of the results being as unambiguous as possible.
As web standards continue to dominate, I still believe that WHATWG standards that reflect actual practice rather than sometimes quite divergent historical fiat will be relevant APIs to add. But I agree that it can be separated from this proposal and, where necessary, may require additional project buy-in to maintain the necessary strict compliance with the standard’s expectations.
Thank you for pointing this out. That's a kind of documentation error. Current draft implementation has @available attributes. However, I guess this feature could be @backDeployed theoretically since it depends on nothing OS-specific.
Thank you for the response. Ideally, we should adopt such standards in some form someday. But, as WHATWG standards are literally living, it may be better to implement them in an independent module other than Foundation. Anyway, as you say, that's out of scope here though.
init(ianaName:) adopts case-insensitive comparison with Preferred MIME Name, Name, and Aliases.
Case-insensitive in which locale? In other words, does the return value of String.Encoding(ianaName: "SHİFT_JIS") depend on the current locale’s language?
Sounds good! I think adding it with availability is fine - that’s the typical approach unless we have a strong need to backdeploy it (since that usually incurs a higher maintenance burden / less flexibility). If that’s the case, (as a small nitpick) it might be a good idea to remove the clause in the proposal about “with no deployment constraints” since there will be a constraint on the deployment (requiring either a higher deployment target or using if #available checks) just so it matches the expected implementation. Thanks for clarifying!
Hmm. This does mean that String.Encoding(ianaName: "shift_jis".uppercased()) will return nil if the locale is Turkish or Azeri, as will String.Encoding(ianaName: "ＧＢ２３１２") (note the fullwidth characters). Nobody is likely to write these literals in Swift code, of course, but these situations could arise from processing user input.
Seems like a good tradeoff, but worth documenting explicitly.