UnicodeScalar.utf16 does not have access modifier and therefore is internal
but should be public, as well as UnicodeScalar.UTF16View.
The ticket is written in a way that makes it seem as though this change would
match the behavior of APIs such as the UTF accessors on `String`.
Additionally, `UnicodeScalar.utf16` and `Unicodescalar.UTF16View` seem to be
created in `UnicodeScalar.swift`, but not used elsewhere, indicating that
these properties were intended to be exposed to developers as part of the
stdlib.
After submitting a pull request to implement this
(https://github.com/apple/swift/pull/4929, Maxim Moiseev and Michael Gottesman
mentioned that since this does modify the public API, a proposal should go
through swift-evolution to address this.
I wanted to kick off the discussion here and get feedback from the mailing
list.
> UnicodeScalar.utf16 does not have access modifier and therefore is internal but should be public, as well as UnicodeScalar.UTF16View.
The ticket is written in a way that makes it seem as though this change would match the behavior of APIs such as the UTF accessors on `String`.
Additionally, `UnicodeScalar.utf16` and `Unicodescalar.UTF16View` seem to be created in `UnicodeScalar.swift`, but not used elsewhere, indicating that these properties were intended to be exposed to developers as part of the stdlib.
After submitting a pull request to implement this (https://github.com/apple/swift/pull/4929, Maxim Moiseev and Michael Gottesman mentioned that since this does modify the public API, a proposal should go through swift-evolution to address this.
I wanted to kick off the discussion here and get feedback from the mailing list.
> UnicodeScalar.utf16 does not have access modifier and therefore is internal but should be public, as well as UnicodeScalar.UTF16View.
The ticket is written in a way that makes it seem as though this change would match the behavior of APIs such as the UTF accessors on `String`.
Additionally, `UnicodeScalar.utf16` and `Unicodescalar.UTF16View` seem to be created in `UnicodeScalar.swift`, but not used elsewhere, indicating that these properties were intended to be exposed to developers as part of the stdlib.
I wanted to kick off the discussion here and get feedback from the mailing list.
Looking forward to chatting about this!
Eli Perkins
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org> https://lists.swift.org/mailman/listinfo/swift-evolution
> UnicodeScalar.utf16 does not have access modifier and therefore
is internal but should be public, as well as
UnicodeScalar.UTF16View.
The ticket is written in a way that makes it seem as though this
change would match the behavior of APIs such as the UTF accessors
on `String`.
Additionally, `UnicodeScalar.utf16` and `Unicodescalar.UTF16View`
seem to be created in `UnicodeScalar.swift`, but not used
elsewhere, indicating that these properties were intended to be
exposed to developers as part of the stdlib.
I wanted to kick off the discussion here and get feedback from the mailing list.
Looking forward to chatting about this!
Eli Perkins
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org> https://lists.swift.org/mailman/listinfo/swift-evolution