Re: [swift-evolution] [REVIEW] SE-0193 - Cross-module inlining and specialization

> On Dec 21, 2017, at 12:42 PM, Paul Cantrell wrote: > > 1. Presumably the portions of A inlined into B and C remain sensitive to the > version-specific memory layout of A? Or will ABI stability mean that the > compiler can magically rearrange memory offsets in already-compiled code when > t

Re: [swift-evolution] [REVIEW] SE-0193 - Cross-module inlining and specialization

> On Dec 21, 2017, at 11:05 AM, Greg Titus via swift-evolution > wrote: > > I come from a perspective similar to Johannes, in that: for my work we are > interested in the performance improvements of cross-module optimization and > specialization but we regularly rebuild frameworks along with

Re: [swift-evolution] [swift-evolution-announce] [REVIEW] SE-0193 - Cross-module inlining and specialization

> On Dec 21, 2017, at 9:33 AM, Tony Parker via swift-evolution > wrote: > > public > public(inlinable) > public(external) // *where we define external to be what abiPublic is now — > more bike shedding welcome I think the downside is that public(external) or whatever @abiPublic becomes actu

Re: [swift-evolution] [REVIEW] SE-0193 - Cross-module inlining and specialization

Hi Johannes, Thanks for reviewing this proposal! > On Dec 21, 2017, at 8:06 AM, Johannes Weiß via swift-evolution > wrote: > The library I'm working on will presumably never have stable ABI as you'd > naturally build it with your application. However we also don't want to miss > on the cross

Re: [swift-evolution] [swift-evolution-announce] [REVIEW] SE-0193 - Cross-module inlining and specialization

Hi Chris, Thanks for reviewing the proposal! > On Dec 20, 2017, at 11:14 PM, Chris Lattner via swift-evolution > wrote: > >> On Dec 20, 2017, at 4:19 PM, Ted Kremenek > > wrote: >> >> The review of "SE-0193 - Cross-module inlining and specialization" begins >> now

Re: [swift-evolution] Preserving non-mutability of methods of an existential or generic object

Hi Hooman, Since the protocol P is not class-bounded, the requirement can be witnessed by a protocol extension method which re-assigns ‘self’: protocol Initable { init() } extension P where Self : Initable { mutating func f(_ x: Int) -> Int { self = Self() return x } } class C :

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

-1 It took awhile to catch up. I understand the motivation but don't agree with the solution. The suggested proposal adds language complexity that can hopefully be solved in other ways. In catching up I related to Howard Lovatt's response. Jordan responded: > On Dec 20, 2017, at 2:33 PM, Jorda

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

> On Dec 21, 2017, at 8:17 PM, Jordan Rose wrote: > > > >> 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

Re: [swift-evolution] [swift-evolution-announce] [Accepted with revisions] SE-0187 “Introduce Sequence.filterMap(_:)”

> On Dec 19, 2017, at 4:42 PM, Dave Abrahams via swift-evolution > wrote: > > > >> On Dec 19, 2017, at 2:28 PM, Xiaodi Wu via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> I disagree. Let’s not reopen what is settled. “Compact” can be a noun just >> as “map” and “filt

Re: [swift-evolution] Should we incorporate bunches of new operators / micro-syntactic sugar?

To answer your meta question, no, we don’t want to add lots of operators. We are willing to add them if they are very strongly motivated, but prefer not to if there are other ways to solve the problem. In this case it sounds like: x = optionalValue ?? x Is a reasonable substitute. -Chris

[swift-evolution] Preserving non-mutability of methods of an existential or generic object

The title is confusing, let me clarify by example: We have this protocol with a mutating method: protocol P { mutating func f(_ x: Int) -> Int } And a conforming class (which has to conform with a non-mutating method): class C: P { func f(_ x: Int) -> Int { return x } } An instance of this cla

Re: [swift-evolution] Enums and Source Compatibility

> On Oct 2, 2017, at 2:10 PM, Jordan Rose via swift-evolution > wrote: > > 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. [Citation Needed] As I pointed out in my email in the review thread

Re: [swift-evolution] Enums and Source Compatibility

Can you go into more detail about why the core team didn't like this? public enum HomeworkExcuse { case eatenByPet case thoughtItWasDueNextWeek default // NEW} To me this is very close to an ideal solution, it fixes ABI concerns, it has sensible defaults. If it was changed a little bit: p

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

Thanks for this response, John. I think you’re right. This would be very helpful. It a) helps those who are source compiling with their app, and b) avoids fragmenting the language because it would be a core understanding of the code you are compiling, rather than creating a new “variant” of Swi

Re: [swift-evolution] [swift-evolution-announce] [REVIEW] SE-0193 - Cross-module inlining and specialization

Thanks for this reply, Chris. It addresses most of my concerns with the current design - scalability (with the attributes), confusion (over the meaning of ABI) and changes in declarations as things change. I think your approach is a far better solution. > On 21 Dec 2017, at 6:14 pm, Chris Lattn

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

I very much agree with the high-level of the proposal. The concept definitely needs to exist. However, I feel that the options presented do so in a non-intuitive way. There are two concepts here: closed and open listing of values that make up a set of possible options to be used. I think of thi

Re: [swift-evolution] [REVIEW] SE-0193 - Cross-module inlining and specialization

Thanks for the answers, Slava. More inline below. > On Dec 21, 2017, at 12:30 AM, Slava Pestov wrote: > > Hi Paul, > > Thanks for reviewing the proposal! > >> On Dec 20, 2017, at 9:21 PM, Paul Cantrell > > wrote: >> >> A concern: how would a library author reason ab

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

I agree with everything said by Brent Royal-Gordon, however a -1 without the addition of a `future` case or something similar. - What is your evaluation of the proposal? -1, this solution solves a real problem but introduces a very significant drawback. It should include a solution that pr

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

> On Dec 21, 2017, at 2:17 PM, John McCall wrote: > > >> On Dec 21, 2017, at 3:10 PM, Matthew Johnson > > wrote: >> >> >>> On Dec 21, 2017, at 2:06 PM, John McCall >> > wrote: >>> >>> On Dec 21, 2017, at 2:41 PM, Matthew Johnson

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

> On Dec 21, 2017, at 3:10 PM, Matthew Johnson wrote: > > >> On Dec 21, 2017, at 2:06 PM, John McCall > > wrote: >> >> >>> On Dec 21, 2017, at 2:41 PM, Matthew Johnson >> > wrote: >>> >>> On Dec 21, 2017, at 1:26 PM, John McCall

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

Making enums non-exhaustive solves a problem for authors of precompiled frameworks which apps can dynamically link against. These libraries need to preserve binary compatibility, in the sense that apps should continue to work with newer versions of the library. Now, that creates a problem for app

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

> On Dec 21, 2017, at 2:06 PM, John McCall wrote: > > >> On Dec 21, 2017, at 2:41 PM, Matthew Johnson > > wrote: >> >> >>> On Dec 21, 2017, at 1:26 PM, John McCall via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> On Dec 21, 2017

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

> On Dec 21, 2017, at 2:41 PM, Matthew Johnson wrote: > > >> On Dec 21, 2017, at 1:26 PM, John McCall via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >>> >>> On Dec 21, 2017, at 2:03 PM, Jordan Rose via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >

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

+1 kind of eye opening looking at it from that angle :/. Sent from my iPhone > On 21 Dec 2017, at 18:02, Dave DeLong via swift-evolution > wrote: > > I realized further why we should not implement this proposal: It forces the > problem of binary compatibility on the app developer, when experi

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

Okay, thanks Jordan. I appreciate your perspective, and I admit that the proposal is technically compelling. My criticism was from a place of respect and admiration, and while I may have missed the deeper technical points of the proposal, I’ll still caution about how this change will be received

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

> On Dec 21, 2017, at 1:26 PM, John McCall via swift-evolution > wrote: > >> >> On Dec 21, 2017, at 2:03 PM, Jordan Rose via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> >> >>> On Dec 20, 2017, at 12:35, Karl Wagner >> > wrote: >>> >>> >>>

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

> On Dec 21, 2017, at 2:03 PM, Jordan Rose via swift-evolution > wrote: > > > >> On Dec 20, 2017, at 12:35, Karl Wagner > > wrote: >> >> >> >>> On 20. Dec 2017, at 19:54, Jordan Rose >> > wrote: >>> >>> >>> On Dec 20, 2017, a

Re: [swift-evolution] [REVIEW] SE-0193 - Cross-module inlining and specialization

On Thu, Dec 21, 2017 at 12:26 AM, Slava Pestov wrote: > Thanks for the review, Kelvin. > > On Dec 20, 2017, at 8:52 PM, Kelvin Ma via swift-evolution < > swift-evolution@swift.org> wrote: > > it makes sense to have @abiPublic on private and fileprivate declarations > too and i hope this gets adde

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 the OS - here, it absolutely

Re: [swift-evolution] Should we incorporate bunches of new operators / micro-syntactic sugar?

possibly off-topic but what i would really find useful is some way of expressing guard/if assignment instead of initialization so that let geomSource:UnsafeMutableBufferPointer? if let geometryFile:String = geometryFile { guard let _geomSource:UnsafeMutableBuffe

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 Swift, largely for the same reason: they can't be used to

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 >> mailto:swift-evolution@swift.org>> wrote: >> When reviewing a proposal, here are some questions to consider: >> >> What is

Re: [swift-evolution] [REVIEW] SE-0193 - Cross-module inlining and specialization

I come from a perspective similar to Johannes, in that: for my work we are interested in the performance improvements of cross-module optimization and specialization but we regularly rebuild frameworks along with apps and explicitly don’t need ABI versioning. Unlike him, I’m not that concerned w

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 >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> >>> On 19. Dec 201

Re: [swift-evolution] Should we incorporate bunches of new operators / micro-syntactic sugar?

Ah, sorry, I misread! For readability I think I'd still favor something like: if let b = b { dict[a] = b } And I think some the arguments made in #0024 may still apply here, though feel free to discuss! Stephen > On Dec 21, 2017, at 1:37 PM, Benoit Pereira da silva wrote: > > S

Re: [swift-evolution] Evaluating the case of an enum with associated values as a bool

> On Dec 21, 2017, at 10:19 AM, Ethan Diamond wrote: > > Just to clarify, Dave - > > What happens there if one case has associated values > and one has an associated value thats an optional? > > Enum A { >case x(String?) >case y > } > > let a = A.x(nil) A.x is String?? > a.y // W

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] Should we incorporate bunches of new operators / micro-syntactic sugar?

Stephen, You are right the proposal #0024 is very close. But in fact the logic is inverted. When using «=? » the right item is optional. a =? b assigns « b » to « a » only if « b » is defined. So if an optional is defined =? will not erase its value. But my real questions was… Do you have s

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

>> [...] > > Hi, Nacho. This is discussed in the proposal as "'future' cases" under > "Alternatives considered". The main blocker was that such a case becomes > untestable (see also "Testing invalid cases"). That didn't seem like an > acceptable state of affairs to me or to the people I had ori

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, > together with the ability to switc

Re: [swift-evolution] Evaluating the case of an enum with associated values as a bool

Just to clarify, Dave - What happens there if one case has associated values and one has an associated value thats an optional? Enum A { case x(String?) case y } let a = A.x(nil) a.y // What's the result? a.x // Would produce a double optional, which are clumsy to nil check I'm not a fan

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

> What I’m proposing is that we introduce a new keyword, unknown (or a better > name), that serves as a way to handle cases that aren’t yet known, but not > those that are. Afaics, the best this could do is helping when a compiled library using another, updated library with new cases in a switc

Re: [swift-evolution] Should we incorporate bunches of new operators / micro-syntactic sugar?

Such an operator was proposed here: https://github.com/apple/swift-evolution/blob/60a8980a66a0a1341871ec323797c5547d0e0925/proposals/0024-optional-value-setter.md It was ultimately rejected: https://lists.swift.org/pipermail/swift-evolution-announce/2016-February/43.html Stephen > On Dec 2

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

I realized further why we should not implement this proposal: It forces the problem of binary compatibility on the app developer, when experience has shown us that problem is better handled by the libraries. Binary Compatibility “Binary compatibility” is the notion that, even if the libraries y

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

> On Dec 19, 2017, at 2:58 PM, Ted Kremenek via swift-evolution > wrote: > > The review of "SE 0192 - Non-Exhaustive Enums" begins now and runs through > January 3, 2018. > > The proposal is available here: > > https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive

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

I think I speak for the entire Swift community when I say that Swift's enums, together with the ability to switch over them exhaustively and having compile-time guarantees, is one of the best features in Swift. I'm regularly annoyed by this when writing other languages like Java and JS (default:

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

Hello I would like to give a feedback on this SE, In the proposal, it stats that In the initial discussion, multiple people were unhappy with the loss of compiler warnings for switches over non-exhaustive enums that comes with using default—they wanted to be able to handle all cases that exist t

Re: [swift-evolution] [swift-evolution-announce] [REVIEW] SE-0193 - Cross-module inlining and specialization

I was going to write up a detailed response to this as well, but Chris did it for me. In general, I agree that we need the feature. However, I believe that the name “ABI” is too specific and does not accomplish the primary purpose of naming this thing — which is to allow people to understand w

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

> On Dec 19, 2017, at 2:58 PM, Ted Kremenek via swift-evolution > wrote: > The review of "SE 0192 - Non-Exhaustive Enums" begins now and runs through > January 3, 2018.The proposal is available here: > > https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md

[swift-evolution] Should we incorporate bunches of new operators / micro-syntactic sugar?

Dear all, That’s not ambitious but i think worth be explored. What do you think for example of this Infix operator? « =? » allows to express optional assignments in a very concise way. // The `=? operator allows simplify optional assignements : // `a = b ?? a` can be written : `a =? b` infix

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

Oops, I meant to post this on a separate thread. Sorry. Sincerely, Natchanon ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

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

Before answering above, I would like to add Since the users of the library will likely not accommodate the new cases (as it doesn’t exist yet), the `default/future` case will then not provide any real usage other than throwing exceptions. So the user will still need to update the code to actuall

Re: [swift-evolution] [REVIEW] SE-0193 - Cross-module inlining and specialization

> On 21 Dec 2017, at 4:06 pm, Johannes Weiß via swift-evolution > wrote: > >> >> On 21 Dec 2017, at 12:19 am, Ted Kremenek via swift-evolution >> wrote: >> >> The review of "SE-0193 - Cross-module inlining and specialization" begins >> now and runs through January 5, 2018. >> >> The prop

Re: [swift-evolution] [REVIEW] SE-0193 - Cross-module inlining and specialization

> On 21 Dec 2017, at 12:19 am, Ted Kremenek via swift-evolution > wrote: > > The review of "SE-0193 - Cross-module inlining and specialization" begins now > and runs through January 5, 2018. > > The proposal is available here: > > https://github.com/apple/swift-evolution/blob/master/proposal

Re: [swift-evolution] Evaluating the case of an enum with associated values as a bool

IIRC what we discussed was synthesizing members of type Optional which could then be checked against nil. if _ = x.failure { ... } if x.failure != nil { ... } if let r = x.success {...} IMO synthesizing predicates would be a huge missed opportunity by comparison Sent from my iPhone > On Dec

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

I can see why this is useful, and understand the problem. However, it does feel like the wrong solution to a real problem. This seems to be very similar to the *expression problem*: > The expression problem is a new name for an old problem.[2][3] The goal is to define a datatype by cases, where on

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

> On 21 Dec 2017, at 05:16, Brent Royal-Gordon via swift-evolution > wrote: > >> On Dec 19, 2017, at 2:58 PM, Ted Kremenek via swift-evolution >> wrote: >> >> • What is your evaluation of the proposal? > > I am pleased with the broad strokes of this design. I have quibbles with > thr

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

+1 on @frozen and John’s reasoning. > On 21. Dec 2017, at 04:32, John McCall via swift-evolution > wrote: > >> >> On Dec 20, 2017, at 10:16 PM, Brent Royal-Gordon via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >>> On Dec 19, 2017, at 2:58 PM, Ted Kremenek via swift-evol

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

FWIW also +1 for @frozen (and actually +1 for everything Brent said) On 21.12.2017 14:28, Jonathan Hull via swift-evolution wrote: +1 for @frozen On Dec 20, 2017, at 7:16 PM, Brent Royal-Gordon via swift-evolution wrote: On Dec 19, 2017, at 2:58 PM, Ted Kremenek via swift-evolution wrote

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

> On 20 Dec 2017, at 9:58 am, Ted Kremenek via swift-evolution > wrote: > > The review of "SE 0192 - Non-Exhaustive Enums" begins now and runs through > January 3, 2018. > > The proposal is available here: > > https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive

Re: [swift-evolution] Evaluating the case of an enum with associated values as a bool

There was a similar thread early this year which I tried to resurrect like a month ago. In my reply I suggested freeing pattern matching from control statements and allowing any pattern matching expression to be evaluated as a boolean. Let me quote what I wrote there: << { case success(T)

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

+1 for @frozen > On Dec 20, 2017, at 7:16 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> On Dec 19, 2017, at 2:58 PM, Ted Kremenek via swift-evolution >> wrote: >> >> • What is your evaluation of the proposal? > > I am pleased with the broad strokes of this design. I have qui

Re: [swift-evolution] Evaluating the case of an enum with associated values as a bool

> On 20 Dec 2017, at 20:24, Ethan Diamond via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > > Sorry all for attaching the original post to the Non-Exhaustive enums thread. > I"m moving it down to it's own thread. > > My understanding is I'm not allowed to write up a proposal

Re: [swift-evolution] [swift-evolution-announce] [REVIEW] SE-0193 - Cross-module inlining and specialization

+1 thanks for your response Chris, it seems to me that it addresses the need this PR is trying to address and it does make it so in a scalable way. I would strongly hope your feedback is added to the proposal and shapes the final solution. Sent from my iPhone > On 21 Dec 2017, at 07:14, Chris