+1. All seems reasonable to me.<br><div class="gmail_quote"><div dir="ltr">On Tue, Aug 9, 2016 at 14:16 Dave Abrahams via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Hi Everybody,<br>
<br>
With another round of apologies for taking late action, we propose to<br>
make some deprecations, moves, and renames. The background for these<br>
moves is as follows:<br>
<br>
We've always known that when Swift reached ABI stability (now slated for<br>
Swift 4), we would be committed to supporting many of the standard<br>
library's design decisions for years to come. What we only realized<br>
very recently is that, although Swift 3.0 is *not* shipping with a<br>
stable ABI, the promise that Swift 3.0 code will work with Swift 4.0<br>
code creates similar implications when it comes to certain protocols,<br>
today. Especially where these protocols show up in refinement<br>
hierarchies, we can't keep Swift 3 code working in the future without<br>
carrying them forward into future libraries.<br>
<br>
The proposed changes are as follows:<br>
<br>
* Move `CustomPlaygroundQuickLookable` to the PlaygroundSupport module.<br>
This component is really only useful for playgrounds, and doesn't<br>
belong in the standard library.<br>
<br>
* Deprecate the Indexable protocols with a message indicating that they<br>
will be gone in Swift 4. These protocols are implementation details<br>
of the standard library designed to work around language limitations<br>
that we expect to be gone in Swift 4. There's no reason for anyone to<br>
ever touch these; users should always use a corresponding Collection<br>
protocol (e.g. instead of MutableIndexable, use MutableCollection).<br>
<br>
* Deprecate the ExpressibleByStringInterpolation protocol with a<br>
message indicating that its design is expected to change. We know<br>
this protocol to be mis-designed<br>
(<a href="https://bugs.swift.org/browse/SR-1260" rel="noreferrer" target="_blank">https://bugs.swift.org/browse/SR-1260</a>) and limited<br>
(<a href="https://bugs.swift.org/browse/SR-2303" rel="noreferrer" target="_blank">https://bugs.swift.org/browse/SR-2303</a>), but there's no time to fix it<br>
for Swift 3. If we knew what the new design should look like, we<br>
might be able to calculate that the current API is supportable in a<br>
forward-compatible way (as we do for Comparable). Unfortunately, we<br>
do not.<br>
<br>
* Rename Streamable to TextOutputStreamable and add a deprecated<br>
Streamable typealias for it. Now that OutputStream been renamed to<br>
TextOutputStream, we should also move Streamable out of the way.<br>
<br>
Deprecation is being proposed instead of underscoring or renaming<br>
because it allows existing code to keep working (with warnings). At<br>
this late stage, it would be bad to actually break anything.<br>
<br>
--<br>
-Dave<br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div>