[swift-evolution] [Late Pitch] Deprecations, Moves, and Renames

[Björn Forster]

I think he is pointing out that in
https://github.com/apple/swift/blob/master/stdlib/public/core/Integers.swift.gyb
there is the FixedWidthInteger protocol, which is part of SE-104.
Also, there is
static func doubleWidthMultiply (line 392)
and
static func doubleWidthDivide (line 394)
but then only
public static func doubleWidthDivide (line 589)
and there is no
public static func doubleWidthMultiply
anywhere in the file.
If the static func doubleWidthMultiply in line 392 exists, shouldn't there
be a public static func for it, too?
Why is there this asymmetry regarding multiplication and division?

Sincerely,
Björn

On Fri, Sep 9, 2016 at 1:35 AM, Chris Lattner via swift-evolution <
swift-evolution at swift.org> wrote:

> On Sep 7, 2016, at 12:58 PM, Tim Vermeulen via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> They’re still in Swift 3. Did something go wrong, or will they simply not
> show up in the final Swift 3.0?
>
>
> Please elaborate on what you mean: what is in that shouldn’t be?
>
> -Chris
>
>
> On 10 Aug 2016, at 22:28, Dave Abrahams <dabrahams at apple.com> wrote:
>
>
> on Wed Aug 10 2016, Tim Vermeulen <tvermeulen-AT-me.com
> <http://tvermeulen-at-me.com/>> wrote:
>
> Some protocols of SE-0104 seem to be part of the latest Swift 3
> snapshots (Arithmetic, FixedWidthInteger, etc) - was this a mistake
> then, if they won’t be in Swift 3.0?
>
>
> Yes, they've been pulled out of the release branch:
> https://github.com/apple/swift/pull/4112#issuecomment-238451509
>
>
>
> on Wed Aug 10 2016, Ben Rimmington<me-AT-benrimmington.com
> <http://me-at-benrimmington.com/>>wrote:
>
> On 10 Aug 2016, at 00:36, Dave Abrahams wrote:
>
> on Tue Aug 09 2016, Ben Rimmington wrote:
>
> On 9 Aug 2016, at 20:09, 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.
>
>
> I didn't think it was possible to `import PlaygroundSupport` unless the
> current file is within a playground. If so, how can corelibs-foundation
> or third-party modules add `CustomPlaygroundQuickLookable`
> conformance?
>
>
> Ahhh... yeah, I didn't realize that, and we don't have time to change
> that restriction for Swift 3. It's not a problem for
> corelibs-foundation but it would be for 3rd-party libraries.
>
> OK, Dmitri and I just figured out how we can change the home of these
> types for Swift 4 without breaking Swift 3 code (mirrors to the rescue!)
> So I'm going to withdraw this part of the proposal.
>
>
> Will the following need to be reverted?
>
> <https://github.com/apple/swift/pull/4089>
>
> <https://github.com/apple/swift-xcode-playground-support/commit/aab7af4>
> <https://github.com/apple/swift-xcode-playground-support/commit/865fd0c>
> <https://github.com/apple/swift-xcode-playground-support/commit/ab605ef>
> <https://github.com/apple/swift-xcode-playground-support/commit/4bd6575>
> <https://github.com/apple/swift-xcode-playground-support/commit/acee2e1>
>
> Technically, no, because typealiases make it unnecessary, but yes, we
> plan to do that.
>
> * 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).
>
> * 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.
>
> * 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.
>
>
> In apple/swift#4131, these lines have overrun the 80 column limit:
>
> <https://github.com/apple/swift/blob/f2443f4/stdlib/
> public/core/Mirror.swift#L843>
> <https://github.com/apple/swift/blob/f2443f4/stdlib/
> public/core/Mirror.swift#L893>
>
> <https://github.com/apple/swift/blob/f2443f4/stdlib/
> public/core/Print.swift#L177>
> <https://github.com/apple/swift/blob/f2443f4/stdlib/
> public/core/Print.swift#L228>
>
> TextFormatting.rst also needs `Streamable` =>`TextOutputStreamable`:
>
> <https://github.com/apple/swift/blob/master/docs/TextFormatting.rst>
>
> Pull requests gratefully accepted for all of these corrections
>
> 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.
>
>
> If the SE-0104 (protocol-oriented integers) proposal has been deferred,
> should any protocols (e.g. SignedNumber) be deprecated?
>
>
> Will the SE-0104 proposal be accepted for Swift 4.0?
>
> It is expected to be. We may even be able to get it into a Swift 3
> point-release (e.g. 3.1)
>
> --
> Dave
>
>
>
>
> --
> -Dave
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160909/5e691ff0/attachment.html>