Mark UnicodeScalar.utf16 and UnicodeScalar.UTF16View as public


(Eli Perkins) #1

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


(Robert Widmann) #2

+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) #3

+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 (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 Abrahams) #4

+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 (https://bugs.swift.org/browse/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
<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