[swift-evolution] [Pitch] SE-0083 revisited: removing bridging behavior from `as`/`is`/`as?` casts

I’d like to investigate separating Objective-C bridging from the behavior of the as/as?/is operator family again for Swift 4. Last year, I proposed SE–0083 , but we deferred the proposal

Re: [swift-evolution] 'T != Type' in where clause

> On Mar 1, 2017, at 18:55, Joe Groff wrote: > > >> On Mar 1, 2017, at 5:27 PM, David Sweeris wrote: >> >> >>> On Feb 28, 2017, at 09:01, Joe Groff wrote: >>> >>> On Feb 27, 2017, at 10:21 PM, David Sweeris via swift-evolution

Re: [swift-evolution] 'T != Type' in where clause

> On Mar 1, 2017, at 5:27 PM, David Sweeris wrote: > > >> On Feb 28, 2017, at 09:01, Joe Groff wrote: >> >> >>> On Feb 27, 2017, at 10:21 PM, David Sweeris via swift-evolution >>> wrote: >>> >>> + all the 1s, along with

[swift-evolution] [Accepted] SE-0104: Protocol-oriented integers

Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md The re-review of SE-0104 ran from February 17...25, 2017. The proposal is accepted with the following revisions: - The root `Number` protocol should be renamed `Numeric`. - Instead of using

Re: [swift-evolution] 'T != Type' in where clause

on Wed Mar 01 2017, Douglas Gregor wrote: >> On Mar 1, 2017, at 1:55 AM, Jonathan Hull wrote: >> >> What I would like is a way to specialize a generic function in a block of >> code: (Strawman syntax) >> >> if T is Int.self { >>

Re: [swift-evolution] [Discussion] Simplifying case syntax

I guess I should also include the example where the user actually wanted the oldValue to be "x": if case let .two(newValue, value) = example, value == oldValue { ... } No surprises there, even if another conditional is required. — Pyry > On 1 Mar 2017, at 22.53, Pyry Jahkola via

Re: [swift-evolution] [Discussion] Simplifying case syntax

Erica, Instead of going into all these lengths introducing new syntax, why not simply turn it into a warning when a `case let` binding shadows an existing variable with the exact same type (which supposedly also conforms to Equatable)? Examples, including how to silence the said warning:

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0156: Class and Subtype existentials

Similar observation on my side as well. Certainly it is better to specify the class constrain (or the type alias that has the class constrain) first because (sub)class constrain is the most determining factor about the nature of the declaration, but I think it is too hard to enforce properly

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0156: Class and Subtype existentials

> On 1 Mar 2017, at 21:20, Matthew Johnson wrote: > > >> On Mar 1, 2017, at 2:16 PM, David Hart > > wrote: >> >> >> >> On 1 Mar 2017, at 21:01, Matthew Johnson via swift-evolution >>

Re: [swift-evolution] [Discussion] Simplifying case syntax

> On Mar 1, 2017, at 11:46 AM, Matthew Johnson wrote: >>> >>> I agree that the ambiguity created by moving `let` outside the local = >>> binding context is problematic. I alway place `let` immediately = >>> alongside the binding for this reason. =20 >>> >>> In design 2

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0156: Class and Subtype existentials

> On 1 Mar 2017, at 21:01, Matthew Johnson via swift-evolution > wrote: > > >> On Mar 1, 2017, at 1:59 PM, Brent Royal-Gordon via swift-evolution >> wrote: >> >> A good and necessary enhancement. My only objection is to the ordering

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0156: Class and Subtype existentials

A good and necessary enhancement. My only objection is to the ordering rules—I'm not convinced that they pull their weight, especially given that typealiases can be used to introduce class constraints that aren't in the leftmost position. It's a lot of rules and strictures for a dubious

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0156: Class and Subtype existentials

> On Mar 1, 2017, at 1:59 PM, Brent Royal-Gordon via swift-evolution > wrote: > > A good and necessary enhancement. My only objection is to the ordering > rules—I'm not convinced that they pull their weight, especially given that > typealiases can be used to

Re: [swift-evolution] [Draft] scope-based submodules

Wonderful comments. I really enjoy your take on submodules which keeps most of the power while keeping the simplicity. Comments below: Sent from my iPhone On 1 Mar 2017, at 07:55, Brent Royal-Gordon via swift-evolution wrote: >> On Feb 24, 2017, at 11:34 AM,

Re: [swift-evolution] [Discussion] Simplifying case syntax

Sent from my iPad > On Feb 28, 2017, at 2:17 PM, Erica Sadun wrote: > > >> On Feb 28, 2017, at 12:19 PM, Matthew Johnson wrote: >> >> --Apple-Mail=_99FCC835-0665-499E-84F7-EB04BAEF8812 >> Content-Transfer-Encoding: quoted-printable >>

Re: [swift-evolution] [Draft] Refining identifier and operator symbology (take 2)

As I said before, I am happy with this proposal overall. I just had a strange thought that I thought I should share before this goes through. If we make ‘π’ an operator instead of identifier, then we would be able to write things like 3π directly. For those of us with rational types, we

[swift-evolution] [Accepted] SE-0153: Compensate for the inconsistency of `@NSCopying`'s behaviour

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0153-compensate-for-the-inconsistency-of-nscopyings-behaviour.md Hello Swift

Re: [swift-evolution] 'T != Type' in where clause

> On Mar 1, 2017, at 1:55 AM, Jonathan Hull via swift-evolution > wrote: > > What I would like is a way to specialize a generic function in a block of > code: (Strawman syntax) > > if T is Int.self { > //In this block of code T == Int > }

Re: [swift-evolution] [Review] SE-0156: Class and Subtype existentials

> On Feb 28, 2017, at 10:39 PM, David Hart wrote: > >> >> On 28 Feb 2017, at 22:53, Jordan Rose via swift-evolution >> > wrote: >> >> Nitpick: 'C & P' is just 'C' in this example. You'd need a refinement >> of

Re: [swift-evolution] [Discussion] Simplifying case syntax

Would you agree with the following arguments? > On 1 Mar 2017, at 15:57, Xiaodi Wu wrote: > > The criteria for a source-breaking change in Swift 4 are as follows: > > - The existing syntax/API being changed must be actively harmful. The current pattern matching syntax is

Re: [swift-evolution] 'T != Type' in where clause

> On Feb 28, 2017, at 09:38, Adrian Zubarev via swift-evolution > wrote: > > I also thought about the Either type. > > enum Either where A != B { > case -> A > case -> B > } I was thinking about using it as a workaround for not having typed throws:

Re: [swift-evolution] 'T != Type' in where clause

> On Mar 1, 2017, at 1:55 AM, Jonathan Hull wrote: > > What I would like is a way to specialize a generic function in a block of > code: (Strawman syntax) > > if T is Int.self { > //In this block of code T == Int > } > > It seems to me that the

Re: [swift-evolution] [Draft] Fix Private Access Levels

> For example, I had to split this class into multiple files using extensions: > https://github.com/smud/Smud/blob/master/Sources/Smud/AreaFormatParser/AreaFormatParser.swift > I had to remove 'private'

Re: [swift-evolution] [Discussion] Simplifying case syntax

The criteria for a source-breaking change in Swift 4 are as follows: - The existing syntax/API being changed must be actively harmful. - The new syntax/API must clearly be better and not conflict with existing Swift syntax. - There must be a reasonably automatable migration path for existing

Re: [swift-evolution] [Review] SE-0157: Support recursive constraints on associated types

Definitely +1 On Wed, 1 Mar 2017 at 12:59 Haravikk via swift-evolution < swift-evolution@swift.org> wrote: > On 28 Feb 2017, at 21:40, John McCall via swift-evolution < > swift-evolution@swift.org> wrote: > > >- What is your evaluation of the proposal? > > +1 > > >- Is the problem being

Re: [swift-evolution] [Draft] Fix Private Access Levels

> In the previous very long thread, many people acknowledged that type + its > extensions private was too complex for its own good. Do you have arguments > against that? And even if it was proposed, I think many people would be very > opposed to keeping scoped in that case. There would be too

Re: [swift-evolution] [Review] SE-0157: Support recursive constraints on associated types

> On 28 Feb 2017, at 21:40, John McCall via swift-evolution > wrote: > > What is your evaluation of the proposal? +1 > Is the problem being addressed significant enough to warrant a change to > Swift? Yes. The problem it addresses is an almost daily annoyance when

Re: [swift-evolution] 'T != Type' in where clause

What I would like is a way to specialize a generic function in a block of code: (Strawman syntax) if T is Int.self { //In this block of code T == Int } It seems to me that the compiler might even be able to optimize this without a branch. If there is a return

[swift-evolution] [Discussion] What is the future of tuples in Swift?

Hi Swift community, I’d love to discuss with you the future of tuples in Swift. I’m really curious whether tuples will ever evolve beyond their current state or not. Last year we revamped custom operators with a whole new syntax in Swift, so why don’t we start a discussion on how tuples could

Re: [swift-evolution] [swift-build-dev] [Draft] Package Manager Manifest API Redesign

Hi, Thank you all for the feedback so far. I have updated the proposal: https://github.com/aciidb0mb3r/swift-evolution/blob/manifest-api-redesign/proposals/-package-manager-manifest-api-redesign.md The major changes are: * Drop SystemPackageProvider struct upgrade. * Drop the identity rule.

Re: [swift-evolution] [swit-evolution] [Review] SE-0156: Class and Subtype existentials

> What is your evaluation of the proposal? +0.9 The core of the proposal is unquestionably necessary to correct a serious deficiency in the expressivity of the type system, but I take issue with the arbitrary limitation of requiring the concrete type to be first and would give a full +1 to the

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0156: Class and Subtype existentials

> On Feb 28, 2017, at 1:19 PM, Jordan Rose via swift-evolution > wrote: > > [Proposal: > https://github.com/apple/swift-evolution/blob/master/proposals/0156-subclass-existentials.md > >

Re: [swift-evolution] [Review] SE-0157: Support recursive constraints on associated types

+1, basically the same response as Matt’s. > On Feb 28, 2017, at 1:51 PM, Matthew Johnson via swift-evolution > wrote: > >> >> What is your evaluation of the proposal? > +1. Checking things off the list of items on the generics manifesto is > always great to see,

Re: [swift-evolution] [Discussion] Simplifying case syntax

I would think that removing confusion and simplifying + rationalising the syntax IS the definition of a breaking change justified :). I do not see how Erica's proposal is in any way contrary to the philosophy behind the language or is removing anything people really depend on now (in terms of