> On 10 Aug 2016, at 22:44, Erica Sadun wrote: > >> On Aug 9, 2016, at 1:09 PM, Dave Abrahams wrote: >> >> Hi Everybody, >> >> With another round of apologies for taking late action, we propose to >> make some deprecations, moves, and renames. The background for these >> moves is as follows: >> >> We've always known that when Swift reached ABI stability (now slated for >> Swift 4), we would be committed to supporting many of the standard >> library's design decisions for years to come. What we only realized >> very recently is that, although Swift 3.0 is *not* shipping with a >> stable ABI, the promise that Swift 3.0 code will work with Swift 4.0 >> code creates similar implications when it comes to certain protocols, >> today. Especially where these protocols show up in refinement >> hierarchies, we can't keep Swift 3 code working in the future without >> carrying them forward into future libraries. >> >> The proposed changes are as follows: >> >> * Move `CustomPlaygroundQuickLookable` to the PlaygroundSupport module. >> This component is really only useful for playgrounds, and doesn't >> belong in the standard library. > > This seems like an obvious win. I *strongly* support this. (Didn't we discuss > this > several weeks ago?)
Yes, we did: <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160718/025242.html> But that part of the proposal has been withdrawn: <https://github.com/apple/swift-evolution/commit/e2610e3fa91b437e06e768aaef6820d755489717> > Since you've opened the doors to last minute discussions, I also feel quite > strongly > that image/color/file literals are misplaced and do not belong as part of the > standard library. The image one is the best example of the misfit. Images > will probably > never be a core component of stdlib but they don't fit in PlaygroundSupport > either as they > are essentially EditorSupport-ive. They have value across multiple platforms > (currently > OS X and the UIKit family, but primarily act in an Xcode-support role) but > could be extended > to other editors and other platforms. (And yes, I have list of other items > but they fall well > outside the scope of the current Swift Ev discussion so I'm sitting on them.) > >> * Deprecate the Indexable protocols with a message indicating that they >> will be gone in Swift 4. These protocols are implementation details >> of the standard library designed to work around language limitations >> that we expect to be gone in Swift 4. There's no reason for anyone to >> ever touch these; users should always use a corresponding Collection >> protocol (e.g. instead of MutableIndexable, use MutableCollection). > > It's time to for indices to evolve. > >> * Deprecate the ExpressibleByStringInterpolation protocol with a >> message indicating that its design is expected to change. We know >> this protocol to be mis-designed >> (https://bugs.swift.org/browse/SR-1260) and limited >> (https://bugs.swift.org/browse/SR-2303), but there's no time to fix it >> for Swift 3. If we knew what the new design should look like, we >> might be able to calculate that the current API is supportable in a >> forward-compatible way (as we do for Comparable). Unfortunately, we >> do not. > > I'm glad you're thinking forward about this. > >> * Rename Streamable to TextOutputStreamable and add a deprecated >> Streamable typealias for it. Now that OutputStream been renamed to >> TextOutputStream, we should also move Streamable out of the way. > > Fine. Now if only I could figure out how to get this working. Been > banging my head against the new streaming stuff. Also it shouldn't be > this hard to print(....toStream: CustomCustomCustomBlah.stderr) See the LocalFileOutputByteStream class and the `<<<` operator in: <https://github.com/apple/swift-package-manager/blob/master/Sources/Basic/OutputByteStream.swift> >> Deprecation is being proposed instead of underscoring or renaming >> because it allows existing code to keep working (with warnings). At >> this late stage, it would be bad to actually break anything. > > Sensible. > > -- E _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution