Re: [swift-evolution] [Proposal draft] Conditional conformances

ery quickly, so any extension needs to be strongly motivated by use cases to matter to all or most Swift developers. - Doug > >> On Sep 26, 2016, at 7:18 PM, Douglas Gregor via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> w

Re: [swift-evolution] [Proposal draft] Conditional conformances

> On Sep 28, 2016, at 11:40 AM, Goffredo Marocchi <pana...@gmail.com> wrote: > > > > Sent from my iPhone > > On 28 Sep 2016, at 17:51, Douglas Gregor via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >

Re: [swift-evolution] [Proposal draft] Conditional conformances

> On Sep 28, 2016, at 2:55 AM, Anton Zhilin wrote: > > I find the limitation of non-intersection of conditional conformance > reqirements quite limiting. Can it be lifted in case there are no overloaded > functions between extensions? > > protocol A { func foo() } >

Re: [swift-evolution] [Review] SE-0142: Permit where clauses to constrain associated types

Sent from my iPhone > On Sep 24, 2016, at 6:55 PM, Nate Cook wrote: > > >> https://github.com/apple/swift-evolution/blob/master/proposals/0142-associated-types-constraints.md > >> What is your evaluation of the proposal? > [Smiling Face With Heart-Shaped Eyes Emoji] > >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0142: Permit where clauses to constrain associated types

Sent from my iPhone > On Sep 24, 2016, at 12:58 PM, Drew Crawford via swift-evolution > wrote: > > This is the #1 Swift feature I have wanted for the past 2 years. > > One thing I would like to see (perhaps out of scope for this proposal) is the > natural

[swift-evolution] [Proposal draft] Conditional conformances

Conditional conformances Proposal: SE- Author: Doug Gregor Review Manager: TBD Status: Awaiting review During the review process, add the

[swift-evolution] [Review] SE-0142: Permit where clauses to constrain associated types

Hello Swift community, The review of SE-0142: "Permit where clauses to constrain associated types" begins now and runs through September 30, 2016. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0142-associated-types-constraints.md Reviews are an

[swift-evolution] [Review] SE-0141: Availability by Swift version

Hello Swift community, The review of SE-0141 "Availability by Swift version" begins now and runs through September 28, 2016. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0141-available-by-swift-version.md Reviews are an important part of the

Re: [swift-evolution] [Pitch] Align label behavior for subscripts

> On Sep 20, 2016, at 3:36 AM, Adrian Zubarev via swift-evolution > wrote: > > This is probably something additional and it might already have been > discussed here somewhere, I apologize if I missed that talk. > > The rule for parameter labels on functions was

Re: [swift-evolution] [Review] SE-0140: Bridge Optional As Its Payload Or NSNull

ries with a similar feature, how >> do you feel that this proposal compares to those? >> >> - >> >> • How much effort did you put into your review? A glance, a quick reading, >> or an in-depth study? >> >> I even filed a Swift bug (SR-26

Re: [swift-evolution] [swift-evolution-announce] [Accepted] SE-0140: Bridge Optional As Its Payload Or NSNull

> On Sep 12, 2016, at 4:48 PM, Greg Parker via swift-evolution > wrote: > > >> On Sep 12, 2016, at 3:39 PM, Douglas Gregor > > wrote: >> >> As an amendment to SE-0140, Swift will produce a warning when an optional >>

[swift-evolution] [Accepted] SE-0140: Bridge Optional As Its Payload Or NSNull

Hello Swift community, The review of SE-0140 "Bridge Optional As Its Payload Or NSNull” ran from September 2…8, 2016. The proposal is accepted with one modification (described below). Reviews on

[swift-evolution] [SE-0139] Bridge Numeric Types to NSNumber and Cocoa Structs to NSValue

Hello Swift community, The review of SE-00139 "Bridge Numeric Types to NSNumber and Cocoa Structs to NSValue” ran from September 1…7, 2016. The proposal has been accepted with one modification:

Re: [swift-evolution] [Swift 4.0] Conditional conformances via protocol extensions

> On Sep 12, 2016, at 8:14 AM, Paul Cantrell <cantr...@pobox.com> wrote: > > >> On Aug 11, 2016, at 9:39 PM, Douglas Gregor via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> FWIW, I'm pl

Re: [swift-evolution] [Swift 4.0] Conditional conformances via protocol extensions

Sent from my iPhone > On Sep 10, 2016, at 2:26 PM, Maximilian Hünenberger <m.huenenber...@me.com> > wrote: > > > >> Am 12.08.2016 um 04:39 schrieb Douglas Gregor via swift-evolution >> <swift-evolution@swift.org>: >> >> >>

Re: [swift-evolution] Amendment to SE-0112: Default values for errorDomain and errorCode

> On Sep 8, 2016, at 3:46 AM, Tino Heth <2...@gmx.de> wrote: > > >> Domain, code, and user-info are useful for Cocoa interoperability but aren’t >> otherwise necessary in Swift, which captures that information more directly >> in the (concrete) error types that conform to Error. > So the only

Re: [swift-evolution] [Review] SE-0140: Bridge Optional As Its Payload Or NSNull

> wrote: >>> >>> >>>>> On Sep 2, 2016, at 5:17 PM, Charles Srstka via swift-evolution >>>>> <swift-evolution@swift.org> wrote: >>>>> >>>>> On Sep 2, 2016, at 5:50 PM, Douglas Gregor via swift-evolution >&

Re: [swift-evolution] [Review] SE-0140: Bridge Optional As Its Payload Or NSNull

> On Sep 6, 2016, at 4:50 PM, Joe Groff <jgr...@apple.com> wrote: > > >> On Sep 2, 2016, at 5:17 PM, Charles Srstka via swift-evolution >> <swift-evolution@swift.org> wrote: >> >>> On Sep 2, 2016, at 5:50 PM, Douglas Gregor via swift-

Re: [swift-evolution] The great renaming and the state of new Unified Logging in Swift

Sent from my iPhone > On Sep 5, 2016, at 2:46 PM, Goffredo Marocchi wrote: > > > > Sent from my iPhone > >> On 5 Sep 2016, at 20:01, Douglas Gregor wrote: >> >> >> >> Sent from my iPhone >> >>> On Sep 5, 2016, at 11:20 AM, Goffredo Marocchi

Re: [swift-evolution] The great renaming and the state of new Unified Logging in Swift

Sent from my iPhone > On Sep 5, 2016, at 11:20 AM, Goffredo Marocchi wrote: > > > Sent from my iPhone > >> On 5 Sep 2016, at 18:59, Douglas Gregor wrote: >> >> >> >> Sent from my iPhone >> >>> On Sep 4, 2016, at 11:48 PM, Goffredo Marocchi

Re: [swift-evolution] The great renaming and the state of new Unified Logging in Swift

Sent from my iPhone > On Sep 4, 2016, at 11:48 PM, Goffredo Marocchi wrote: > > Hey Doug, > > How do I use it in Swift code without a wrapper, which is understandably a > bit pointless, if I still support iOS 9? #if or a wrapper are your best options. - Doug > >

Re: [swift-evolution] The great renaming and the state of new Unified Logging in Swift

Sent from my iPhone > On Sep 4, 2016, at 9:05 PM, Brandon Knope wrote: > > Where should the lack of {public} be reported then? > > This seems like it falls under jira and not radar because it's in swift open > source but I'm not 100 percent Overlays are a grey area. Please

Re: [swift-evolution] The great renaming and the state of new Unified Logging in Swift

Sent from my iPhone > On Sep 3, 2016, at 11:32 AM, Ben Rimmington via swift-evolution > wrote: > > >> On 3 Sep 2016, at 19:13, Brandon Knope wrote: >> >> Thank you! I was looking for this last night and failed. >> >> Why do you think {public}

[swift-evolution] [Review] SE-0140: Bridge Optional As Its Payload Or NSNull

Hello Swift community, The review of SE-0140 "Bridge Optional As Its Payload Or NSNull" begins now and runs through September 8, 2016. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0140-bridge-optional-to-nsnull.md Reviews are an important part

Re: [swift-evolution] Amendment to SE-0112: Default values for errorDomain and errorCode

> On Sep 2, 2016, at 5:59 AM, Tino Heth via swift-evolution > wrote: > > Why not simply add those default implementations to Error? > I can't see the value of hiding read-only properties that are already there… Domain, code, and user-info are useful for Cocoa

Re: [swift-evolution] Amendment to SE-0112: Default values for errorDomain and errorCode

> On Aug 5, 2016, at 4:32 PM, Charles Srstka via swift-evolution > wrote: > > MOTIVATION: > > SE-0112 includes the CustomNSError protocol, which includes the properties > errorDomain, errorCode, and errorUserInfo. These properties can be used to > tell Swift how

Re: [swift-evolution] Type-annotated throws

> On Aug 29, 2016, at 12:14 PM, Charles Srstka via swift-evolution > wrote: > >> On Aug 29, 2016, at 4:18 AM, Tino Heth via swift-evolution >> > wrote: >> >> I'm quite skeptical here (Java has already

[swift-evolution] [Review] SE-0139: Bridge Numeric Types to NSNumber and Cocoa Structs to NSValue

Hello Swift community, The review of SE-0139 "Bridge Numeric Types to NSNumber and Cocoa Structs to NSValue" begins now and runs through September 7, 2016. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0139-bridge-nsnumber-and-nsvalue.md Reviews

Re: [swift-evolution] [Proposal draft] Bridge Optional As Its Payload Or NSNull

> On Aug 24, 2016, at 6:27 PM, Greg Parker <gpar...@apple.com> wrote: > > >> On Aug 23, 2016, at 3:36 PM, Douglas Gregor via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> Propose

Re: [swift-evolution] [Proposal draft] Bridge Numeric Types to NSNumber and Cocoa Structs to NSValue

PM, Tony Parker <anthony.par...@apple.com >>> <mailto:anthony.par...@apple.com>> wrote: >>> >>> Hi Doug, >>> >>>> On Aug 23, 2016, at 3:36 PM, Douglas Gregor via swift-evolution >>>> <swift-evolution@swift.org <m

Re: [swift-evolution] Renaming for Protocol Conformance

> On Aug 22, 2016, at 9:59 PM, Jonathan Hull via swift-evolution > wrote: > > Hi everyone, > > We talked about this before when we were discussing mixins, and there seemed > to be generally positive feelings towards it as a feature for the future. I > am fairly

Re: [swift-evolution] [Proposal draft] Bridge Optional As Its Payload Or NSNull

Is? That method returns “CAAction?”, so ‘nil’ will come through as ‘nil’ and NSNull can be stored in the .some(x). - Doug > > - David > >> On 24 Aug 2016, at 00:36, Douglas Gregor via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swif

Re: [swift-evolution] [Proposal draft] Bridge Numeric Types to NSNumber and Cocoa Structs to NSValue

> On Aug 23, 2016, at 4:00 PM, Tony Parker <anthony.par...@apple.com> wrote: > > Hi Doug, > >> On Aug 23, 2016, at 3:36 PM, Douglas Gregor via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >>

[swift-evolution] [Proposal draft] Bridge Optional As Its Payload Or NSNull

Introduction Optionals can be used as values of the type Any, but only bridge as opaque objects in Objective-C. We should bridge Optionals with some value by bridging the wrapped value, and bridge nils to the NSNull singleton. Swift-evolution thread: TBD

[swift-evolution] [Proposal draft] Bridge Numeric Types to NSNumber and Cocoa Structs to NSValue

Introduction A handful of Swift numeric types are bridged to NSNumber when passed into Objective-C object contexts. We should extend this bridging behavior to all Swift numeric types. We should also bridge common Cocoa structs such as NSRangeby boxing them into NSValue objects.

Re: [swift-evolution] [swift-dev] SE-0111 related question

> On Aug 18, 2016, at 11:17 AM, Xiaodi Wu <xiaodi...@gmail.com> wrote: > > On Thu, Aug 18, 2016 at 1:10 PM, Douglas Gregor via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >> On Aug 18, 2016, at 9:52 AM, Benjam

Re: [swift-evolution] [swift-dev] SE-0111 related question

> On Aug 18, 2016, at 9:52 AM, Benjamin G via swift-dev > wrote: > > Sorry for mentioning this issue again, as it seems to have been already much > discussed, but i've had the unfortunate experience of dealing with the > consequences of this proposal in my code since

Re: [swift-evolution] Amendment to SE-0112: Default values for errorDomain and errorCode

> On Aug 5, 2016, at 4:32 PM, Charles Srstka via swift-evolution > wrote: > > MOTIVATION: > > SE-0112 includes the CustomNSError protocol, which includes the properties > errorDomain, errorCode, and errorUserInfo. These properties can be used to > tell Swift how

Re: [swift-evolution] [Swift 4.0] Conditional conformances via protocol extensions

Sent from my iPhone > On Aug 4, 2016, at 2:36 AM, Haravikk via swift-evolution > wrote: > > >>> On 4 Aug 2016, at 03:19, Brent Royal-Gordon via swift-evolution >>> wrote: >>> >>> On Aug 3, 2016, at 10:17 AM, Manav Gabhawala via

Re: [swift-evolution] [swift-dev] [Swift 4] Organizing source stability

> On Aug 3, 2016, at 1:16 AM, Brent Royal-Gordon via swift-dev > wrote: > >> On Jul 29, 2016, at 5:55 PM, Jacob Bandes-Storch via swift-evolution >> wrote: >> >> • a top-of-file "shebang"-style comment indicating the version, >>

Re: [swift-evolution] [Accepted] SE-0112: Improved NSError Bridging

> On Aug 2, 2016, at 2:19 PM, Jon Shier wrote: > > Thanks Doug. I missed the rename, as earlier points still referred to > ErrorProtocol. In regards to the CloudKit errors, I appreciate the strongly > typed CKError, but why not have the methods return that type

Re: [swift-evolution] [Accepted] SE-0112: Improved NSError Bridging

> On Aug 2, 2016, at 10:30 AM, Jon Shier via swift-evolution > wrote: > > I’m not sure where to put such feedback, but the ErrorProtocol to Error > rename that accompanied the implementation of this proposal is very, very > painful. It completely eliminates

Re: [swift-evolution] Swift Generics: connection between equality constraints on generic parameters and GADTs

> On Aug 2, 2016, at 9:36 AM, Gabriel Scherer wrote: > > I'm not familiar with Swift, but happened to find the Generics > Manifesto document at > https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md > > I wonder if the Swift community is aware of the

Re: [swift-evolution] Swift 3.0 vs 3.x and Timing Clarification

> On Jul 30, 2016, at 9:19 PM, Robert Hedin via swift-evolution > wrote: > > I thought Chris was pretty clear as well; but what was said was: > > "Over the next year, the core team expects to ship two major releases of > Swift: Swift 3.x in Spring 2017 and Swift 4

Re: [swift-evolution] [swift-evolution-announce] [Review #2] SE-0091: Improving operator requirements in protocols

> On Jul 12, 2016, at 10:35 AM, Jordan Rose wrote: > > [Proposal: > https://github.com/apple/swift-evolution/blob/master/proposals/0091-improving-operators-in-protocols.md > >

[swift-evolution] [Accepted] SE-0086 "Drop NS Prefix in Swift Foundation"

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0086-drop-foundation-ns.md The review of SE-0086 "Drop NS Prefix in Swift Foundation” ran from May 9…16, 2016. The proposal is *accepted*. This proposal has evolved greatly from a single bullet item in the original

[swift-evolution] [Accepted] SE-0109: Remove the Boolean protoco

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0109-remove-boolean.md The second review of "SE-0109: Remove the Boolean protocol" ran from June 28 ... July 4, 2016. The

Re: [swift-evolution] [Pitch] Introduce continue to switch statements

t; On 12 Jul 2016, at 18:07, Leonardo Pessoa via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> I'd agree with Doug, completely out of scope. The only way I'd support >> a goto statement was to jump to another switch case as in C#. >> >> L &

Re: [swift-evolution] [Pitch] Introduce continue to switch statements

> On Jul 12, 2016, at 8:47 AM, Erica Sadun via swift-evolution > wrote: > > >> On Jul 11, 2016, at 4:49 PM, Chris Lattner > > wrote: >> >> As for all of the other additive changes, I would strongly prefer you to >>

Re: [swift-evolution] [Accepted] SE-0111: Remove type system significance of function argument labels

> On Jul 7, 2016, at 3:18 AM, Taras Zakharko via swift-evolution > wrote: > > I would also be interested in a clarification on this point from Chris or > someone else from the core team. > > The accepted proposal states that labels are illegal in function types

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0108: Remove associated type inference

> On Jul 6, 2016, at 10:43 AM, Jordan Rose wrote: > >> >> On Jul 1, 2016, at 15:53, Russ Bishop > > wrote: >> >> >>> On Jun 30, 2016, at 4:23 PM, Jordan Rose via swift-evolution >>>

Re: [swift-evolution] [Review] SE-0112: Improved NSError Bridging

> On Jul 5, 2016, at 10:35 PM, Ben Rimmington wrote: > > >> On 5 Jul 2016, at 21:41, Douglas Gregor > > wrote: >> >>> The following comment is incorrect, AFAIK. The `helpAnchor` is the name >>> attribute of a HTML anchor

Re: [swift-evolution] [Review] SE-0112: Improved NSError Bridging

> On Jul 5, 2016, at 5:54 PM, Ben Rimmington wrote: > >> >> On 6 Jul 2016, at 01:02, Douglas Gregor > > wrote: >> >>> On Jul 5, 2016, at 5:00 PM, Ben Rimmington >> >

Re: [swift-evolution] [Review] SE-0112: Improved NSError Bridging

> On Jul 5, 2016, at 5:00 PM, Ben Rimmington wrote: > > > > The new protocols could be combined into a single CustomNSError protocol. > This would mirror the NSError class APIs,

Re: [swift-evolution] [Review] SE-0112: Improved NSError Bridging

> On Jul 4, 2016, at 10:15 PM, Ben Rimmington wrote: > > > > If uses NS_EXTENSIBLE_STRING_ENUM for `domain` names > and `userInfo` keys, would a generic type (cf.

Re: [swift-evolution] [Review] SE-0112: Improved NSError Bridging

> On Jul 1, 2016, at 6:25 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> * What is your evaluation of the proposal? > > Massively in favor overall. I use NSError features heavily in Objective-C, > and I'll be very, very glad to get powerful error

Re: [swift-evolution] [Review] SE-0112: Improved NSError Bridging

> On Jul 1, 2016, at 5:25 PM, Charles Srstka <cocoa...@charlessoft.com> wrote: > >> On Jul 1, 2016, at 4:12 PM, Douglas Gregor via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> FYI, in-progress i

Re: [swift-evolution] [Review] SE-0112: Improved NSError Bridging

FYI, in-progress implementation is available at: https://github.com/apple/swift/tree/nserror-bridging The only issue I’ve found so far with the proposal is this bit: When we introduce this bridging, we will need to remove

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0108: Remove associated type inference

> On Jun 29, 2016, at 4:38 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> >> https://github.com/apple/swift-evolution/blob/master/proposals/0108-remove-assoctype-inference.md > >> * What is your evaluation of the proposal? > > I don't think the

Re: [swift-evolution] [Proposal draft] NSError bridging

On Jun 29, 2016, at 10:05 AM, Dmitri Gribenko wrote:On Wed, Jun 29, 2016 at 4:13 AM, Charles Srstka wrote:On Jun 29, 2016, at 2:50 AM, Dmitri Gribenko via swift-evolution wrote:I'm not sure I really want '.url' and

Re: [swift-evolution] [Pitch] Make NSNotification names a protocol like ErrorProtocol

Sent from my iPhone On Jun 29, 2016, at 6:51 PM, Brent Royal-Gordon via swift-evolution wrote: >> On Jun 29, 2016, at 6:07 PM, Kenny Leung via swift-evolution >> wrote: >> >> 1. I think following the pattern of ErrorProtocol would be

Re: [swift-evolution] [Pitch] Remove type inference for associated types

n? >> >> l8r >> Sean >> >> >> >>> On Jun 29, 2016, at 8:55 AM, Brandon Knope via swift-evolution >>> <swift-evolution@swift.org> wrote: >>> >>> What's the rationale for having associatedtype in protocols and typealias

Re: [swift-evolution] [Pitch] Remove type inference for associated types

> On Jun 28, 2016, at 11:43 PM, Paulo Faria wrote: > >> >> On Jun 29, 2016, at 3:40 AM, Douglas Gregor > > wrote: >> >>> >>> On Jun 28, 2016, at 11:36 PM, Paulo Faria >> > wrote: >>>

[swift-evolution] [Review] SE-0109: Remove the Boolean protocol

Hello Swift community, The review of SE-0109 "Remove the Boolean protocol" begins now and runs through July 4, 2016. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0109-remove-boolean.md

Re: [swift-evolution] [Pitch] Remove type inference for associated types

> On Jun 28, 2016, at 11:36 PM, Paulo Faria wrote: > >> >> On Jun 29, 2016, at 2:54 AM, Douglas Gregor > > wrote: >> >> >> >> Sent from my iPhone >> >> On Jun 28, 2016, at 10:51 PM, Paulo Faria >

Re: [swift-evolution] [Proposal draft] NSError bridging

; >> On Jun 28, 2016, at 4:33 PM, Douglas Gregor via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> >>> On Jun 27, 2016, at 1:58 PM, Charles Srstka via swift-evolution >>> <swift-evolution@swift.org> wrote: >>

Re: [swift-evolution] [Pitch] Remove type inference for associated types

Sent from my iPhone > On Jun 28, 2016, at 10:51 PM, Paulo Faria wrote: > > >> On Jun 29, 2016, at 2:48 AM, Austin Zheng wrote: >> >> If you tested it, there's a problem with the current behavior independent of >> associated type inference, and it

Re: [swift-evolution] [Pitch] Remove type inference for associated types

Sent from my iPhone > On Jun 28, 2016, at 10:45 PM, Austin Zheng wrote: > > Thank you for your detailed feedback. Would it be helpful if I prepared a PR? Yes, it would be very helpful. - Doug > > Austin > >>> On Jun 28, 2016, at 10:33 PM, Douglas Gregor

Re: [swift-evolution] [Pitch] Remove type inference for associated types

> On Jun 24, 2016, at 10:50 PM, Austin Zheng via swift-evolution > wrote: > > Hello all, > > Per Chris Lattner's list of open Swift 3 design topics > (http://article.gmane.org/gmane.comp.lang.swift.evolution/21369 >

Re: [swift-evolution] [Pitch] Remove type inference for associated types

> On Jun 28, 2016, at 9:45 PM, Paulo Faria wrote: > > >> On Jun 28, 2016, at 3:34 PM, Matthew Johnson via swift-evolution >> > wrote: >> Finally, I am very concerned that there are protocols such as Collection,

Re: [swift-evolution] [Proposal draft] NSError bridging

> On Jun 27, 2016, at 1:58 PM, Charles Srstka via swift-evolution > wrote: > > Obviously, I’m in favor of this one. +1! > > I think I did prefer the older name of CustomUserInfoError for the > domain/code/userInfo protocol, rather than CustomNSError. This is just

Re: [swift-evolution] [Pitch] Remove type inference for associated types

> On Jun 25, 2016, at 12:51 AM, Dmitri Gribenko via swift-evolution > wrote: > > On Fri, Jun 24, 2016 at 10:50 PM, Austin Zheng via swift-evolution > wrote: >> Hello all, >> >> Per Chris Lattner's list of open Swift 3 design topics >>

Re: [swift-evolution] [Pitch] Remove type inference for associated types

> On Jun 27, 2016, at 12:56 PM, Dave Abrahams via swift-evolution > wrote: > > > on Sat Jun 25 2016, Austin Zheng wrote: > >>> On Jun 25, 2016, at 6:23 AM, Matthew Johnson wrote: >>> >>> Hi Austin, >>> >>> I’m

Re: [swift-evolution] [discussion] Change the behavior of @objc on a class?

> On Jun 27, 2016, at 1:26 PM, Jordan Rose via swift-evolution > wrote: > > Hey, all. An engineer at Apple noticed the following behavior: > > 1. class Foo: NSObject → exposed to Objective-C, Swift-style (mangled) > runtime name > 2. @objc class Foo: NSObject →

Re: [swift-evolution] Partial list of open Swift 3 design topics

> On Jun 28, 2016, at 9:49 AM, Austin Zheng wrote: > > This makes sense. If nobody objects I'll prepare a proposal today. > > By the way, on the topic of design topics: is there any core team support for > removing associated type inference? I have a proposal there

Re: [swift-evolution] Partial list of open Swift 3 design topics

> On Jun 27, 2016, at 10:40 PM, Charlie Monroe > wrote: > > Oh, I see. The issue is then the following: > > let x = f > x(1, 2) // Error: Missing argument labels 'a:b:' in call > > let y: (Int, Int) -> () = f > f(1, 2) // OK > > Which requires you to write x(a: 1,

Re: [swift-evolution] Partial list of open Swift 3 design topics

> On Jun 26, 2016, at 3:57 PM, Russ Bishop via swift-evolution > wrote: > > >> On Jun 22, 2016, at 11:48 PM, David Hart via swift-evolution >> wrote: >> >> >>> - Bridge NSRange to “Range?” >> >> I don’t think I can handle writing a

Re: [swift-evolution] Partial list of open Swift 3 design topics

> On Jun 24, 2016, at 9:22 AM, Paul Cantrell via swift-evolution > wrote: > > Way back when, there was an unresolved discussion was about whether it’s a > bug or a feature that $0 sometimes captures a single arg and sometimes > captures all args as a tuple: > >

Re: [swift-evolution] [Pitch] Consistent bridging for NSErrors at the language boundary

Sent from my iPhone > On Jun 20, 2016, at 11:03 AM, Charles Srstka via swift-evolution > wrote: > > It was deferred until after Swift 3.0. > > https://github.com/apple/swift-evolution/pull/331 > > I plan to resubmit the proposal after Swift 3.0 comes out. Do you

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

Sent from my iPhone > On Jun 18, 2016, at 2:29 AM, Thorsten Seitz wrote: > > >>> Am 17.06.2016 um 16:11 schrieb Douglas Gregor : >>> >>> On Jun 16, 2016, at 9:46 AM, Thorsten Seitz via swift-evolution wrote:

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

> On Jun 16, 2016, at 9:46 AM, Thorsten Seitz via swift-evolution > wrote: > >> >> Am 16.06.2016 um 17:36 schrieb Paul Cantrell > >: >> >>> On Jun 16, 2016, at 8:29 AM, Thorsten Seitz via swift-evolution >>>

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0091: Improving operator requirements in protocols

> On Jun 10, 2016, at 8:24 AM, Tony Allevato <allev...@google.com> wrote: > > Thanks for your feedback, Doug! I've addressed some of your concerns inline. > > On Thu, Jun 9, 2016 at 10:16 PM Douglas Gregor via swift-evolution > <swift-evolution@swift.org <ma

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0091: Improving operator requirements in protocols

Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0091-improving-operators-in-protocols.md Hi all, > On May 17, 2016, at 8:33 PM, Chris Lattner

Re: [swift-evolution] Enhanced existential types proposal discussion

> On Jun 8, 2016, at 11:57 AM, Dave Abrahams via swift-evolution > wrote: > > > on Sun Jun 05 2016, Douglas Gregor > wrote: > >> Sent from my iPhone >> >>> On Jun 5, 2016, at 6:41 PM, Matthew Johnson

Re: [swift-evolution] [Proposal] Conditional Conformance on Protocols/Generic Types

> On Jun 8, 2016, at 11:52 AM, Thorsten Seitz wrote: > >> >> Am 07.06.2016 um 07:55 schrieb LM > >: >> >> >> >> On Jun 7, 2016, at 7:14 AM, Douglas Gregor >

Re: [swift-evolution] [Proposal] Conditional Conformance on Protocols/Generic Types

> On Jun 6, 2016, at 10:08 PM, Thorsten Seitz wrote: > > > > Am 06.06.2016 um 22:13 schrieb L Mihalkovic >: > >> >>> On Jun 6, 2016, at 9:34 PM, Douglas Gregor >>

Re: [swift-evolution] [Pitch] Allow sub-protocols to define typealiases for protocols' associatedtypes

> On Jun 6, 2016, at 1:59 PM, Ross O'Brien via swift-evolution > wrote: > > Given a protocol with an associated type: > > protocol Foo > { > associatedtype Bar > } > > it should be possible to define a protocol conforming to Foo, for which Bar > can be

Re: [swift-evolution] [Proposal] Conditional Conformance on Protocols/Generic Types

> On Jun 6, 2016, at 12:37 PM, L Mihalkovic > wrote: > >> >> On Jun 6, 2016, at 6:51 PM, Douglas Gregor > > wrote: >> >>> >>> On Jun 5, 2016, at 3:24 AM, L. Mihalkovic via swift-evolution >>>

Re: [swift-evolution] [Proposal] Conditional Conformance on Protocols/Generic Types

> On Jun 6, 2016, at 12:12 PM, Thorsten Seitz wrote: > > > > Am 06.06.2016 um 18:51 schrieb Douglas Gregor >: > >> >>> On Jun 5, 2016, at 3:24 AM, L. Mihalkovic via swift-evolution >>>

Re: [swift-evolution] [Proposal] Conditional Conformance on Protocols/Generic Types

> On Jun 5, 2016, at 3:24 AM, L. Mihalkovic via swift-evolution > wrote: > > The issue is to decide on the applicability scope. Thinking 'my app/their > stuff' is an illusion. To the compiler & runtime there is only code split > into modules, some in source code

Re: [swift-evolution] Enhanced existential types proposal discussion

> On Jun 5, 2016, at 11:27 PM, L. Mihalkovic <laurent.mihalko...@gmail.com> > wrote: > > > > > Regards > (From mobile) > On Jun 6, 2016, at 1:20 AM, Douglas Gregor via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org&

Re: [swift-evolution] Enhanced existential types proposal discussion

Sent from my iPhone > On Jun 5, 2016, at 7:02 PM, Austin Zheng wrote: > > Thank you for your feedback, Doug! I appreciate you taking the time to read > through everything and write up your thoughts. I'll revise the proposal and > plan for a 2017 time frame. It should

Re: [swift-evolution] Enhanced existential types proposal discussion

Sent from my iPhone > On Jun 5, 2016, at 6:41 PM, Matthew Johnson wrote: > > > > Sent from my iPad > >> On Jun 5, 2016, at 6:20 PM, Douglas Gregor wrote: >> >> >>> On May 18, 2016, at 12:35 AM, Austin Zheng wrote: >>>

Re: [swift-evolution] Enhanced existential types proposal discussion

> On May 18, 2016, at 12:35 AM, Austin Zheng wrote: > > I've put together a considerably more detailed draft proposal, taking into > account as much of Matthew's feedback as I could. You can find it below: > >

Re: [swift-evolution] Variadic generics discussion

> On May 31, 2016, at 12:56 PM, Austin Zheng via swift-evolution > wrote: > > This is pretty much where my thinking about the topic has led me as well. > I'll resign this topic to pursue some other, hopefully more relevant work, > although anyone who wants to

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0083: Remove bridging conversion behavior from dynamic casts

> On May 23, 2016, at 5:26 PM, Jordan Rose via swift-evolution > wrote: > > I am way late, but I share Brent’s concerns. I don’t think this addresses the > very common case of “getting a String out of a heterogeneous dictionary”. > > let name = plist[“name”] as!

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

> On May 17, 2016, at 10:40 AM, Adrian Zubarev > wrote: > >> You don’t seem to be tackling the case of “A Collection whose Element type >> is String”. If we’re generalizing the current “protocol<>” notion, why not >> make it as powerful as a generic

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

> On May 17, 2016, at 6:43 AM, Adrian Zubarev via swift-evolution > wrote: > > So basically everyone start to like by the core team suggested `Any<>` name > of the proposed mechanism. I’ll rename it when I get home. ;) Definitely happy to see this proposal being

Re: [swift-evolution] Referencing zero-parameter functions

> On May 6, 2016, at 12:34 AM, Alex Hoppen via swift-evolution > wrote: > > Thanks for your feedback so far. Based on the discussion, I have updated the > proposal to let `foo` refer to the zero-parameter function instead of > `foo(_)`. > > The updated proposal is

[swift-evolution] [Pitch] Align @objc inference with the semantic model

Hi all, Right now, Swift infers @objc (meaning that you don’t have to write it explicitly) in a number of places: 1) When overriding an @objc declaration 2) When implementing a requirement of an @objc protocol (note: this behavior was recently enabled in the Swift compiler) 3) When the

<    1   2   3   4   5   >