Mark UnicodeScalar.utf16 and UnicodeScalar.UTF16View as public

Eli_Perkins · 2016-09-22T22:59:00.000Z

Hey all!

I picked up SR-2627 (https://bugs.swift.org/browse/SR-2627\) from the Swift
JIRA project. The ticket states:

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.

Looking forward to chatting about this!

Eli Perkins

codafi · 2016-09-23T16:02:05.000Z

+1. This is a bug fix in my mind, evolution is merely a formality.

Ship it

~Robert Widmann

2016/09/22 18:59、Eli Perkins via swift-evolution <swift-evolution@swift.org> のメッセージ:

···

Hey all!

I picked up SR-2627 (https://bugs.swift.org/browse/SR-2627\) from the Swift JIRA project. The ticket states:

> 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.

Looking forward to chatting about this!
Eli Perkins
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Chris_Lattner · 2016-09-25T19:59:31.000Z

+1, assuming Dave Abrahams agrees.

-Chris

···

On Sep 23, 2016, at 6:02 AM, Robert Widmann via swift-evolution <swift-evolution@swift.org> wrote:

+1. This is a bug fix in my mind, evolution is merely a formality.

Ship it

~Robert Widmann

2016/09/22 18:59、Eli Perkins via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> のメッセージ:

Hey all!

I picked up SR-2627 (https://bugs.swift.org/browse/SR-2627\) from the Swift JIRA project. The ticket states:

> 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 ([stdlib] Mark UnicodeScalar.utf16 and UnicodeScalar.UTF16View as public by eliperkins · Pull Request #4929 · apple/swift · GitHub, 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.

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

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

dabrahams · 2016-09-26T00:18:15.000Z

+1, assuming Dave Abrahams agrees.

-Chris

Now that our comments have been addressed, I'm all for merging it.

···

on Sun Sep 25 2016, Chris Lattner <clattner-AT-apple.com> wrote:

On Sep 23, 2016, at 6:02 AM, Robert Widmann via swift-evolution <swift-evolution@swift.org> wrote:

+1. This is a bug fix in my mind, evolution is merely a formality.

Ship it

~Robert Widmann

2016/09/22 18:59、Eli Perkins via swift-evolution
<swift-evolution@swift.org <mailto:swift-evolution@swift.org>> のメッ
セージ:

Hey all!

I picked up SR-2627 ([SR-2627] UnicodeScalar.utf16 does not have access modifier and is therefore internal · Issue #45232 · apple/swift · GitHub
<https://bugs.swift.org/browse/SR-2627>\) from the Swift JIRA
project. The ticket states:

> 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
([stdlib] Mark UnicodeScalar.utf16 and UnicodeScalar.UTF16View as public by eliperkins · Pull Request #4929 · apple/swift · GitHub
<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.

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

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
-Dave