Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

> On Jan 17, 2018, at 14:42, Jordan Rose wrote: > > > >> On Jan 17, 2018, at 14:41, Chris Lattner > > wrote: >> >>> On Jan 16, 2018, at 10:24 AM, Jordan Rose >> >

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

> On Jan 17, 2018, at 14:41, Chris Lattner wrote: > >> On Jan 16, 2018, at 10:24 AM, Jordan Rose > > wrote: On Jan 12, 2018, at 3:08 PM, Jordan Rose >

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

> On Jan 14, 2018, at 09:36, Vladimir.S wrote: > > > > On 12.01.2018 21:38, Jordan Rose wrote: >>> On Jan 12, 2018, at 06:49, Michel Fortin via swift-evolution >>> > wrote: >>> Le 12 janv. 2018 à 4:44,

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

> On Jan 13, 2018, at 18:33, Chris Lattner wrote: > > I don’t understand why #unknown wouldn’t work in catch clauses. In the > absence of typed throws you can’t match on an enums case without the enums > base: you can’t use .foo, you have to use MyEnum.foo. > >

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

Is this equivalent to `default: break`? `default: fatalError()`? I think it's better to write such things explicitly. Jordan > On Jan 14, 2018, at 21:51, Tim Wang wrote: > > I would like to add a syntax sugar .casesBelow for enum value to be used in > switch

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

gt;>> Unless I’m missing something, this is still missing the discussion on being >>> able to treat all enums of internally-packaged libraries as frozen. >>> >>> IE, that frozen vs unfrozen is only an issue for enums that come from >>> modules that are not

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

Dave > >> On Jan 12, 2018, at 4:08 PM, Jordan Rose via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> Okay, I went back to `unknown case` in the proposal, but mentioned Chris's >> point very specifically: if the compiler emits an

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

Okay, I went back to `unknown case` in the proposal, but mentioned Chris's point very specifically: if the compiler emits an error, we should go with `case #unknown` instead. (I'm very strongly in the "warning" camp, though.) I think the revised proposal is in good shape!

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

> On Jan 12, 2018, at 06:49, Michel Fortin via swift-evolution > wrote: > >> Le 12 janv. 2018 à 4:44, Vladimir.S via swift-evolution >> > a écrit : >> >> On 12.01.2018 10:30, Chris Lattner via

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

> On Jan 11, 2018, at 23:30, Chris Lattner wrote: > > >> On Jan 11, 2018, at 11:15 PM, Jean-Daniel via swift-evolution >> wrote: >> >> A question about the new #unknown behavior. Is it intended to be used for >> error handling too ? >> Will

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

> On Jan 11, 2018, at 05:08, Michel Fortin wrote: > > I think `unknown` should be a modifier for either `case` or `default`. This > would allow: > > unknown default: > unknown case _: // similar to default > unknown case (1, _): // enum in second

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

Removing cases just isn’t allowed. They can be deprecated, but actually removing one is a breaking change. With a Swift enum the app will actually fail to launch with a dynamic linking error. Jordan > On Jan 10, 2018, at 21:27, Howard Lovatt wrote: > > It is a two

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

Remember, the goal here is to support both binary and source compatibility. An existing app might be using the enum case that you're trying to remove, but there's no chance that an existing app is using an enum case that you're trying to add. Jordan > On Jan 10, 2018, at 16:34, Howard Lovatt

Re: [swift-evolution] [Review] SE-0194: Derived Collection of Enum Cases

[Proposal: https://github.com/apple/swift-evolution/blob/master/proposals/0194-derived-collection-of-enum-cases.md] I think this is generally reasonable, and none of the names offend me enough to weigh in on that discussion. I do think it's a little weird that @objc enums defined in Swift

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

> On Jan 10, 2018, at 12:04, Jose Cheyo Jimenez via swift-evolution > wrote: > > > > On Tue, Jan 9, 2018 at 10:10 PM, Chris Lattner > wrote: > On Jan 9, 2018, at 3:07 PM, Jose Cheyo Jimenez

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

>> That said, it sounds like people are happier with `case #unknown` than >> `unknown case`, and that leaves things a little more consistent if we ever >> do expand it to other pattern positions, so I'll change the proposal >> revision to use that spelling. (And if anyone comes up with a nicer

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

> On Jan 9, 2018, at 22:17, Chris Lattner wrote: > > On Jan 9, 2018, at 4:46 PM, Jordan Rose > wrote: >> Thanks for writing this up, Chris! I addressed the idea of making this an >> arbitrary pattern in the revised

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

> On Jan 9, 2018, at 21:39, Brent Royal-Gordon <br...@architechies.com> wrote: > > > >> On Jan 9, 2018, at 4:46 PM, Jordan Rose via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >>

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

I'm not sure how this solves the problem. We need to know whether an enum may grow new cases or not, a concept that doesn't exist in Swift today. This is most interesting for enums in "libraries with binary compatibility concerns", but is also interesting for libraries that don't have such

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

> On Jan 8, 2018, at 22:54, Chris Lattner via swift-evolution > wrote: > > The mega-thread about SE-0192 is a bit large, and I’d like to talk about one > specific point. In the review conversation, there has been significant > objection to the idea of requiring a

Re: [swift-evolution] Questions about non-exhaustive enums

Good questions. The answer at a high level is "you break binary and source compatibility", and if you care about binary compatibility everything will fall to pieces (read: crashes, possibly undefined behavior). So our only goal on the binary compatibility is to make the "falling to pieces" as

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

sn’t appear to be one >> for Obj-C. If an enum adds a case now, I don’t have to care until I >> recompile using the new SDK. Is the intention for Swift to be different in >> this regard? >> >> >> >> Jon Shier >> >> On Jan 5, 2018, at 6:41 PM,

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

> On Jan 3, 2018, at 00:54, Jason Merchant via swift-evolution > wrote: > > Is it hard to imagine that most everyone can get what they want and keep the > syntax clean and streamlined at the same time? Without any "@" signs or other > compiler hints? For what

Re: [swift-evolution] [swift-evolution-announce] [Review] SE 0192 - Non-Exhaustive Enums

Clarifications here only! I don't think I have too much more to convince you; at this point we've looked at the same landscape and come to different conclusions. Although I think I'm more optimistic than you are about being able to build a binary compatibility checker. > On Jan 5, 2018, at

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

> On Jan 5, 2018, at 00:11, Jonathan Hull via swift-evolution > wrote: > >> >> On Jan 4, 2018, at 11:02 PM, Xiaodi Wu > > wrote: >> >> >> On Fri, Jan 5, 2018 at 01:56 Jonathan Hull >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE 0192 - Non-Exhaustive Enums

ely > capable of covering the possibilities: we just keep using a “default:” case > whenever the compiler can’t guarantee that we can be exhaustive in our > switching. > > Where the real work would be is teaching the compiler about > internally-vs-externally linked modules. >

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

> On Jan 4, 2018, at 11:45, Cheyo Jimenez wrote: > > > > On Jan 4, 2018, at 10:49 AM, Jordan Rose > wrote: > >> I'll admit I hadn't thought of using "unknown default" (or "default >> unknown"). I don't think

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

ult", can't be >> mixed with "default", and can't be used in case patterns, why not "default >> unknown" (or "unknown default") instead of "unknown case"? > > `case _ :` is already a special case of default. > I’d rather have `case unknown

Re: [swift-evolution] [swift-evolution-announce] [Review] SE 0192 - Non-Exhaustive Enums

> On Jan 2, 2018, at 18:07, Jordan Rose wrote: > > [Proposal: > https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md > > ] > > Whew!

Re: [swift-evolution] [swift-evolution-announce] [Review] SE 0192 - Non-Exhaustive Enums

[Proposal: https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md ] Whew! Thanks for your feedback, everyone. On the lighter side of feedback—naming things—it

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

> On Dec 20, 2017, at 12:54, Charlie Monroe wrote: > > I think that the main confusion here stems from the word library as we are > addressing something that can be divided further (and this is IMHO as many > macOS/iOS devs see it): > > - libraries that come with

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

> On Dec 20, 2017, at 12:52, Colin Barrett wrote: > > >> On Dec 20, 2017, at 1:36 PM, Jordan Rose > > wrote: >> >> Thanks for the links, Colin. I think neither of these approaches are >> appropriate for

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

Thanks for your comments, Jon. Responses inline. > On Dec 20, 2017, at 12:46, Jonathan Hull wrote: > > >> On Dec 19, 2017, at 2:58 PM, Ted Kremenek via swift-evolution >> > wrote: >> When reviewing a proposal, here

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

> On Dec 20, 2017, at 12:35, Karl Wagner wrote: > > > >> On 20. Dec 2017, at 19:54, Jordan Rose > > wrote: >> >> >> >>> On Dec 20, 2017, at 05:36, Karl Wagner via swift-evolution >>>

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

Thanks for your response, Ash. Comments inline. > On Dec 20, 2017, at 11:49, Ash Furrow via swift-evolution > wrote: > > Proposal link: > https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md > >

Re: [swift-evolution] The Non-Exhaustive Enums proposal kills one of Swift's top features - change proposal

[Proposal: https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md] > On Dec 21, 2017, at 09:49, Ignacio Soto via swift-evolution > wrote: > > I think I speak for the entire Swift community when I say that Swift's enums, >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE 0192 - Non-Exhaustive Enums

> On Dec 19, 2017, at 20:15, Howard Lovatt via swift-evolution > wrote: > > As an aside: there seems to be increasingly comments about proposals that say: > > 1. This was discussed at the evaluation stage and rejected. > 2. This is how it is implemented in the

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

Thanks for the feedback, Dave! Responses inline. > On Dec 20, 2017, at 09:23, Dave DeLong via swift-evolution > wrote: > > > >> On Dec 19, 2017, at 3:58 PM, Ted Kremenek via swift-evolution >> > wrote:

Re: [swift-evolution] [swift-evolution-announce] [Review] SE 0192 - Non-Exhaustive Enums

Thanks for your feedback! I think you're missing the "libraries in the OS" aspect of this: if there are Swift libraries in iOS, and Apple ships a software update, some enums will get new cases. That means you can always end up in a default case if you were switching over those enums, and that's

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

> On Dec 20, 2017, at 05:36, Karl Wagner via swift-evolution > wrote: > > > >> On 19. Dec 2017, at 23:58, Ted Kremenek via swift-evolution >> > wrote: >> >> The review of "SE 0192 - Non-Exhaustive

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

Thanks for the links, Colin. I think neither of these approaches are appropriate for Swift, largely for the same reason: they can't be used to define a library's API. Polymorphic variants are ad-hoc union types (much like tuples are ad-hoc structs) which—apart from having other problems in

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0189: Restrict Cross-module Struct Initializers

> On Nov 17, 2017, at 15:20, Ben Langmuir wrote: > > Hi Jordan, > > First off, this is clearly the model we should have had all along ;-) That > said, I have a concern about source-compat and our ability to automatically > migrate code impacted by this change. >>

Re: [swift-evolution] [Review] SE-0189: Restrict Cross-module Struct Initializers

Hi, David. This only affects cross-module use cases, which means that the automatically synthesized initializer doesn’t come into play (because it’s not public). Is the clarification you’re looking for something like “a 'source-breaking change’ is something that can cause previously compiling

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0189: Restrict Cross-module Struct Initializers

Hi, everyone, proposal author here. Caveat: I'll be on vacation for the last few days of this review period, so I won't see your comments after Saturday the 18th (and possibly not even then, if you send them too late in the day). This is fine, of course, but if you have questions for me I may

Re: [swift-evolution] Pitch: Restrict Cross-module Struct Initializers

> On Oct 7, 2017, at 14:44, Chris Lattner <clatt...@nondot.org> wrote: > > >> On Oct 6, 2017, at 2:32 PM, Jordan Rose via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> While working on the

Re: [swift-evolution] Property Getter Return Statement

> On Oct 8, 2017, at 21:56, Slava Pestov via swift-evolution > wrote: > > > >> On Oct 7, 2017, at 7:07 AM, James Valaitis via swift-evolution >> wrote: >> >> Is it widely agreed that it is necessary to require a return statement on a

Re: [swift-evolution] Pitch: Restrict Cross-module Struct Initializers

ibed in this proposal be enforced also for testing > targets/modules? > > R+ > > Sent from my iPhone > > On 7 Oct 2017, at 23:44, Chris Lattner via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >> >

Re: [swift-evolution] Pitch: Restrict Cross-module Struct Initializers

gt;> the current functionality? >> >> >> On Fri, Oct 6, 2017 at 16:32 Jordan Rose via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> While working on the non-exhaustive enums proposal I had it pointed out

Re: [swift-evolution] Pitch: Restrict Cross-module Struct Initializers

in a source package, and we wouldn't want this to become one. Jordan > On Oct 6, 2017, at 15:23, Xiaodi Wu <xiaodi...@gmail.com> wrote: > > Presumably, @_fixed_layout and its future formalized cousin would restore the > current functionality? > > > On Fri, Oct 6, 2017 at

[swift-evolution] Pitch: Restrict Cross-module Struct Initializers

While working on the non-exhaustive enums proposal I had it pointed out to me that structs actually currently leak implementation details across module boundaries, specifically their full set of stored properties. This only comes up in one place: when making an initializer for the struct in an

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

> - Imports are per-module, not per-source-file, so this couldn’t be used to > “user-partition” the identifier and operator space. It could be a way to > make it clear that the user is opting into these explicitly. Imports actually are per-source-file. At times they appear to be per-module

Re: [swift-evolution] Fix "private extension" (was "Public Access Modifier Respected in Type Definition")

> On Oct 2, 2017, at 18:06, Jose Cheyo Jimenez <ch...@masters3d.com> wrote: > >> >> On Oct 2, 2017, at 5:33 PM, Jordan Rose via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> >>

Re: [swift-evolution] Fix "private extension" (was "Public Access Modifier Respected in Type Definition")

> On Oct 2, 2017, at 03:25, Vladimir.S via swift-evolution > wrote: > > On 01.10.2017 1:18, Chris Lattner wrote: >>> On Sep 29, 2017, at 10:42 AM, Xiaodi Wu via swift-evolution >>> wrote: >>> >>> Vladimir, I agree with you on that

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

Today's @available can't be the thing that makes symbols public, since it's also used to affect the availability context for private symbols. The one described in the library evolution document is specifically about marking something available with respect to the current module. So we would

Re: [swift-evolution] Enums and Source Compatibility

I don't think I have anything to say on this topic that I haven't already said: - Switching exhaustively over non-exhaustive enums is uncommon. - It's more important for a library to build without errors when its dependencies change than it is to get an error. (This doesn't apply to warnings,

Re: [swift-evolution] Enums and Source Compatibility

This exists, but it's imperfect: it's possible that an app and its embedded frameworks are not all linked against the same version of the SDK, and then the system framework has to go with whatever the app does. (It's more important to behave consistently within a process.) It's not impossible

Re: [swift-evolution] Enums and Source Compatibility

(responses to both Jon and Goffredo's most recent point inline) > On Sep 28, 2017, at 16:15, Goffredo Marocchi wrote: > > Agreed, I am not seeing this change doing so much good because maybe it could > prevent issues Library writers or developers updating libraries without

Re: [swift-evolution] Enums and Source Compatibility

> On Sep 22, 2017, at 08:20, Karl Wagner wrote: > > So I’m in favour of the change, but absolutely not in favour of the keywords. > We need to standardise a minimal set of keywords which broadly cover the > things library authors need to care about (versioning,

Re: [swift-evolution] Enums and Source Compatibility

> On Sep 22, 2017, at 17:50, Rex Fenley wrote: > > It’s really only an issue for people whose frameworks are used across > variously-distributed apps (your own, or other peoples’). The typical dynamic > library use-case. Those people already know to be careful, so why

Re: [swift-evolution] Enums and Source Compatibility

> On Sep 27, 2017, at 16:48, Jessie Serrino wrote: > > Hi there, > > Just want to circle back on a few things. > > You mentioned that library vendors communicate deprecation notices, but this > is very prone to error. If someone misses the notice that a library puts out

Re: [swift-evolution] Enums and Source Compatibility

> On Sep 20, 2017, at 16:15, Dave DeLong wrote: > > Hi Jordan, > > One thing I’m still not clear on exhaustive vs non-exhaustive… > > What will stop a developer from releasing an exhaustive enum in version 1 of > their library, and then adding a new case in version 2? >

Re: [swift-evolution] Enums and Source Compatibility

framework author had validated it > with unit tests? > > Sent from my iPhone > > On 16 Sep 2017, at 01:07, Jordan Rose via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >> Hi, Rex. I definitely agree that 'exhaustive'

Re: [swift-evolution] Enums and Source Compatibility

makes the default case un-testable, which brings >> me to >> >> 2) All non-exhaustive enums should have the pseudo value “default” that can >> be used just like a regular value. This would allow you to write code like: >> >> teacher.failedToHandInHomew

Re: [swift-evolution] Enums and Source Compatibility

> On Sep 16, 2017, at 15:35, Kenny Leung via swift-evolution > wrote: > > In general, I agree with everything in the proposal. > > I’d like to propose these alternative extensions for clients: > > 1) As a client of an enum, I’d like to know in the future when a

Re: [swift-evolution] Enums and Source Compatibility

eyword in Swift 4 to change that behaviour > Non-exhaustive by default outside the module in Swift 5 > exhaustive keyword to change the default behaviour > > Like that, we don’t need nonexhaustive. > > Thoughts? > David. > >> On 13 Sep 2017, at 21:16, Jordan Rose via swi

Re: [swift-evolution] Enums and Source Compatibility

> On Sep 16, 2017, at 11:35, Christopher Kornher via swift-evolution > wrote: > > > > > >> On Sep 16, 2017, at 11:28 AM, Christopher Kornher via swift-evolution >> > wrote: >> >>> >>> On Sep 16,

Re: [swift-evolution] Enums and Source Compatibility

ng the default internally and > closed the default publicly. Otherwise you’re essentially forcing what is > likely the vast majority of enum usage to adopt a bit of boilerplate that > will only be used by the vast minority of libraries (almost entirely > libraries shipped by Apple).

Re: [swift-evolution] Enums and Source Compatibility

Hi, Rex. I definitely agree that 'exhaustive' is the right model for a multi-module app; indeed, there's no real reason for a single project to do anything else. However, it is not always the right behavior for libraries that actually get distributed, whether as source or as binary. In this

Re: [swift-evolution] Subscripts assignable to closure vars

> On Sep 15, 2017, at 13:00, John McCall via swift-evolution > wrote: > >> >> On Sep 15, 2017, at 3:45 PM, Joanna Carter via swift-evolution >> > wrote: >> >> Just came across this. >> >> I want to be

Re: [swift-evolution] Enums and Source Compatibility

> On Sep 14, 2017, at 20:59, Chris Lattner <clatt...@nondot.org> wrote: > > >> On Sep 13, 2017, at 12:17 PM, Jordan Rose via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> Proposal updated,

Re: [swift-evolution] Enums and Source Compatibility

ack so far, everyone! Jordan > On Sep 12, 2017, at 17:55, Jordan Rose via swift-evolution > <swift-evolution@swift.org> wrote: > > Sorry, I got distracted by other tasks! Both the discussion here and within > Apple has moved towards making "non-exhaustive" the d

Re: [swift-evolution] Enums and Source Compatibility

> On Sep 13, 2017, at 05:21, Brent Royal-Gordon wrote: > >> On Sep 12, 2017, at 6:30 PM, Jordan Rose > > wrote: >> >> It gets a little tricky if layout matters—Optional fits exactly >> in a single word-sized value,

Re: [swift-evolution] Enums and Source Compatibility

017, at 05:53, Brent Royal-Gordon <br...@architechies.com> wrote: > >> On Sep 5, 2017, at 5:19 PM, Jordan Rose via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> I've taken everyone's feedback into con

Re: [swift-evolution] Enums and Source Compatibility

Sorry, I got distracted by other tasks! Both the discussion here and within Apple has moved towards making "non-exhaustive" the default, which, to be honest, I too think is the best design. I'll update the proposal today to reflect that, though I still want to keep both the "nonexhaustive" and

Re: [swift-evolution] Enums and Source Compatibility

> swift construct. > > You could declare it like this: > > enum struct { >case a, b, c > } > > This would be a struct that acts like an enum but it is open like a > RawRepresentable but using the enum case sugar. > > On Sep 5, 2017, at 5:37 P

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0184: Unsafe[Mutable][Raw][Buffer]Pointer: add missing methods, adjust existing labels for clarity, and remove deallocation size

> On Sep 7, 2017, at 17:46, Andrew Trick wrote: > > >> On Sep 7, 2017, at 5:40 PM, Joe Groff wrote: >> >> >>> But then given that, I don't understand why the 'capacity' parameter is necessary. Under what circumstances would it actually be

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0184: Unsafe[Mutable][Raw][Buffer]Pointer: add missing methods, adjust existing labels for clarity, and remove deallocation size

> On Sep 7, 2017, at 17:09, Andrew Trick wrote: > > >> On Sep 7, 2017, at 2:29 PM, Jordan Rose > > wrote: >> >>> >>> We do want the Swift memory model to be consistent with the reality that on >>> most platforms, we

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0184: Unsafe[Mutable][Raw][Buffer]Pointer: add missing methods, adjust existing labels for clarity, and remove deallocation size

> On Sep 7, 2017, at 13:02, Andrew Trick wrote: > > >> On Sep 7, 2017, at 11:39 AM, Jordan Rose > > wrote: >> >>> This discussion needs to be grounded by reiterating role of the API. >>> UnsafePointer specifies the

Re: [swift-evolution] Enums and Source Compatibility

It's in the "Alternatives Considered" section. :-) That was my desired design when we started, but feedback convinced me that the break from Swift 4 mode would be too drastic. The same valid code would have a different meaning whether you were writing Swift 4 or Swift 5. Jordan > On Sep 5,

Re: [swift-evolution] Enums and Source Compatibility

I've taken everyone's feedback into consideration and written this up as a proposal: https://github.com/jrose-apple/swift-evolution/blob/non-exhaustive-enums/proposals/-non-exhaustive-enums.md

Re: [swift-evolution] Why you can't make someone else's class Decodable: a long-winded explanation of 'required' initializers

> On Sep 2, 2017, at 00:30, Fabian Ehrentraud <fabian.ehrentr...@willhaben.at> > wrote: > > > Am 03.08.2017 um 02:09 schrieb Jordan Rose via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>: > >> David Hart recen

Re: [swift-evolution] Enums and Source Compatibility

> On Aug 11, 2017, at 02:59, Vladimir.S wrote: > > On 11.08.2017 2:37, Jordan Rose wrote: >> Both you and Vladimir are bringing up this point, with Vladimir explicitly >> suggesting a "future" case that's different from "default". Again, the >> pushback we get here is that

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

> On Aug 10, 2017, at 13:00, David Hart wrote: > > > > On 10 Aug 2017, at 19:19, Jordan Rose > wrote: > >> >> >>> On Aug 9, 2017, at 22:46, David Hart >> > wrote: >>>

Re: [swift-evolution] Enums and Source Compatibility

he way nullability is >>> still missing in many frameworks out there, I think would take years. >>> >>> I'd personally expand this proposal by introducing switch! (with the >>> exclamation mark) which would allow to treat open enums as closed. Example: >>&g

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

> On Aug 9, 2017, at 20:00, Zach Waldowski via swift-evolution > <swift-evolution@swift.org> wrote: > > 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 >> e

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

> On Aug 10, 2017, at 15:34, Tony Allevato wrote: > > Do you mean something like this, then? > > ``` > struct Foo: Equatable { > let x: Int > } > > func test(_ lhs: T, _ rhs: T) -> Bool { > return lhs == rhs > } > > extension Foo { > static func == (lhs: Foo,

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

> On Aug 10, 2017, at 14:48, Tony Allevato wrote: > > On Thu, Aug 10, 2017 at 11:05 AM Jordan Rose > wrote: > [Proposal: >

Re: [swift-evolution] Enums and Source Compatibility

> On Aug 10, 2017, at 09:15, Vladimir.S via swift-evolution > wrote: > > On 10.08.2017 18:22, Adrian Zubarev via swift-evolution wrote: >> I think this design does not avoid you writing something like `private enum >> Foo { default ... }`, which is redudant as

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

[Proposal: https://github.com/apple/swift-evolution/blob/master/proposals/0185-synthesize-equatable-hashable.md ] Hi, Tony. Glad to see this back again! Overall I'm an enthusiastic +1. The

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

> On Aug 9, 2017, at 22:46, David Hart wrote: > > >> 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:

Re: [swift-evolution] Enums and Source Compatibility

what is your decided behaviour. by default your code will crash if > new cases are added" > , then we can add 'default' block to process new future cases or somehow mark > that switch as explicitly exhaustive... something like this: > > @exhaustive > switch openEnum { >

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

t IMHO nail their >>>> behavior down to the point: >>>> >>>> finite enum A {} - so to say a closed enum (default) >>>> infinite enum B {} - so to say an open enum (requires default case in a >>>> switch statement) >>>> >>>&g

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

enum A {} - so to say a closed enum (default) >>> infinite enum B {} - so to say an open enum (requires default case in a >>> switch statement) >>> >>> If you think the default should be the other way around, than feel free to >>> switch that. 'finite' a

Re: [swift-evolution] Enums and Source Compatibility

> On Aug 9, 2017, at 11:45, Dave DeLong <del...@apple.com> wrote: > > >> On Aug 8, 2017, at 4:27 PM, Jordan Rose via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> Hi, everyone. Now t

Re: [swift-evolution] Enums and Source Compatibility

more mailing lists in the "to" field!) > On Aug 8, 2017, at 3:27 PM, Jordan Rose via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >> Hi, everyone. Now that Swift 5 is starting up, I'd like to circle back to an &

Re: [swift-evolution] Enums and Source Compatibility

your opinion on using public as a “soft > default” and assigning it one of the two enum semantics you discuss? Do you > think this makes sense or would you prefer distinct keywords for these two > semantics? I don’t have any really great new ideas, but I’ll throw out > “complete” and “in

Re: [swift-evolution] Enums and Source Compatibility

witch would implicitely create the default label crashing, logging > the rawValue of the enum. > > Thoughts? > >> On Aug 9, 2017, at 12:28 AM, Jordan Rose via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>

Re: [swift-evolution] overridable members in extensions (was: Why you can't make someone else's class Decodable)

> On Aug 2, 2017, at 23:21, Goffredo Marocchi <pana...@gmail.com> wrote: > > > Sent from my iPhone > > On 3 Aug 2017, at 01:09, Jordan Rose via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >> >&

[swift-evolution] Why you can't make someone else's class Decodable: a long-winded explanation of 'required' initializers

David Hart recently asked on Twitter if there was a good way to add Decodable support to somebody else's class. The short answer is "no, because you don't control all the subclasses", but David already understood that and wanted to know

Re: [swift-evolution] [Review] SE-0182 - String Newline Escaping

> On Jul 14, 2017, at 10:00, Alex Blewitt wrote: > >> On 13 Jul 2017, at 23:14, David Hart via swift-evolution >> > wrote: >> >>> >>> On 14 Jul 2017, at 00:21, Jordan Rose >>

  1   2   3   4   >