Re: [swift-evolution] [proposal] Allow function argument type to be omitted when passing a default value from which it can be inferred

Sent from my iPhone > On May 10, 2016, at 8:33 PM, Chris Lattner via swift-evolution > wrote: > >> On May 10, 2016, at 3:02 AM, Sam Dods via swift-evolution >> wrote: >> I propose that function argument types could be omitted in the

Re: [swift-evolution] [Review] SE-0081: Move where clause to end of declaration

> On May 10, 2016, at 3:46 PM, Jordan Rose via swift-evolution > wrote: > > I think actual keyword “where” provides enough of a delimiter that it won’t > be hard to put something before it, and it seems unlikely to me that we would > want to add anything after it

Re: [swift-evolution] NSRange and Range

Sent from my iPhone > On May 10, 2016, at 12:14 AM, David Hart wrote: > > But it’s reasonably implementable? I guess the answer is yes if you have > already faced the same bridging concerns with NSArray/Array. I’de really like > this going forward, but I don’t know how

Re: [swift-evolution] NSRange and Range

> On May 9, 2016, at 11:23 PM, David Hart wrote: > > Why wouldn't it completely eliminate NSRange? Because NSRange has a different representation than Range (start+length vs. start/end), a pointer-to-NSRange has to come in as Unsafe(Mutable)Pointer rather than

Re: [swift-evolution] Move where clause to end of declaration

> On May 2, 2016, at 12:16 AM, David Hart via swift-evolution > wrote: > > Hello swift-evolution, > > I took the pitch originally from Developer to move the where clause out of > the generic parameter list, with improvements brought up by Pyry Jahkola, and > wrote

Re: [swift-evolution] NSRange and Range

> On May 8, 2016, at 2:10 PM, David Hart via swift-evolution > wrote: > > Hello Swift-Evolution, > > I spent some time coding on Linux with Swift 3 (latest developement snapshot) > and corelibs-foundation and I’ve hit one major hurdle: passing and converting >

[swift-evolution] [Review] SE-0086: Drop NS Prefix in Swift Foundation

Hello Swift community, The review of SE-0086 "Drop NS Prefix in Swift Foundation" begins now and runs through May 16, 2016. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0086-drop-foundation-ns.md Reviews are an important part of the Swift

[swift-evolution] [Accepted] SE-0066: Standardize function type argument syntax to require parentheses

Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0066-standardize-function-type-syntax.md Hello Swift community, The review of SE-0066 “Standardize function type argument syntax to require parentheses” ran from April 25...May 2, 2016. The proposal is accepted for

Re: [swift-evolution] [Proposal] More Powerful Constraints for Associated Types

Sent from my iPhone > On May 2, 2016, at 3:50 PM, David Hart wrote: > > Hi Doug, > > In the latest version of the proposal, which is now linked to a pull request, > I mentioned in the Detail Design section that the following syntax be valid: > > protocol R : Q where

Re: [swift-evolution] [Manifesto] Completing Generics

nstraints) would require a proposal. - Doug > >> On 03 Mar 2016, at 02:22, Douglas Gregor via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> Hi all, >> >> Introduction >> >> The “Complete Generics” goal for Swift 3

Re: [swift-evolution] [Pitch] Allow nested protocol declarations

> On Apr 28, 2016, at 10:15 AM, Brad Hilton via swift-evolution > wrote: > > Type nesting allows some convenient and straightforward semantics that we see > inside the Swift standard library such as views on String like > String.CharacterView,

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

> On Apr 27, 2016, at 12:45 PM, L. Mihalkovic > wrote: > > Inline > > Regards > (From mobile) > > On Apr 27, 2016, at 9:31 PM, Erica Sadun via swift-evolution > > wrote: > >> On Apr 27, 2016, at

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

> On Apr 27, 2016, at 12:31 PM, Erica Sadun wrote: > > On Apr 27, 2016, at 12:25 PM, Douglas Gregor > wrote: >> >> On Apr 27, 2016, at 10:10 AM, Erica Sadun > > wrote: >>>

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

> On Apr 27, 2016, at 10:10 AM, Erica Sadun wrote: > > From the Swift Programming Language: Methods on a subclass that override the > superclass’s implementation are marked with override—overriding a method by > accident, without override, is detected by the compiler as

Re: [swift-evolution] [Review] SE-0070: Make Optional Requirements Objective-C only

> On Apr 26, 2016, at 3:33 AM, James Froggatt wrote: > > Fair enough. Upon reflection, I think my real issue is somewhat different to > what I suggested previously. > > I wasn't intending to suggest such a thing would be practical, just that it > would be a decent

Re: [swift-evolution] [Proposal] More Powerful Constraints for Associated Types

Sent from my iPhone On Apr 25, 2016, at 10:03 PM, Brent Royal-Gordon wrote: >> Note that, if we do the above, I’d love to make it an error to define a new >> associated type with the same name as an associated type in an inherited >> protocol. It’s odd that we do so,

Re: [swift-evolution] Mutability for Foundation types in Swift

> On Apr 25, 2016, at 8:39 PM, Russ Bishop via swift-evolution > wrote: > > There aren’t enough +1s in the world for this, I fully endorse your proposal > and would like to subscribe to your newsletter ;) > > Do you envision the apinotes will be the vehicle for

Re: [swift-evolution] [swift-dev] RFC: "Near-miss" checking for defaulted protocol requirements

> On Apr 25, 2016, at 1:13 PM, Erica Sadun wrote: > > With apologies, I do not see near miss checks as a pressing need: > > * Quick Help lists of required members (including associated types and > inherited members) would be far more valuable to me than "near miss" >

Re: [swift-evolution] [Review] SE-0070: Make Optional Requirements Objective-C only

Sent from my iPhone > On Apr 25, 2016, at 12:37 PM, Joe Groff wrote: > > I support the approach of making optional requirements ObjC-only. As a > nitpick, it feels "wrong" to me to keep a decl modifier around for something > that's only a compatibility feature and not

Re: [swift-evolution] [Proposal draft] Make Optional Requirements Objective-C-only

> On Apr 25, 2016, at 10:13 AM, Erica Sadun wrote: > > >> On Apr 25, 2016, at 10:49 AM, Douglas Gregor > > wrote: >>> * Swift already has an `Optional` type. Importing ObjC "optional" protocol >>> requirements is therefore

Re: [swift-evolution] Rewrite imported C function signatures

> On Apr 24, 2016, at 3:45 PM, Carlos Rodríguez Domínguez > wrote: > > Thanks for the explanation, which makes me think that it should be suitable, > as you comment, to promote API notes to a “first class” transition technology. > > As a first approach towards that

Re: [swift-evolution] [Proposal draft] Make Optional Requirements Objective-C-only

> On Apr 24, 2016, at 7:02 PM, Erica Sadun <er...@ericasadun.com> wrote: > > >> On Apr 24, 2016, at 3:28 PM, Chris Lattner via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> >>> On

Re: [swift-evolution] Mutability for Foundation types in Swift

> On Apr 25, 2016, at 9:20 AM, Tony Parker via swift-evolution > wrote: > > Hi Brent, > > Thanks for your feedback! You’ve got some great questions below, I’ll try to > answer them as best I can. > >> On Apr 24, 2016, at 3:44 AM, Brent Royal-Gordon

Re: [swift-evolution] [Proposal draft] Make Optional Requirements Objective-C-only

ly. Why not emphasize the Obj-C > compatibility angle by requiring the `@objc` attribute to precede each > use of `optional`? (In other words, effectively rename `optional` to > `@objc optional`.) That is a great idea. > > > On Fri, Apr 22, 2016 at 7:35 PM, Douglas Gregor via swift

[swift-evolution] [Proposal draft] Make Optional Requirements Objective-C-only

Proposal link: https://github.com/DougGregor/swift-evolution/blob/objc-optional/proposals/-optional-requirements.md After a whole lot of discussion and thrashing on optional requirements, I have a draft for a modest proposal: change the ‘optional’ keyword to something that indicates that

Re: [swift-evolution] [META] Fast Track Reviews

> On Apr 18, 2016, at 7:39 PM, Douglas Gregor via swift-evolution > <swift-evolution@swift.org> wrote: > > > > Sent from my iPhone > > On Apr 18, 2016, at 8:56 AM, Erica Sadun via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@sw

[swift-evolution] [Rejected] SE-0056: Allow trailing closures in `guard` conditions

Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0056-trailing-closures-in-guard.md Hello Swift community, The review of SE-0056 "Allow trailing closures in `guard` conditions” ran from March 31...April 5, 2016. The proposal is rejected. The core team felt that the

Re: [swift-evolution] [Accepted] SE-0059: Update API Naming Guidelines and Rewrite Set APIs Accordingly

r us to warn on this kind of example, e.g., placing a Void result of a call to a mutating method in a variable. Can you file a ticket a bugs.swift.org? It would be a great starter bug. - Doug > > On 19.04.2016 0:18, Douglas Gregor via swift-evolution wrote: >> >> Propo

Re: [swift-evolution] [Pitch] Extend Any.Type to allow construction of bound generic types

Sent from my iPhone > On Apr 20, 2016, at 8:36 AM, Joanna Carter > wrote: > > Hi Doug > >> In programming-language circles, this feature is called “dependent types” >> (see, e.g., https://en.wikipedia.org/wiki/Dependent_type), and it introduces >>

Re: [swift-evolution] [Accepted] SE-0064: Referencing the Objective-C selector of property getters and setters

Sent from my iPhone On Apr 18, 2016, at 4:11 PM, Robert Schwalbe via swift-evolution wrote: >> Hello Robert, >> >> My comment below: >> >>> Per my reading of SE-0022, would SE-0064 institute the first exception to >>> the #selector expression where the

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

> On Apr 15, 2016, at 5:24 PM, Brent Royal-Gordon > wrote: > >> That’s the other part of my argument: if it is true that Swift code only >> needs to conform to ObjC protocols with optional requirements, but Swift >> code does not need to invoke optional requirements

[swift-evolution] [Accepted] SE-0059: Update API Naming Guidelines and Rewrite Set APIs Accordingly

Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0059-updated-set-apis.md Hello Swift Community, The review of SE-0059 "Update API Naming Guidelines and Rewrite Set APIs Accordingly” ran from March 31...April 5, 2016. The proposal is accepted. There was much

Re: [swift-evolution] [Accepted] SE-0048: Generic Type Aliases

> On Apr 16, 2016, at 4:12 PM, Chris Lattner wrote: > > >> On Apr 16, 2016, at 1:12 AM, Nicola Salmoria via swift-evolution >> wrote: >> >>> Proposal link: >>>

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

;>>>> On Apr 13, 2016, at 11:42 AM, Douglas Gregor <dgre...@apple.com >>>>>> <mailto:dgre...@apple.com>> wrote: >>>>>> >>>>>>> >>>>>>> On Apr 11, 2016, at 10:30 AM, Matthew Johnson <matt...@anandab

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

>>>> >>>>> >>>>> On Apr 11, 2016, at 10:30 AM, Matthew Johnson <matt...@anandabits.com >>>>> <mailto:matt...@anandabits.com>> wrote: >>>>> >>>>> >>>>> >>>>> Sent fro

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

0 AM, Matthew Johnson <matt...@anandabits.com >>> <mailto:matt...@anandabits.com>> wrote: >>> >>> >>> >>> Sent from my iPad >>> >>>> On Apr 11, 2016, at 12:15 PM, Joe Groff via swift-evolution >>>> <swift-e

[swift-evolution] [Accepted] SE-0064: Referencing the Objective-C selector of property getters and setters

Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0064-property-selectors.md Hello Swift Community, The review of SE-0064 "Referencing the Objective-C selector of property getters and setters” ran from April 7...12, 2016. The proposal is accepted. Feedback was

[swift-evolution] [Accepted] SE-0062: Referencing Objective-C key-paths

Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0062-objc-keypaths.md Hello Swift Community, The review of SE-0062 "Referencing Objective-C key-paths” ran from April 7...12, 2016. The proposal is accepted, with one adjustment to the handling of collections:

[swift-evolution] [Accepted] SE-0036: Requiring Leading Dot Prefixes for Enum Instance Member Implementations

Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0036-enum-dot.md Hello Swift Community, The review of SE-0036 "Requiring Leading Dot Prefixes for Enum Instance Member Implementations” ran from March 31...April 5, 2016. The proposal is accepted for Swift 3. We

[swift-evolution] [Accepted] SE-0049: Move @noescape and @autoclosure to be type attributes

Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0049-noescape-autoclosure-type-attrs.md Hello Swift Community, The review of SE-0049 "Move @noescape and @autoclosure to be type attributes” ran from March 28...31, 2016. The proposal is accepted for Swift 3.

[swift-evolution] [Accepted] SE-0048: Generic Type Aliases

Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0048-generic-typealias.md The review of SE-0048 “Generic Type aliases” ran from March 24…29, 2016. The proposal received overwhelmingly positive feedback and has now been implemented for Swift 3. - Doug

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

> On Apr 11, 2016, at 10:30 AM, Matthew Johnson <matt...@anandabits.com> wrote: > > > > Sent from my iPad > >> On Apr 11, 2016, at 12:15 PM, Joe Groff via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> >>>

Re: [swift-evolution] [Completing Generics] Arbitrary requirements in protocols

> On Apr 12, 2016, at 11:23 PM, David Hart via swift-evolution > wrote: > > I wouldn't mind driving the discussion and proposal, because I'd really like > to see a more complete generics system. Before I start, can David or Doug, or > someone else with a high-level

Re: [swift-evolution] [Completing Generics] Arbitrary requirements in protocols

tocol Collection : Sequence { func foo() // is the following where clause part of foo() or part of Collection? where SubSequence : Collection } - Doug > > David > > On 12 Apr 2016, at 19:07, Douglas Gregor via swift-evolution > <swift-evolutio

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

> On Apr 11, 2016, at 10:15 AM, Joe Groff <jgr...@apple.com> wrote: > > >> On Apr 7, 2016, at 5:12 PM, Douglas Gregor via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> One could perhaps work around (a), (b), and (d) by allowing comp

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

and what I’ve said above about compatibility with Cocoa, do you still think we need to keep ‘@objc optional’ as a notion in the language? - Doug > > -Shawn > > On Thu, Apr 7, 2016 at 5:12 PM Douglas Gregor via swift-evolution > <swift-evolution@swift.org

Re: [swift-evolution] [Completing Generics] Arbitrary requirements in protocols

> On Apr 11, 2016, at 1:01 AM, Jacob Bandes-Storch via swift-evolution > wrote: > > Doug wrote this in the Completing Generics manifesto, under "Minor > extensions": > > *Arbitrary requirements in protocols > > Currently, a new protocol can inherit from other

Re: [swift-evolution] SE-0062 Referencing Objective-C key-paths

> On Apr 7, 2016, at 9:34 PM, Les Pruszynski via swift-evolution > wrote: > > This is my first post on this list so please bear with me. > > I very much like this proposal but what bothers me is this doubling of > valueForKeyPath(#keyPath(xxx) in the signature of

[swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

Hi all, Optional protocol requirements in Swift have the restriction that they only work in @objc protocols, a topic that’s come up a number of times

[swift-evolution] [Review] SE-0064: Referencing the Objective-C selector of property getters and setters

Hello Swift community, The review of SE-0064 "Referencing the Objective-C selector of property getters and setters" begins now and runs through April 12, 2016. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0064-property-selectors.md Reviews are

[swift-evolution] [Review] SE-0062: Referencing Objective-C key-paths

Hello Swift community, The review of SE-0062 “Referencing Objective-C key-paths" begins now and runs through April 12, 2016. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0062-objc-keypaths.md Reviews are an important part of the Swift evolution

Re: [swift-evolution] deployment targets and frameworks

> On Apr 5, 2016, at 4:04 PM, Drew Crawford wrote: > > >> On Apr 5, 2016, at 12:06 PM, Douglas Gregor > > wrote: >> >> I would not want this to be implicit behavior: it should be recorded in the >> source with, e.g., >>

Re: [swift-evolution] [Review] SE-0058: Allow Swift types to provide custom Objective-C representations

> On Apr 5, 2016, at 11:36 AM, Russ Bishop wrote: > > >> On Apr 5, 2016, at 10:14 AM, Douglas Gregor > > wrote: >>> Suppose there is also a subclass (say, ObjCMutableFizzer), and we have this Objective-C API:

Re: [swift-evolution] [Review] SE-0058: Allow Swift types to provide custom Objective-C representations

> On Apr 4, 2016, at 9:54 PM, Russ Bishop via swift-evolution > wrote: > >> >> On Apr 4, 2016, at 9:22 PM, Brent Royal-Gordon via swift-evolution >> wrote: >> >>> >>>

Re: [swift-evolution] deployment targets and frameworks

> On Apr 4, 2016, at 4:48 PM, Drew Crawford via swift-evolution > wrote: > > Suppose *Apple* ships a framework that is only supported in iOS 9.3. As a > direct consequence, the framework is only #available in iOS 9.3 or later. > > Suppose Jane links this framework

Re: [swift-evolution] SE-0025: Scoped Access Level (DECISION)

> On Apr 4, 2016, at 7:54 AM, Ilya Belenkiy wrote: > > Just to double check: do I need to do anything with the proposal? It sounds > like it was decided, and Doug will update the proposal, but I 'd like to make > sure that there is nothing to be done on my end. I’ll

Re: [swift-evolution] [Review] SE-0059: Update API Naming Guidelines and Rewrite Set APIs Accordingly

the IEDs are not taking the place of the insurgents. I was going to comment about your choice of a terrorism-related example sentence, but the online OED *only* uses war-related examples for this verb. - Doug > > On Mon, Apr 4, 2016 at 11:14 AM, Douglas Gregor via swift-evolution >

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

> On Apr 1, 2016, at 5:37 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> Protocol requirements with default (no-op) implementations already satisfy >> that design goal, no? > > Kind of. If I may steelman* optional members for a moment... > > In cases

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

> On Apr 3, 2016, at 10:21 PM, Thorsten Seitz via swift-evolution > wrote: > > As the problem seems to be to eliminate having to write the extension with > all its duplication, I'd prefer a more general solution instead of > introducing the notion of an "optional"

Re: [swift-evolution] [Review] SE-0059: Update API Naming Guidelines and Rewrite Set APIs Accordingly

> On Apr 3, 2016, at 1:56 PM, Shawn Erickson wrote: > > > > On Sun, Apr 3, 2016 at 1:27 PM Shawn Erickson > wrote: > On Sun, Apr 3, 2016 at 6:41 AM Michel Fortin via swift-evolution >

Re: [swift-evolution] [Review] SE-0057: Importing Objective-C Lightweight Generics

> On Mar 31, 2016, at 2:40 PM, Andrew Bennett via swift-evolution > wrote: > > A few quick questions: > > * Is there a swift-evolution discussion thread? It's marked as TODO > currently. Thanks for catching that. The thread is here:

[swift-evolution] [Review] SE-0059: Update API Naming Guidelines and Rewrite Set APIs Accordingly

Hello Swift community, The review of SE-0059 "Update API Naming Guidelines and Rewrite Set APIs Accordingly" begins now and runs through April 5, 2016. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0059-updated-set-apis.md Reviews are an

[swift-evolution] [Review] SE-0056: Allow trailing closures in `guard` conditions

Hello Swift community, The review of SE-0056 "Allow trailing closures in `guard` conditions" begins now and runs through April 5, 2016. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0056-trailing-closures-in-guard.md Reviews are an important part

Re: [swift-evolution] Rewrite imported C function signatures

> On Mar 29, 2016, at 3:02 AM, Carlos Rodríguez Domínguez > wrote: > > Well, those proposal are more oriented towards annotating on C/Objective-C > files to allow a more sophisticate import into swift. Yes, that is true. The philosophy behind these is that it’s

[swift-evolution] [Review] SE-0049 Move @noescape and @autoclosure to be type attributes

Hello Swift community, The review of SE-0049 "Move @noescape and @autoclosure to be type attributes" begins now and runs through March 31, 2016. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0049-noescape-autoclosure-type-attrs.md Reviews are an

Re: [swift-evolution] Rewrite imported C function signatures

> On Mar 25, 2016, at 3:25 AM, Carlos Rodríguez Domínguez via swift-evolution > wrote: > > (Please, take a look at the proposal named "[swift-evolution] Promote > "primitive" types to enums in extensions” in order to understand the > intention of my proposal as a

Re: [swift-evolution] [Idea] ObjectiveCBridgeable

> On Mar 24, 2016, at 12:39 AM, Russ Bishop wrote: > > >>> I added a separate section on Ambiguity and what the behavior is. I think >>> you should be able to resolve ambiguity by casting so I went ahead and put >>> that in. An example: >>> >>> //Bar and Foo bridge to

[swift-evolution] [Review] SE-0048: Generic Type Aliases

Hello Swift community, The review of SE-0048 "Generic Type Aliases" begins now and runs through March 29, 2016. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0048-generic-typealias.md Reviews are an important part of the Swift evolution process.

Re: [swift-evolution] [Idea] ObjectiveCBridgeable

> On Mar 23, 2016, at 1:25 PM, Russ Bishop wrote: > > >> On Mar 23, 2016, at 11:49 AM, Douglas Gregor > > wrote: >>> >>> I assume this is a static function to avoid allocating memory by calling >>> the initializer directly for

[swift-evolution] [Accepted] SE-0044: Import as member

Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0044-import-as-member.md The review of SE-0044 “Import as member” ran from March 15...22, 2016. The proposal has been

Re: [swift-evolution] [Idea] ObjectiveCBridgeable

> On Mar 23, 2016, at 12:21 AM, Russ Bishop wrote: > >> >> On Mar 21, 2016, at 9:41 AM, Douglas Gregor > > wrote: >> >> >>> On Mar 9, 2016, at 12:26 PM, Russ Bishop via swift-evolution >>>

Re: [swift-evolution] #selector and Void methods

> On Mar 23, 2016, at 10:14 AM, Jordan Rose via swift-evolution > wrote: > >> >> On Mar 23, 2016, at 10:11, Joe Groff via swift-evolution >> > wrote: >> >>> >>> On Mar 22, 2016, at 8:49 PM, Brent

Re: [swift-evolution] Notes from Swift core team 2016-03-15 design discussion

> On Mar 16, 2016, at 5:27 PM, Alex Martini via swift-evolution > wrote: > > To help keep proposals moving forward, the Swift core team has set aside some > time specifically for design discussions of upcoming proposals. Below are > some rough notes from the

Re: [swift-evolution] [Idea] ObjectiveCBridgeable

> On Mar 9, 2016, at 12:26 PM, Russ Bishop via swift-evolution > wrote: > > An official proposal PR has been opened on this: > https://github.com/apple/swift-evolution/pull/198 > > > It includes clarifications, a

Re: [swift-evolution] Removing explicit use of `let` from Function Parameters

tion of this. >>> >>> I would like to write up a quick proposal today if its ok. >>> >>> Chris, I promise to make it very concise is it ok to send over a PR to >>> swift evolution? >>> >>> - Nick >>> >>> 2016年3

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0044 Import as Member

> On Mar 16, 2016, at 4:48 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> • What is your evaluation of the proposal? > > Overall in favor. > > I don't like the getter syntax: > > float Point3DGetRadius(Point3D point) >

Re: [swift-evolution] Removing explicit use of `let` from Function Parameters

x that. > be allowed, such that it’ll be called as this: > > foo(let: 3) Right. - Doug > > — Harlan > >> On Mar 17, 2016, at 11:08 AM, Douglas Gregor via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: &

[swift-evolution] [Review] SE-0044 Import as Member

Hello Swift community, The review of SE-0044 “Import as Member" begins now and runs through March 22, 2016. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0044-import-as-member.md

Re: [swift-evolution] [Rejected] SE-0009 Require self for accessing instance members

> On Jan 6, 2016, at 6:56 AM, Greg Parker via swift-evolution > wrote: > > >> On Jan 6, 2016, at 6:17 AM, Honza Dvorsky via swift-evolution >> wrote: >> >> I remember this being discussed in the conversation about this proposal and >>

Re: [swift-evolution] STDLibs

> On Jan 6, 2016, at 11:06 AM, James Campbell via swift-evolution > wrote: > > I did but it redirects elsewhere now :S It’s “swiftdoc.org”, not “swiftdocs.org” as in the link. - Doug > > On Wed, Jan 6, 2016 at 6:50 PM, Erica Sadun

[swift-evolution] [Review] SE-0010 Add StaticString.UnicodeScalarView

Hello Swift community, The review of SE-0010 "Add StaticString.UnicodeScalarView" begins now and runs through Friday, January 8th. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0010-add-staticstring-unicodescalarview.md Reviews are an

Re: [swift-evolution] [Mini-proposal] Require @nonobjc on members of @objc protocol extensions

that people write a protocol extension of a delegate that implements some of its optional members. The only calls to that method occur in some framework code written in Objective-C, so there place for the compiler to tell you it’s not there. - Doug > > A. > > > >&

Re: [swift-evolution] [Mini-proposal] Require @nonobjc on members of @objc protocol extensions

> On Jan 5, 2016, at 5:41 AM, Charles Srstka <cocoa...@charlessoft.com> wrote: > >> On Jan 4, 2016, at 10:32 PM, Douglas Gregor via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> There is no

[swift-evolution] [Accepted] SE-0014 Constraining `AnySequence.init`

The review of SE-0014 "Constraining `AnySequence.init`" ran from December 18–21, 2015. The proposal has been accepted for Swift 2.2. https://github.com/apple/swift-evolution/blob/master/proposals/0014-constrained-AnySequence.md Thank you to everyone who participated in the review

[swift-evolution] [Rejected] SE-0009 Require self for accessing instance members

The review of SE-0009 "Require self for accessing instance members`" ran from December 16–20, 2015. The proposal has been rejected. https://github.com/apple/swift-evolution/blob/master/proposals/0009-require-self-for-accessing-instance-members.md

Re: [swift-evolution] [Mini-proposal] Require @nonobjc on members of @objc protocol extensions

s over >> only doing this on each method, if extensions cannot already be modified >> with attributes. I can’t think of a case where I’ve seen annotations added >> to protocol extensions, or any other extensions for that matter. >> >> >>> On Jan 4, 2016, at 11:32 PM

Re: [swift-evolution] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

vement on its own, which then opens the door to additional features (real typealiases in protocols or protocol extensions). - Doug > >> On Jan 3, 2016, at 1:38 AM, Douglas Gregor via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org

[swift-evolution] [Mini-proposal] Require @nonobjc on members of @objc protocol extensions

Hi all, We currently have a bit of a surprise when one extends an @objc protocol: @objc protocol P { } extension P { func bar() { } } class C : NSObject { } let c = C() print(c.respondsToSelector("bar")) // prints "false" because the members of the extension are not exposed to the

Re: [swift-evolution] [Mini-proposal] Require @nonobjc on members of @objc protocol extensions

t; > Félix > >> Le 4 janv. 2016 à 23:32:25, Douglas Gregor via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit : >> >> Hi all, >> >> We currently have a bit of a surprise when one extends

Re: [swift-evolution] [Proposal] Separate protocols and interfaces

> On Jan 4, 2016, at 6:24 AM, Matthew Johnson via swift-evolution > wrote: > >> >> On Jan 3, 2016, at 10:44 PM, Matthew Johnson > > wrote: >> >> >>> On Jan 3, 2016, at 9:14 PM, Drew Crawford

Re: [swift-evolution] [Proposal] Separate protocols and interfaces

> On Jan 4, 2016, at 9:54 AM, Matthew Johnson wrote: > >> >> On Jan 4, 2016, at 11:43 AM, Douglas Gregor > > wrote: >> >>> >>> On Jan 4, 2016, at 6:24 AM, Matthew Johnson via swift-evolution >>>

Re: [swift-evolution] [Proposal] Separate protocols and interfaces

t 3 schedule. It’s also a case where the compiler has a lot of the pieces already implemented (with some runtime bits landing soon), so the implementation should not be *that* hard and will likely not require architectural changes. - Doug > > -DW > >> On Jan 3, 201

Re: [swift-evolution] [Proposal] Separate protocols and interfaces

> On Jan 3, 2016, at 6:48 AM, Антон Жилин via swift-evolution > wrote: > > Introduction of interfaces will clean up the current blend of static and > dynamic protocols, and solve at least three popular issues. > Please see: >

[swift-evolution] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

Hello Swift community, The review of "Replace `typealias` keyword with `associatedtype` for associated type declarations” begins now and runs through Wednesday, January 6th. The proposal is available here:

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

>> On Dec 27, 2015, at 10:37 AM, Joe Groff <jgr...@apple.com> wrote: >> >> >> On Dec 26, 2015, at 11:22 PM, Douglas Gregor via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> Hi all, >> >> Here’s a proposal dra

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

Sent from my iPhone > On Dec 29, 2015, at 11:03 AM, Douglas Gregor via swift-evolution > <swift-evolution@swift.org> wrote: > > > > Sent from my iPhone > >> On Dec 29, 2015, at 10:17 AM, Joe Groff <jgr...@apple.com> wrote: >> >> We

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

15 à 14:10:51, Erica Sadun via swift-evolution >> <swift-evolution@swift.org> a écrit : >> >> Talk about things you didn't know you needed until you see them. This is a >> really nice way of disambiguating! >> >> -- E >> >>> On Dec 29

Re: [swift-evolution] [Idea] Expression to retrieve the Objective-C selector of a method

hat's the nature of overriding. But objective-c allows one to use a selector with an unrelated class, which can certainly be confusing. I feel like that comes from the runtime itself, and isn't something we can avoid with any syntax we pick. > Jacob Bandes-Storch > >> On Sat, Dec

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

Sent from my iPhone > On Dec 27, 2015, at 8:34 PM, Chris Lattner via swift-evolution > wrote: > > >>> On Dec 27, 2015, at 4:27 PM, John McCall wrote: >>> >>> On Dec 27, 2015, at 4:15 PM, Chris Lattner wrote: >>> >>> On

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

ses (#set, contextual type disambiguation, etc)… which seems inconsistent to me. - Doug > On Dec 26, 2015, at 11:22 PM, Douglas Gregor via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >> Hi all, >> >&g

<    1   2   3   4   5   >