Within the documentation for
Unicode, there are four global type aliases under a section titled "Deprecated":
UnicodeScalar. But they aren't actually marked as deprecated using
@available, and their usage seems fairly common.
UnicodeScalar is mentioned in The Swift Programming Language as the type of Unicode scalar values. The global
UTF32 type aliases were used in the recent pitch to add input-validating initializers to
Are these type aliases actually deprecated? If they are, we should actually mark them as deprecated. The availability declarations already exist in the source code for the standard library, but they're commented out for some reason? If they aren't, then we should rename the section of documentation to something else.
There is a third option we could explore: perhaps we could un-deprecate the
UTF32 type aliases and only mark
UnicodeScalar as deprecated.
Unicode.UTF__ is a bit wordy and being able to exclude the
Unicode. part would be nice. We could also add an
ASCII type alias for
Looks like a comment in the PR that commented out the deprecation availability suggested that they'd be deprecated in a future PR, but it's been a few years, so perhaps that's no longer the plan / possible.
I've disabled deprecating the top-level
Unicode.* typealiases, for a later patch
Depending on the status of the above; potentially, yeah. Although since they're type aliases, I wouldn't expect them to be necessarily elevated above their current placement (the types they alias are on the same page already).
These deprecations are part of SE-0163. Reality and proposal should be aligned, but it's not obvious which way it should go. I would lean towards making the deprecations real.
Note that the fact that these deprecations are picked up by the documentation even though they're commented out may also be a bug.
According to “Addressing unimplemented evolution proposals”:
I think this means that the type aliases are not deprecated, and that there is an error in the documentation. If we wanted to deprecate them, we’d have to make a new proposal.
@Ben_Cohen is this correct?
(Interestingly, that post does mention SE-0163, albeit a different part of the proposal.)