[Late Pitch] Deprecations, Moves, and Renames


(Dave Abrahams) #1

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.

* 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.

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.

···

--
-Dave


(Charles Srstka) #2

Is the team taking suggestions on APIs to be deprecated, renamed and/or modified? I’ve been noticing quite a few translated ObjC APIs that don’t quite seem to fit the Swift paradigm lately.

Charles

···

On Aug 9, 2016, at 2: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.

* 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.

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.


(David Sweeris) #3

+1

···

Sent from my iPhone

On Aug 9, 2016, at 14:09, 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.

* 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.

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.

--
-Dave

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Dave Abrahams) #4

Full proposal:
https://github.com/apple/swift-evolution/blob/master/proposals/0137-avoiding-lock-in.md

···

on Tue Aug 09 2016, Dave Abrahams <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:

--
-Dave


(Xiaodi Wu) #5

+1. All seems reasonable to me.

···

On Tue, Aug 9, 2016 at 14:16 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.

* 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.

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.

--
-Dave

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Ben Rimmington) #6

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?

* 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.

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?

-- Ben

···

On 9 Aug 2016, at 20:09, Dave Abrahams wrote:


(Karl) #7

Does this include the ContiguousArray deprecation? I’m still seeing performance issues with regular Array (will update bug soon).

I don’t mind if it gets deprecated, so long as it isn’t removed before we sort those issues out.

Otherwise +1

Karl

···

On 9 Aug 2016, at 21:09, 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.

* 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.

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.

--
-Dave

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Erica Sadun) #8

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

···

On Aug 9, 2016, at 1:09 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:


(Brent Royal-Gordon) #9

Should IndexableBase get the same treatment? Or is that hidden anyway?

···

On Aug 9, 2016, at 12:09 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

Deprecate the Indexable protocols with a message indicating that they
will be gone in Swift 4.

--
Brent Royal-Gordon
Architechies


(Ben Rimmington) #10

Can the deprecation of ExpressibleByStringInterpolation be reverted next year,
if a backwards-compatible design is proposed for Swift 4.0?

-- Ben

···

On 9 Aug 2016, at 20:09, Dave Abrahams wrote:

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.


(Dave Abrahams) #11

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.

* 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.

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.

--
-Dave

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Does this include the ContiguousArray deprecation?

Definitely not.

···

on Tue Aug 09 2016, Karl <swift-evolution@swift.org> wrote:

On 9 Aug 2016, at 21:09, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

I’m still seeing performance issues with regular Array (will update
bug soon).

I don’t mind if it gets deprecated, so long as it isn’t removed before we sort those issues out.

Otherwise +1

Karl

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
-Dave


(Dave Abrahams) #12

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.

···

on Tue Aug 09 2016, Ben Rimmington <swift-evolution@swift.org> wrote:

On 9 Aug 2016, at 20:09, Dave Abrahams wrote:

* 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.

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?

-- Ben

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
-Dave


(Michael Ilseman) #13

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.

* 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.

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.

Is the team taking suggestions on APIs to be deprecated, renamed and/or modified? I’ve been noticing quite a few translated ObjC APIs that don’t quite seem to fit the Swift paradigm lately.

Please file radars for these against the offending frameworks. You can additionally discuss them on swift-dev or swift-users, but definitely file those radars!

···

On Aug 9, 2016, at 1:01 PM, Charles Srstka via swift-evolution <swift-evolution@swift.org> wrote:

On Aug 9, 2016, at 2:09 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

Charles

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Paulo Faria) #14

+1

···

On Aug 9, 2016, at 6:57 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

on Tue Aug 09 2016, Karl <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On 9 Aug 2016, at 21:09, 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.

* 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.

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.

--
-Dave

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Does this include the ContiguousArray deprecation?

Definitely not.

I’m still seeing performance issues with regular Array (will update
bug soon).

I don’t mind if it gets deprecated, so long as it isn’t removed before we sort those issues out.

Otherwise +1

Karl

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

--
-Dave

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Ben Rimmington) #15

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>

* 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>

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?

-- Ben

···

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:


(Ben Rimmington) #16

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>

···

On 10 Aug 2016, at 22:44, Erica Sadun wrote:

On Aug 9, 2016, at 1:09 PM, Dave Abrahams wrote:

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


(Ben Rimmington) #17

Yes, see <https://github.com/apple/swift/pull/4091> from the SE-0137 proposal.

<https://github.com/apple/swift/blob/8a73f0b/stdlib/public/core/Collection.swift#L18-L19>

-- Ben

···

On 11 Aug 2016, at 00:24, Brent Royal-Gordon wrote:

On Aug 9, 2016, at 12:09 PM, Dave Abrahams wrote:

Deprecate the Indexable protocols with a message indicating that they
will be gone in Swift 4.

Should IndexableBase get the same treatment?


(Dave Abrahams) #18

Yes, that's the plan, even if a backwards-compatible design isn't
proposed. The reason to deprecate it now is that we're not sure a
backwards-compatible design will be possible.

···

on Fri Aug 12 2016, Ben Rimmington <swift-evolution@swift.org> wrote:

On 9 Aug 2016, at 20:09, Dave Abrahams wrote:

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.

Can the deprecation of ExpressibleByStringInterpolation be reverted next year,
if a backwards-compatible design is proposed for Swift 4.0?

--
-Dave


(Ben Rimmington) #19

The only downside is when manually converting to current Swift syntax:

1. :warning:️ 'StringInterpolationConvertible' is deprecated:
    renamed to 'ExpressibleByStringInterpolation'

2. :ballot_box_with_check:️ Fix-it: Use 'ExpressibleByStringInterpolation' instead

3. :warning:️ 'ExpressibleByStringInterpolation' is deprecated:
    it will be replaced or redesigned in Swift 4.0.
    Instead of conforming to 'ExpressibleByStringInterpolation',
    consider adding an 'init(_:String)'

-- Ben

···

On 12 Aug 2016, at 21:03, Dave Abrahams wrote:

on Fri Aug 12 2016, Ben Rimmington wrote:

On 9 Aug 2016, at 20:09, Dave Abrahams wrote:

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.

Can the deprecation of ExpressibleByStringInterpolation be reverted next year,
if a backwards-compatible design is proposed for Swift 4.0?

Yes, that's the plan, even if a backwards-compatible design isn't
proposed. The reason to deprecate it now is that we're not sure a
backwards-compatible design will be possible.


(Charles Srstka) #20

Will do. I just fired off about five of them, before the Radar server abruptly went “Oh God, not that guy again” and decided to stop responding. :wink:

Will probably file a few more as I think of them, when I can get into the server again.

Charles

···

On Aug 9, 2016, at 7:21 PM, Michael Ilseman <milseman@apple.com> wrote:

Please file radars for these against the offending frameworks. You can additionally discuss them on swift-dev or swift-users, but definitely file those radars!