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

1) What is your evaluation of the proposal? This is a critical must have feature in Swift. I’ve been waiting for it since Swift 1.2. 2) Is the problem being addressed significant enough to warrant a change to Swift? Absolutely. 3) Does this proposal fit well with the feel and direction of

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

> On Feb 24, 2017, at 11:34 AM, Matthew Johnson via swift-evolution > wrote: > > Scope-based submodules > > • Proposal: SE- > • Authors: Matthew Johnson > • Review Manager: TBD > • Status: Awaiting review Well, this is certainly

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

> 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 'P' to make it interesting ('C & Q’). Could generic specialisation be disallowed in constraints? I need to think

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

> 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 'P' to make it interesting ('C & Q'). > > Jordan > Or conformance to P needs to be conditional. That is my only

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

> On Feb 28, 2017, at 6:43 PM, Dave Abrahams via swift-evolution > wrote: > on Tue Feb 28 2017, John McCall wrote: > >> What is your evaluation of the proposal? > > +1, duh How much effort would you say that you've put into this review?

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

> On Feb 28, 2017, at 2:28 PM, Matthew Johnson via swift-evolution > wrote: > >> >> On Feb 28, 2017, at 4:14 PM, David Hart wrote: >> >> >>> On 28 Feb 2017, at 22:45, Matthew Johnson via swift-evolution >>> wrote:

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

on Tue Feb 28 2017, John McCall wrote: > What is your evaluation of the proposal? +1, duh -- -Dave ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

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

Agree. Design 1 seems like an improvement over the status quo. Barring unexpected downsides to this, it's then a question of whether the improvements are large enough to justify a breaking change. On Tue, Feb 28, 2017 at 3:57 PM, David Hart via swift-evolution < swift-evolution@swift.org> wrote:

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

> On Feb 28, 2017, at 4:14 PM, David Hart wrote: > > >> On 28 Feb 2017, at 22:45, Matthew Johnson via swift-evolution >> > wrote: >> >>> >>> What is your evaluation of the proposal? >> +1, this is a fantastic

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

> On 28 Feb 2017, at 22:52, Christopher Kornher via swift-evolution > wrote: > > What is your evaluation of the proposal? > It seems to be a very straightforward and natural extension of existing > syntax to bring Swift closer to the functionality of Objective-C and

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

> On Feb 28, 2017, at 2:00 PM, David Hart wrote: > > >> On 28 Feb 2017, at 22:39, Douglas Gregor via swift-evolution >> > wrote: >> >> >>> On Feb 27, 2017, at 11:21 PM, Nicolas Fezans via swift-evolution >>>

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

> On 28 Feb 2017, at 22:45, Matthew Johnson via swift-evolution > wrote: > >> >> What is your evaluation of the proposal? > +1, this is a fantastic proposal! I > > The proposal does not specifically call out whether a class may inherit from > a subclass of a

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

Hi Daniel, Thanks for the reply. Sorry I wasn't clear - by removal I actually meant remove pkgConfig from the Package, and introduce it in a custom build configuration (associated with a Target). I think pkgConfig and custom build configurations may fit nicely together. And you are absolutely

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

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

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

> On 28 Feb 2017, at 22:39, Douglas Gregor via swift-evolution > wrote: > > >> On Feb 27, 2017, at 11:21 PM, Nicolas Fezans via swift-evolution >> > wrote: >> >> +1 >> I would also welcome to be able to

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

I’m happy that someone is trying to fix this small wart in the language. I’ve always wanted something like Design 1. It makes sense because we are already used to the pattern matching operator and we finally fix the inconsistencies between if/guard and switch. > On 28 Feb 2017, at 20:01, Erica

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

Nitpick: 'C & P' is just 'C' in this example. You'd need a refinement of 'P' to make it interesting ('C & Q'). Jordan > On Feb 28, 2017, at 13:20, Joe Groff via swift-evolution > wrote: > > Composing a base class and protocol requirements opens up the possibility

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

What is your evaluation of the proposal? It seems to be a very straightforward and natural extension of existing syntax to bring Swift closer to the functionality of Objective-C and other languages. My only concern is that using `AnyObject` at first glance seems less descriptive than ‘class’

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

> > What is your evaluation of the proposal? +1. Checking things off the list of items on the generics manifesto is always great to see, especially when they allow for improvements in the standard library. > Is the problem being addressed significant enough to warrant a change to > Swift?

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

> > What is your evaluation of the proposal? +1, this is a fantastic proposal! I The proposal does not specifically call out whether a class may inherit from a subclass of a superclass constraint when a typealias is used in the inheritance list. I believe the following should be valid, but

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

Hello Swift community, The review of SE-0157 "Support recursive constraints on associated types" begins now and runs through next Wednesday, March 8, 2017. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0157-recursive-protocol-constraints.md

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

> On Feb 27, 2017, at 11:21 PM, Nicolas Fezans via swift-evolution > wrote: > > +1 > I would also welcome to be able to use "or" and "and" logical operators (not > only the not operator) on these constraints. You already have “and’ constraints: it’s what you get

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

Composing a base class and protocol requirements opens up the possibility of using the base class to constrain away a protocol's associated types, e.g.: protocol P { associatedtype T; func foo(_: T) } class C: P { func foo(_: T) {} It'd be worth calling out explicitly whether this proposal

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

[Proposal: https://github.com/apple/swift-evolution/blob/master/proposals/0156-subclass-existentials.md ] Well-written, good job, useful feature, long-since-needed-because-of-ObjC, +1. One nitpick:

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

Hello Swift community, The review of SE-0156 "Class and Subtype existentials" begins now and runs through March 7, 2017. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0156-subclass-existentials.md Reviews are an important part of the Swift

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

I suggest you split this into 2 separate proposals. The second part seems much, much more controversial than the first. Cheers, Jaden Geller > On Feb 28, 2017, at 11:01 AM, Erica Sadun via swift-evolution > wrote: > > The following draft proposal addresses one

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

> On Feb 28, 2017, at 12:19 PM, Matthew Johnson wrote: > > --Apple-Mail=_99FCC835-0665-499E-84F7-EB04BAEF8812 > Content-Transfer-Encoding: quoted-printable > Content-Type: text/plain; > charset=utf-8 > > I agree that the ambiguity created by moving `let` outside

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

Here's a simplified section of code I'm writing for mapping some data from over the wire public protocol Transform { // a bunch of stuff } public protocol Key { // a bunch of stuff } extension String: Key { /* conforming stuff */ } public protocol JSONType { } extension Int: JSONType

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

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. In design 2 do you disallow matching a value using an existing name? If so, how do users match values bound to an

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

I like the ~> operator, but not := operator. It makes the language inconsistent. Then we should allow using it without "if" just like this: mylet := "hey there" I think we should keep let as it was and avoid := P.S.: it also looks too much Pascal-ish :) On Tue, 28 Feb 2017 at 21:02 Erica Sadun

[swift-evolution] [Discussion] Simplifying case syntax

The following draft proposal addresses one matter of substance (eliminating edge case errors by adopting at-site conditional binding) and one of style (using the pattern match operator consistently). Its discussion was deferred from Phase 1 and remains in a fairly early stage. Your feedback

Re: [swift-evolution] [Pitch] Typed throws

> On Feb 28, 2017, at 12:44 PM, Dave Abrahams wrote: > > > on Tue Feb 28 2017, Karl Wagner wrote: > >>> On 28 Feb 2017, at 18:00, Matthew Johnson wrote: >>> >>> On Feb 28, 2017, at 10:44 AM, Daniel Leping >

Re: [swift-evolution] [Pitch] Typed throws

> On Feb 28, 2017, at 12:27 PM, Tino Heth via swift-evolution > wrote: > >> I disagree with that, it works if you only have a single function parameter >> type that throws an error, but if there are more than one inferring the type >> won’t be possible anymore:

Re: [swift-evolution] [Pitch] Typed throws

> On Feb 28, 2017, at 12:21 PM, Daniel Leping wrote: > > Matthew, I understand your idea. Though IMO nested exceptions lead to > cluttering and to tons of boilerplate code. I understand this and am suggesting that this boilerplate is a problem that can be addressed

Re: [swift-evolution] [Pitch] Typed throws

on Tue Feb 28 2017, Karl Wagner wrote: >> On 28 Feb 2017, at 18:00, Matthew Johnson wrote: >> >> >>> On Feb 28, 2017, at 10:44 AM, Daniel Leping > wrote: >>> > >>> Mathew, I totally understand what you're

Re: [swift-evolution] [Pitch] Typed throws

> On Feb 28, 2017, at 11:55 AM, Karl Wagner wrote: > > >> On 28 Feb 2017, at 18:00, Matthew Johnson > > wrote: >> >> >>> On Feb 28, 2017, at 10:44 AM, Daniel Leping >>

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

Hello Daniel, In general I’m really happy with the changes in the proposal and especially after you have incorporated the comments from David (Thanks David). In the proposal it is stated that the exclude section may be eliminated as soon as we have custom layouts. My question is: would

Re: [swift-evolution] [Pitch] Typed throws

> I disagree with that, it works if you only have a single function parameter > type that throws an error, but if there are more than one inferring the type > won’t be possible anymore: func foo(_: () throws(T) -> Void, _: () throws(S) > -> Void) rethrows(S) (here, we’re assuming that T is

Re: [swift-evolution] [Pitch] Typed throws

Matthew, I understand your idea. Though IMO nested exceptions lead to cluttering and to tons of boilerplate code. What I think is that the important (logical) parts are to be provided by custom errors (not wrapped, just custom). It's a good practice and you don't need any typed throws for it.

Re: [swift-evolution] [Pitch] Typed throws

> On 28 Feb 2017, at 18:00, Matthew Johnson wrote: > > >> On Feb 28, 2017, at 10:44 AM, Daniel Leping > > wrote: >> >> Mathew, I totally understand what you're talking about. And this is exactly >> what I

Re: [swift-evolution] [Pitch] Typed throws

> On Feb 28, 2017, at 11:17 AM, Zaid Daghestani wrote: > > Matthew, Per api fragility, the only API fragility would likely be adding a > new error to the signature, which isn’t that bad. Any significant error > changes, would probably mirror a significant change in that

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

I also thought about the Either type. enum Either where A != B { case -> A case -> B } --  Adrian Zubarev Sent with Airmail Am 28. Februar 2017 um 18:35:45, Matthew Johnson via swift-evolution (swift-evolution@swift.org) schrieb: On Feb 28, 2017, at 11:33 AM, Joe Groff

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

> On Feb 28, 2017, at 11:33 AM, Joe Groff wrote: > >> >> On Feb 28, 2017, at 9:23 AM, Matthew Johnson wrote: >> >> >>> On Feb 28, 2017, at 11:04 AM, Joe Groff via swift-evolution >>> wrote: >>> >>> On Feb 27,

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

> On Feb 28, 2017, at 9:23 AM, Matthew Johnson wrote: > > >> On Feb 28, 2017, at 11:04 AM, Joe Groff via swift-evolution >> wrote: >> >> >>> On Feb 27, 2017, at 4:34 PM, Rex Fenley via swift-evolution >>>

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

> On Feb 28, 2017, at 11:04 AM, Joe Groff via swift-evolution > wrote: > > >> On Feb 27, 2017, at 4:34 PM, Rex Fenley via swift-evolution >> wrote: >> >> I often find myself running into situations where I'll receive "Ambiguous >> use

Re: [swift-evolution] [Pitch] Typed throws

> On Feb 28, 2017, at 11:08 AM, Vladimir.S wrote: > > On 28.02.2017 19:48, Matthew Johnson wrote: >> >>> On Feb 28, 2017, at 6:47 AM, Vladimir.S wrote: >>> >>> On 28.02.2017 0:40, Matthew Johnson via swift-evolution wrote: > On Feb 27, 2017, at

Re: [swift-evolution] [Pitch] Typed throws

Matthew, Per api fragility, the only API fragility would likely be adding a new error to the signature, which isn’t that bad. Any significant error changes, would probably mirror a significant change in that libraries pattern in and of itself, which would lend to a Semver.Major version bump

Re: [swift-evolution] [Pitch] Typed throws

On 28.02.2017 19:48, Matthew Johnson wrote: On Feb 28, 2017, at 6:47 AM, Vladimir.S wrote: On 28.02.2017 0:40, Matthew Johnson via swift-evolution wrote: On Feb 27, 2017, at 1:46 PM, David Waite via swift-evolution

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

> On Feb 27, 2017, at 4:34 PM, Rex Fenley via swift-evolution > wrote: > > I often find myself running into situations where I'll receive "Ambiguous use > of..." for overloaded functions or operators. In every case these situations > would be easily solved if I

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

> On Feb 27, 2017, at 10:21 PM, David Sweeris via swift-evolution > wrote: > > > > > Sent from my iPhone >> On Feb 27, 2017, at 16:34, Rex Fenley via swift-evolution >> wrote: >> >> I often find myself running into situations where

Re: [swift-evolution] [Pitch] Typed throws

> On Feb 28, 2017, at 10:44 AM, Daniel Leping wrote: > > Mathew, I totally understand what you're talking about. And this is exactly > what I want to avoid. > > If a library developer knows how to handle certain case (i.e. recover or > throw a special error) I'm ok

Re: [swift-evolution] [Pitch] Typed throws

> On Feb 28, 2017, at 6:47 AM, Vladimir.S wrote: > > On 28.02.2017 0:40, Matthew Johnson via swift-evolution wrote: >> >>> On Feb 27, 2017, at 1:46 PM, David Waite via swift-evolution >>> > wrote: >>> >>> IMHO,

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0155: Normalize Enum Case Representation

> On Feb 28, 2017, at 10:39 AM, Joe Groff wrote: > > >> On Feb 27, 2017, at 7:17 PM, Xiaodi Wu via swift-evolution >> wrote: >> >> Having watched this conversation from the sidelines, I just wanted to chime >> in from a more distant view: >> >>

Re: [swift-evolution] [Pitch] Typed throws

Mathew, I totally understand what you're talking about. And this is exactly what I want to avoid. If a library developer knows how to handle certain case (i.e. recover or throw a special error) I'm ok with it. Though I'm not ok with completely hiding errors from the underlying implementation. The

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0155: Normalize Enum Case Representation

> On Feb 27, 2017, at 7:17 PM, Xiaodi Wu via swift-evolution > wrote: > > Having watched this conversation from the sidelines, I just wanted to chime > in from a more distant view: > > Originally, I thought this proposal was very nice because it made a good >

Re: [swift-evolution] [Pitch] Typed throws

> On Feb 28, 2017, at 5:09 AM, Daniel Leping wrote: > > When you're going to present a user with specific error message you don't do > it for all errors. First of all at the end of a call chain you will have a > couple of dozens of possible errors and only 2 or 3

Re: [swift-evolution] [Pitch] Typed throws

> On Feb 28, 2017, at 12:29 AM, Karl Wagner wrote: > > >> On 28 Feb 2017, at 02:43, Matthew Johnson via swift-evolution >> > wrote: >> >> >> >> Sent from my iPad >> >> On Feb 27, 2017, at 7:19 PM, Daniel

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

> On Feb 28, 2017, at 12:28 AM, Jens Nerup wrote: > > Hello Daniel, > > In general I’m really happy with the changes in the proposal and especially > after you have incorporated the comments from David (Thanks David). In the > proposal it is stated that the exclude section

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

> On Feb 27, 2017, at 10:24 PM, David Hart wrote: > > > > On 28 Feb 2017, at 01:50, Daniel Dunbar > wrote: > >> Hi David, >> >> We discussed the leading-dot & capitalization issue today again... this was >>

Re: [swift-evolution] [Pitch] Typed throws

> On Feb 27, 2017, at 11:04 PM, David Waite > wrote: > > >> On Feb 27, 2017, at 2:08 PM, Matthew Johnson > > wrote: >> >>> >>> On Feb 27, 2017, at 1:46 PM, David Waite via swift-evolution >>>

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0155: Normalize Enum Case Representation

> On Feb 27, 2017, at 9:53 PM, Brent Royal-Gordon > wrote: > > > > -- > Brent Royal-Gordon > Sent from my iPhone >> On Feb 27, 2017, at 10:39 AM, Matthew Johnson via swift-evolution >> wrote: > >> >> Here is an example of the kind of

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0155: Normalize Enum Case Representation

> On Feb 27, 2017, at 9:17 PM, Xiaodi Wu wrote: > > Having watched this conversation from the sidelines, I just wanted to chime > in from a more distant view: > > Originally, I thought this proposal was very nice because it made a good > argument as to why enum cases

Re: [swift-evolution] A Comprehensive Rethink of Access Levels in Swift

> as ‘closed’ is a rare niche case. If there is agreement on the importance of closed, imho we shouldn't even need variants of final: You could already build the required class hierarchies if the restriction that a subclass can't have higher visibility as its parent is lifted. Imho this

Re: [swift-evolution] A Comprehensive Rethink of Access Levels in Swift

Rien, your example shows two things (well, three, but one relates to variadic arguments not access levels). First, it shows the importance of being able to prevent external overrides of individual methods. I did not directly address that in my pitch, however it could easily use the same syntax as

Re: [swift-evolution] [Pitch] Typed throws

On 28.02.2017 0:40, Matthew Johnson via swift-evolution wrote: On Feb 27, 2017, at 1:46 PM, David Waite via swift-evolution > wrote: IMHO, there are two kinds of responses to errors - a specific response, and a general one. Only the

Re: [swift-evolution] [Pitch] Typed throws

When you're going to present a user with specific error message you don't do it for all errors. First of all at the end of a call chain you will have a couple of dozens of possible errors and only 2 or 3 will do really matter for the end user. Would you list all the dozen in params? Probably not.

Re: [swift-evolution] A Comprehensive Rethink of Access Levels in Swift

Ah, the irony… Having argued against too much complexity, I now encountered an error in my software that shows why there might indeed be a need for “open” and “public”. In an API: class Foo { open func foo(options: Option ...) { foo(options) } open func foo(options: [Options]) { … }

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

The or operator for types is rejected in Swift, and probably won’t ever make it, however there might be hope for enums to solve this issue. Some people pointed out in different threads how enums could mimic such behavior. +1 for != type operator I bumped myself once or twice into such a

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

But it already works without where T != Self. Moreover, I guess, this solution is currently considered “good enough” not to introduce additional complexity to type system. Also, on and and or—the former already exists in the form of &, and the latter is listed in commonly proposed rejected