> On Aug 9, 2016, at 1:09 PM, Dave Abrahams via swift-evolution > <swift-evolution@swift.org> 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?) 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) > 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