<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">+1, assuming Dave Abrahams agrees.<div class=""><br class=""></div><div class="">-Chris</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Sep 23, 2016, at 6:02 AM, Robert Widmann via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class=""><div style="direction: inherit;" class="">+1. &nbsp;This is a bug fix in my mind, evolution is merely a formality.</div><div style="direction: inherit;" class=""><br class=""></div><div style="direction: inherit;" class="">Ship it</div><br class="">~Robert Widmann</div><div class=""><br class="">2016/09/22 18:59、Eli Perkins via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; のメッセージ:<br class=""><br class=""></div><blockquote type="cite" class=""><div class="">Hey all!<div class=""><br class=""></div><div class="">I picked up SR-2627 (<a href="https://bugs.swift.org/browse/SR-2627" class="">https://bugs.swift.org/browse/SR-2627</a>) from the Swift JIRA&nbsp;project. The ticket states:</div><div class=""><br class=""></div><div class="">&gt;&nbsp;<span style="line-height: 1.4;" class="">UnicodeScalar.utf16 does not have access modifier and therefore is internal but should be public, as well as UnicodeScalar.UTF16View.</span></div><div class=""><br class=""></div><div class=""><span style="line-height: 1.4;" class="">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`.</span><br class=""></div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">After submitting a pull request to implement this (<a href="https://github.com/apple/swift/pull/4929" class="">https://github.com/apple/swift/pull/4929</a>,&nbsp;Maxim Moiseev&nbsp;and&nbsp;Michael Gottesman&nbsp;mentioned that since this does modify the public API, a proposal should go through swift-evolution to address&nbsp;this.</div><div class=""><br class=""></div><div class="">I wanted to kick off the discussion here and get feedback from the mailing list.</div><div class=""><br class=""></div><div class="">Looking forward to chatting about this!</div><div class="">Eli Perkins</div></div></blockquote><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></body></html>