Re: [swift-evolution] ExpressibleByStringInterpolation

I like the proposal so far and would be happy seeing this in 4.1, even. ;) I don’t know/remember the conditions under which the previous implementation was deemed unsuitable, but this addresses most of my personal qualms with it. My primary interests in an interpolation align with yours: in

[swift-evolution] [Proposal] Synthesizing Equatable/Hashable conformance for enums and structs

Now that Swift 5 is taking proposals, I'm dusting off my proposal to synthesize Equatable/Hashable conformance for enums and structs. I had implemented this a few months ago hoping to squeeze it in by the Swift 4 deadline, but unfortunately the timeline was too tight. The pull request for the

Re: [swift-evolution] How does "Sequence.joined" work?

On Wed, Aug 9, 2017 at 10:43 AM, Daryle Walker via swift-evolution < swift-evolution@swift.org> wrote: > > On Aug 8, 2017, at 6:45 PM, Geordie Jay wrote: > > > Daryle Walker via swift-evolution schrieb am > Di. 8. Aug. 2017 um 21:25: > >> On Aug 8,

Re: [swift-evolution] Enums and Source Compatibility

Sent from my iPad > On Aug 9, 2017, at 12:15 PM, Tony Allevato via swift-evolution > wrote: > >> On Wed, Aug 9, 2017 at 9:40 AM David Sweeris via swift-evolution >> wrote: >> (Now with more mailing lists in the "to" field!) >>> On Aug

Re: [swift-evolution] [discussion] What generics feature would this be?

A existential type of some protocol `P`, counterintuitively, doesn't conform to itself, unless it's an Objective-C protocol. Because `S : Special` means S has to be a type that conforms to the protocol `Special`, and `special` is of the existential type `Special`, the existential type

Re: [swift-evolution] [discussion] Class stored properties?

I don't follow. What's a singleton/how? If you mean my example, the whole point/need for the feature is so it's not. I want `.value` to be unique storage for each subclass. On Wed, Aug 9, 2017 at 7:09 PM, Robert Widmann wrote: > This is a singleton, it just happens to be in

Re: [swift-evolution] SE-184 Improved Pointers

On Wed, Aug 9, 2017 at 2:34 AM, Andrew Trick wrote: > > On Aug 8, 2017, at 11:10 PM, Taylor Swift wrote: > > > On Wed, Aug 9, 2017 at 1:51 AM, Andrew Trick wrote: > >> >> On Aug 8, 2017, at 8:44 PM, Taylor Swift

Re: [swift-evolution] Enums and Source Compatibility

Sorry if I misunderstood the subject, but shouldn't this also be a *consumer* decision, when one wants to keep own switch exhaustive or it is OK to process all possible future cases in 'default'? If enum is 'closed' - nothing is changed, as I understand, we have the same rules for switch as

Re: [swift-evolution] Enums and Source Compatibility

On Wed, Aug 9, 2017 at 9:40 AM David Sweeris via swift-evolution < swift-evolution@swift.org> wrote: > (Now with more mailing lists in the "to" field!) > On Aug 8, 2017, at 3:27 PM, Jordan Rose via swift-evolution < > swift-evolution@swift.org> wrote: > > Hi, everyone. Now that Swift 5 is

Re: [swift-evolution] [discussion] Class stored properties?

This is a singleton, it just happens to be in class scope. ~Robert Widmann > On Aug 9, 2017, at 3:55 AM, Mathew Huusko V via swift-evolution > wrote: > > Curious if class stored properties have ever been discussed (doesn't seem > so..)? > > Also, assuming no, and

Re: [swift-evolution] Enums and Source Compatibility

> On Aug 8, 2017, at 4:27 PM, Jordan Rose via swift-evolution > wrote: > > Hi, everyone. Now that Swift 5 is starting up, I'd like to circle back to an > issue that's been around for a while: the source compatibility of enums. > Today, it's an error to switch over

Re: [swift-evolution] Enums and Source Compatibility

> On Aug 9, 2017, at 11:04, Matthew Johnson wrote: > >> On Aug 9, 2017, at 12:15 PM, Tony Allevato via swift-evolution >> wrote: >> >>> On Wed, Aug 9, 2017 at 9:40 AM David Sweeris via swift-evolution >>> wrote:

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0185 - Synthesizing Equatable and Hashable conformance

Hi there, I don’t mean to be rude or something, nor do I want to hold the review process up from succeeding, but where is the branch with the implementation? Quote: The proposal phase for Swift 4 is now officially over I hope that the core team does not pick proposals they like, for instance

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0185 - Synthesizing Equatable and Hashable conformance

Well, if there is one, then I apologize for bothering anyone. I just assumed it would be included in the proposal itself, and I couldn't find it myself. ;) Thank you David. -- Adrian Zubarev Sent with Airmail Am 10. August 2017 um 07:30:16, David Hart

Re: [swift-evolution] Enums and Source Compatibility - defaults

> On 10 Aug 2017, at 02:42, Jordan Rose wrote: > > :-) As you've all noted, there are some conflicting concerns for the default: > > - Source compatibility: the existing behavior for an unannotated enum is > "closed". > - Intuition: if you show someone an enum without

Re: [swift-evolution] Enums and Source Compatibility

Hi Jordan, let's say I'm writing my custom number formatter and I switch over NSNumberFormatterStyle (NumberFormatter.Style in Swift) - the question always is what to do with the default case - it's a value that I am not programmatically counting with. I would personally just put in fatalError

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0185 - Synthesizing Equatable and Hashable conformance

> On 10 Aug 2017, at 07:20, Adrian Zubarev via swift-evolution > wrote: > > Hi there, I don’t mean to be rude or something, nor do I want to hold the > review process up from succeeding, but where is the branch with the > implementation? > > Quote: > > The

Re: [swift-evolution] [planning] [discussion] Schedule for return of closure parameter labels (+ world domination ramble)

> If you’re into analogies, I see features like the generics improvements, > concurrency model, ownership system, macro system, ABI stability, new > frameworks, and other large scale efforts as the “bricks" that make up the > house of Swift. In that analogy, smaller proposals are “mortar”

Re: [swift-evolution] Swift 5: start your engines

Would it be possible to get a series of tutorials on how the systems that make up Swift generally work? In other words, what are the pieces and how do they fit together? I think it would be useful even for people who aren’t directly implementing because they can have a better idea of how

Re: [swift-evolution] Swift 5: start your engines

> On Aug 8, 2017, at 3:07 PM, Erica Sadun via swift-evolution > wrote: > > Upfront costs *will* be higher. Not only do you have to believe that a change > is good, you must develop a working group that includes coders to create a > prototype without any guarantee

Re: [swift-evolution] Swift 5: start your engines

Async / await is really spoiling me in Node.JS at the moment, you leave with shiver with anticipation!!! :) Sent from my iPhone > On 9 Aug 2017, at 06:41, Chris Lattner via swift-evolution > wrote: > > >> On Aug 8, 2017, at 8:19 PM, Susan Cheng via swift-evolution

Re: [swift-evolution] [Pitch] range.contains(anotherRange)

2017-08-09 12:50 GMT+09:00 Robert Bennett : It’s a shame that Range can’t be made to conform to SetAlgebra as it lacks the required initializers. Is there anything that can be done about this? Actually, it makes me wonder whether those initializers should even be a part of

Re: [swift-evolution] [swift-users] How does "Sequence.joined" work?

The benefit that standard library containers have over containers from other modules is that they're optimized as if they were part of your own module, so you can get the same thing by including the collection classes in your own executable instead of linking with the module. It's my

Re: [swift-evolution] Swift 5: start your engines

The project would definitely be well-served by having more documentation, and hopefully we’ll see that grow both incrementally and in spurts. Even writing tutorials, however, must be weighed against competing priorities — such as finishing the work for ABI stability. My hope is we can find a

Re: [swift-evolution] Enums and Source Compatibility

Hi Jordan, is that only me or haven't you metioned the default should be applied to all new enums? Personally I'd say that 'closed' should be the default and the 'open' enum would require an extra keyword. Now about the keyword itself. Here are two keywords that IMHO nail their behavior down

Re: [swift-evolution] [Pitch] range.contains(anotherRange)

I am not sure if removing initializers from `SetAlgebra` does not cause any problems in the standard library, it seems reasonable for me if range types could adopt `SetAlgebra`. `SetAlgebra` contains some mutating methods like `insert`, `remove`, `formUnion`. It means it is impossible for range

Re: [swift-evolution] Swift 5: start your engines

> Le 9 août 2017 à 00:06, Erica Sadun via swift-evolution > a écrit : > > >> On Aug 8, 2017, at 3:29 PM, Paul Cantrell via swift-evolution >> > wrote: >> >> Perhaps I am too optimistic, and core team

Re: [swift-evolution] [swift-users] How does "Sequence.joined" work?

On Wed, Aug 9, 2017 at 1:50 AM, Rob Mayoff wrote: > On Tue, Aug 8, 2017 at 11:51 PM, Taylor Swift via swift-users < > swift-us...@swift.org> wrote: > >> >> >> On Wed, Aug 9, 2017 at 12:29 AM, Félix Cloutier via swift-evolution < >> swift-evolution@swift.org> wrote: >> >>> Yes,

Re: [swift-evolution] SE-184 Improved Pointers

On Wed, Aug 9, 2017 at 1:51 AM, Andrew Trick wrote: > > On Aug 8, 2017, at 8:44 PM, Taylor Swift wrote: > > cool,, as for UnsafeMutableRawBufferPointer.copy(from:bytes:), I cannot > find such a function anywhere in the API. There is copyBytes(from:) >

Re: [swift-evolution] SE-184 Improved Pointers

> On Aug 8, 2017, at 11:10 PM, Taylor Swift wrote: > > > On Wed, Aug 9, 2017 at 1:51 AM, Andrew Trick > wrote: > >> On Aug 8, 2017, at 8:44 PM, Taylor Swift > > wrote: >>

Re: [swift-evolution] [swift-users] How does "Sequence.joined" work?

> On 9. Aug 2017, at 06:51, Taylor Swift via swift-users > wrote: > > It’s possible to implement a classic red-black tree in Swift that performs > better than a sorted Array, down to about n = 1,500 items, not n = 100,000 > items as it claims. (Actually, heap

Re: [swift-evolution] Enums and Source Compatibility

> On 9 Aug 2017, at 09:21, Adrian Zubarev via swift-evolution > wrote: > > Hi Jordan, is that only me or haven't you metioned the default should be > applied to all new enums? Personally I'd say that 'closed' should be the > default and the 'open' enum would

[swift-evolution] [discussion] Class stored properties?

Curious if class stored properties have ever been discussed (doesn't seem so..)? Also, assuming no, and assuming there's a good reason no/they're not coming anytime soon, what are some patterns people have been using in their place? I was considering something like.. class SomeClass {

Re: [swift-evolution] [discussion] Class stored properties?

Hi, can you provide a usecase for this? I remember this being used in ObjC for +version, but I'm not sure anymore where I'd use this... BTW you don't need to stringify, use ObjectIdentifier (part of stdlib). > On Aug 9, 2017, at 12:54 PM, Mathew Huusko V via swift-evolution >

[swift-evolution] private extension

Could someone remind please, was it decided to stick with 'private extension' means actually fileprivate access level for members declared in such extension or this could be discussed for Swift5? Currently, when private members are visible in type/extensions of that type in the same file, IMO

Re: [swift-evolution] [discussion] What generics feature would this be?

Very interesting. Is this likely to be changed in the future (either existentials conforming to their protocols, or `S: Protocol` specifically allowing for existentials)? Also, is this at all related? Another instance of at naive/face value something seeming like it should conform, but not..

Re: [swift-evolution] Enums and Source Compatibility

I’d very much in favour of a consistent access modifiers across the whole language and eliminate exclusive `open`. `open/public` protocols are more than welcome. Plus it’s already has been said that Swift will potentially support subtyping for value type in some future, where we’ll yet again

Re: [swift-evolution] Swift 5: start your engines

> On 9 Aug 2017, at 07:29, Jonathan Hull wrote: > > Would it be possible to get a series of tutorials on how the systems that > make up Swift generally work? In other words, what are the pieces and how do > they fit together? Slava Pestov wrote a couple of articles last year:

Re: [swift-evolution] Enums and Source Compatibility

Hi Jordan, Thanks for bringing this topic up again! I’m glad to see it will receive attention in Swift 5. I agree with the semantics of your proposed direction. In terms of syntax, I continue to believe that requiring users to specify a keyword indicating open or closed *in addition* to

Re: [swift-evolution] [swift-users] How does "Sequence.joined" work?

On Wed, Aug 9, 2017 at 5:54 AM, Daniel Vollmer via swift-evolution < swift-evolution@swift.org> wrote: > > > On 9. Aug 2017, at 06:51, Taylor Swift via swift-users < > swift-us...@swift.org> wrote: > > > > It’s possible to implement a classic red-black tree in Swift that > performs better than a

Re: [swift-evolution] Enums and Source Compatibility

(Now with more mailing lists in the "to" field!) > On Aug 8, 2017, at 3:27 PM, Jordan Rose via swift-evolution > wrote: > > Hi, everyone. Now that Swift 5 is starting up, I'd like to circle back to an > issue that's been around for a while: the source compatibility

Re: [swift-evolution] [Proposal] Synthesizing Equatable/Hashable conformance for enums and structs

Hi Tony. I’m really glad to see you’re brining this proposal back right away. It was a shame that it missed the deadline for Swift 4 and will be awesome to have it accepted for Swift 5. > On Aug 9, 2017, at 10:36 AM, Tony Allevato via swift-evolution > wrote: > >

Re: [swift-evolution] [Proposal] Synthesizing Equatable/Hashable conformance for enums and structs

Looks good to me, though I have some clarifying questions. For a type which conforms to both Equatable and Hashable: 1. To automatically derive both Equatable and Hashable, will it be sufficient to declare “struct Foo: Hashable” (since Hashable refines Equatable) or must “Equatable” also be

Re: [swift-evolution] [Proposal] Synthesizing Equatable/Hashable conformance for enums and structs

Thanks for the questions! On Wed, Aug 9, 2017 at 9:18 AM Nevin Brackett-Rozinsky < nevin.brackettrozin...@gmail.com> wrote: > Looks good to me, though I have some clarifying questions. For a type > which conforms to both Equatable and Hashable: > > 1. To automatically derive both Equatable and

Re: [swift-evolution] Swift 5: start your engines

> On Aug 9, 2017, at 2:30 AM, Brent Royal-Gordon via swift-evolution > wrote: > >> On Aug 8, 2017, at 3:07 PM, Erica Sadun via swift-evolution >> wrote: >> >> Upfront costs *will* be higher. Not only do you have to believe that a >>

Re: [swift-evolution] private extension

That behaviour was never explicitly mentioned in SE-0169 but I agree its confusing. But I’m also fairly sure the only window to do anything about it is Swift 4. Everybody is really worn down by those access level discussions. For illustration, Vladimir is confused that: private extension Foo {

Re: [swift-evolution] private extension

Actually, I think this is this way only as a relic from the original private/fileprivate proposal. Swift 3’s private has no meaning as an extension modifier, so it was made to alias to fileprivate. But since SE-0169 modified private’s meaning so that it would make sense as an extension

Re: [swift-evolution] private extension

The last thing I want is to launch into a new round of discussions. I am just hoping it can be considered as a straight bug that can be fixed without any discussion. > On 9 Aug 2017, at 23:47, Xiaodi Wu wrote: > > I brought this up after SE-0169, but it was deemed to be a

Re: [swift-evolution] private extension

Do you a have a link to that discussion? > On 10 Aug 2017, at 00:04, Xiaodi Wu wrote: > > Agree, but again, I tried, and the answer was no, it’s not considered a bug > and cannot be fixed without independent discussion. >> On Wed, Aug 9, 2017 at 16:51 David Hart

Re: [swift-evolution] private extension

I agree this should be considered a simple bug. Have you filed a bug report? Nevin ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [discussion] Class stored properties?

Class variables are not common, but they are the most natural way to implement class-specific functionality. Off the top of my head, I have used class variables for: 1) Custom allocation schemes, e.g. pools, LRU implementations 2) Diagnostics, e.g. counting the number of instances of a given

Re: [swift-evolution] private extension

I brought this up after SE-0169, but it was deemed to be a separate issue and any further consideration was declined. Let’s not initiate another round of access control discussions. On Wed, Aug 9, 2017 at 16:31 David Hart via swift-evolution < swift-evolution@swift.org> wrote: > Actually, I think

Re: [swift-evolution] private extension

Agree, but again, I tried, and the answer was no, it’s not considered a bug and cannot be fixed without independent discussion. On Wed, Aug 9, 2017 at 16:51 David Hart wrote: > The last thing I want is to launch into a new round of discussions. I am > just hoping it can be

Re: [swift-evolution] private extension

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170417/035885.html On Wed, Aug 9, 2017 at 17:05 David Hart wrote: > Do you a have a link to that discussion? > > > On 10 Aug 2017, at 00:04, Xiaodi Wu wrote: > > Agree, but again, I tried,

Re: [swift-evolution] Enums and Source Compatibility - defaults

:-) As you've all noted, there are some conflicting concerns for the default: - Source compatibility: the existing behavior for an unannotated enum is "closed". - Intuition: if you show someone an enum without an explicit annotation, they'll probably expect they can switch over it. (I'm going

Re: [swift-evolution] Enums and Source Compatibility - defaults

Ah, I forgot to mention: per my response to Charlie, the vast majority of enums in ObjC Foundation (80-90%) seem to be "open". I should have put that in the "open" side of the list. I'm not convinced that "APIs are designed differently in Swift" to the extent where you'd actually expect most

Re: [swift-evolution] [swift-evolution-announce] Swift 5: start your engines

I am not against these changes, of requiring an implementation, but I am a little nervous. Let me expand. I was involved in the Java Coin initiative for community driven changes to Java 7. In that process the implementation barrier was set very high and it effectively meant that only changes from

Re: [swift-evolution] Enums and Source Compatibility

Hi, Vladimir. I think framing this as a consumer decision is the wrong place to start. There are some enums that definitely make sense to be "closed", all the time, with no additional annotations, including Foundation.NSComparisonResult and, well, Swift.Optional. (Yes, Optional is special, and

Re: [swift-evolution] Pitch: Improved Swift pointers

> On Jul 19, 2017, at 11:21 AM, Taylor Swift via swift-evolution > wrote: > > What about `value:`? > > `ptr.initialize(value: value)` > `ptr.initialize(value: value, count: 13)` > `ptr.initialize(as: UInt16.self, at: 0, value: value, count: 13)` Doesn't read as a

Re: [swift-evolution] [swift-evolution-announce] Swift 5: start your engines

> On Aug 9, 2017, at 8:52 PM, Howard Lovatt via swift-evolution > wrote: > I am not against these changes, of requiring an implementation, but I am a > little nervous. Let me expand. > > I was involved in the Java Coin initiative for community driven changes to >

Re: [swift-evolution] private extension

I counter with the rationale for rejecting SE-0119 , namely: The review of "SE-0119: Remove access modifiers from extensions" ran from > July 12...19. The proposal has been *rejected*. > > The majority of the

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0185 - Synthesizing Equatable and Hashable conformance

And of course, the correct proposal link is: https://github.com/apple/swift-evolution/blob/master/proposals/0185-synthesize-equatable-hashable.md > On Aug 9, 2017, at 4:10 PM, Chris Lattner wrote: > > I forgot to mention that the implementation of this feature is available

Re: [swift-evolution] [Review] SE-0185 - Synthesizing Equatable and Hashable conformance

> • What is your evaluation of the proposal? +∞ - 1 (for no extension synthesis) > • Is the problem being addressed significant enough to warrant a change to > Swift? Most certainly. This is a major pain point, especially for structs with many members. > • Does this proposal fit well with

Re: [swift-evolution] ExpressibleByStringInterpolation

This is an excellent proposal; no suggestions for improvement at this point, as I think it has evolved excellently from its earlier forms. I hope it goes swiftly to review. On Tue, Aug 8, 2017 at 11:08 PM, Brent Royal-Gordon via swift-evolution < swift-evolution@swift.org> wrote: > I had a

Re: [swift-evolution] Enums and Source Compatibility

Hi, Charlie. This is fair—if you're switching over an open enum at all, presumably you have a reason for doing so and therefore might want to handle all known cases every time you update your SDK. However, I think in practice that's going to be rare—do you have examples of exhaustive switches

Re: [swift-evolution] Enums and Source Compatibility

> On Aug 9, 2017, at 10:15, Tony Allevato via swift-evolution > wrote: > > On Wed, Aug 9, 2017 at 9:40 AM David Sweeris via swift-evolution > > wrote: > (Now with more mailing lists in the "to" field!) >

Re: [swift-evolution] private extension

On Wed, Aug 9, 2017 at 5:52 PM, Nevin Brackett-Rozinsky < nevin.brackettrozin...@gmail.com> wrote: > I counter with the rationale for rejecting SE-0119 > , > namely: > > The review of "SE-0119: Remove access

[swift-evolution] [Review] SE-0185 - Synthesizing Equatable and Hashable conformance

Hello Swift community, The review of SE-0185 - "Synthesizing Equatable and Hashable conformance" begins now and runs through August 15, 2017. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0185-synthesize-equatable-hashable.md Reviews are an

Re: [swift-evolution] [Review] SE-0185 - Synthesizing Equatable and Hashable conformance

I forgot to mention that the implementation of this feature is available here: https://github.com/apple/swift/pull/9619 -Chris > On Aug 9, 2017, at 4:08 PM, Chris Lattner wrote: > > Hello Swift community, > > The review of SE-0185 - "Synthesizing Equatable and Hashable

Re: [swift-evolution] Enums and Source Compatibility

On Tue, Aug 8, 2017 at 5:27 PM, Jordan Rose via swift-evolution < swift-evolution@swift.org> wrote: > Hi, everyone. Now that Swift 5 is starting up, I'd like to circle back to > an issue that's been around for a while: the source compatibility of enums. > Today, it's an error to switch over an

Re: [swift-evolution] [Review] SE-0185 - Synthesizing Equatable and Hashable conformance

On Wed, Aug 9, 2017 at 6:08 PM, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote: > Hello Swift community, > > The review of SE-0185 - "Synthesizing Equatable and Hashable conformance" > begins now and runs through August 15, 2017. The proposal is available here: >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0185 - Synthesizing Equatable and Hashable conformance

> On Aug 9, 2017, at 4:09 PM, Chris Lattner wrote: > > Hello Swift community, > > The review of SE-0185 - "Synthesizing Equatable and Hashable conformance" > begins now and runs through August 15, 2017. The proposal is available here: >

Re: [swift-evolution] Enums and Source Compatibility

There really isn't a good way to do "extensible outside the library" enums, because at that point you've lost the guarantee of distinct cases—it's possible for two modules to add the same case with the same raw value. So I don't think there are really three states for public enums, only two. I

Re: [swift-evolution] [Review] SE-0185 - Synthesizing Equatable and Hashable conformance

On Wed, Aug 9, 2017 at 4:36 PM Xiaodi Wu via swift-evolution < swift-evolution@swift.org> wrote: > On Wed, Aug 9, 2017 at 6:08 PM, Chris Lattner via swift-evolution < > swift-evolution@swift.org> wrote: > >> Hello Swift community, >> >> The review of SE-0185 - "Synthesizing Equatable and Hashable

Re: [swift-evolution] Enums and Source Compatibility

> On Aug 9, 2017, at 11:45, Dave DeLong wrote: > > >> On Aug 8, 2017, at 4:27 PM, Jordan Rose via swift-evolution >> > wrote: >> >> Hi, everyone. Now that Swift 5 is starting up, I'd like to circle back to an >>

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0185 - Synthesizing Equatable and Hashable conformance

On Wed, Aug 9, 2017 at 4:59 PM Michael Ilseman via swift-evolution < swift-evolution@swift.org> wrote: > > On Aug 9, 2017, at 4:09 PM, Chris Lattner wrote: > > Hello Swift community, > > The review of SE-0185 - "Synthesizing Equatable and Hashable conformance" > begins now

Re: [swift-evolution] Enums and Source Compatibility - defaults

On Wed, Aug 9, 2017, at 08:42 PM, Jordan Rose via swift-evolution wrote:> - Consistency: switches on an enum in the same module can always be > exhaustive, so having it be different across modules is a bit > annoying. (But 'public' already acts like this.) >From someone frequently working on

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0185 - Synthesizing Equatable and Hashable conformance

> > The review of SE-0185 - "Synthesizing Equatable and Hashable conformance". > The proposal is available here: > https://github.com/apple/swift-evolution/blob/master/ > proposals/0185-synthesize-equatable-hashable.md > > • What is your evaluation of the proposal? > Overall a worthwhile

Re: [swift-evolution] Pitch: Improved Swift pointers

On Wed, Aug 9, 2017 at 8:22 PM, Brent Royal-Gordon via swift-evolution < swift-evolution@swift.org> wrote: > On Jul 19, 2017, at 11:21 AM, Taylor Swift via swift-evolution < > swift-evolution@swift.org> wrote: > > What about `value:`? > > `ptr.initialize(value: value)` > `ptr.initialize(value:

Re: [swift-evolution] Enums and Source Compatibility - defaults

On Wed, Aug 9, 2017, at 08:49 PM, Jordan Rose via swift-evolution wrote:> Ah, I forgot to mention: per my response to Charlie, the vast majority > of enums in ObjC Foundation (80-90%) seem to be "open". I should have > put that in the "open" side of the list. I'm not convinced that "APIs > are

Re: [swift-evolution] How does "Sequence.joined" work?

> On Aug 9, 2017, at 12:19 PM, Taylor Swift wrote: > > On Wed, Aug 9, 2017 at 10:43 AM, Daryle Walker via swift-evolution > > wrote: > >> On Aug 8, 2017, at 6:45 PM, Geordie Jay >

[swift-evolution] [discussion] What generics feature would this be?

Curious what part of generics the below would fall under? This hit me by surprise/makes even non-generic/Self-depending protocols un-interchangeable with classes.. ``` protocol Special {} func doWithAndReturn(_ special: S) -> S { ... } let special: Special = ... // "error: Generics parameter

Re: [swift-evolution] Enums and Source Compatibility

I disagree. Closed is indeed the stronger guarantee, but APIs are designed differently in Swift; closed is a sensible default. We shouldn’t need to define new keywords and increase the surface area of the language for something that has verisimilitude with the existing open syntax. Sincerely,