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

> What is your evaluation of the proposal? > +1 if a `future` case (or similar solution… “unknown” might be a nice keyword, although some enums probably have an `.unknown` case which could be confusing) is added. > Is the problem being addressed significant enough to warrant a change to >

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

Hi guys, I am part of the people mentioned in "Preserve exhaustiveness diagnostics for non-exhaustive enums" : I see the completeness check as a major feature of enums, that makes a difference between it and a list of constants in multiple cases. So much that in the coding rules of the company

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

> On Dec 20, 2017, at 1:00 AM, Sebastian Hagedorn via swift-evolution > wrote: > >> The expectation is that switches over non-exhaustive enums are uncommon. > > > Basically every time I interact with an enum, I switch over it, to make sure > I don’t forget

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

> > What is your evaluation of the proposal? > > +1 it solves an important problem in our ecosystem. > Is the problem being addressed significant enough to warrant a change to > Swift? > > Yes > Does this proposal fit well with the feel and direction of Swift? > > This is weird because I

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

Thanks for your thoughts. I think 3) is indeed a very common case, but also not affected by this proposal or the general issue at all. Unless I’m missing something, I think it makes sense to limit the discussion to those enums that are typically switched over in client code. I don’t think 1)

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

Should there be some kind of diagnostic if you have an @abiPublic definition that is never referenced by any @inlinable function? I can imagine that there might be tools to check that a new build of a module doesn’t break binary compatibility by verifying that you didn’t remove any @abiPublic

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

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 about, and check for bugs in, > the combinatorial explosion of old and new implementations that could exist > simultaneously

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

> On Dec 20, 2017, at 10:17 PM, Adam Kemp via swift-evolution > wrote: > > Should there be some kind of diagnostic if you have an @abiPublic definition > that is never referenced by any @inlinable function? I can imagine that there > might be tools to check that a

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

> On Dec 20, 2017, at 10:34 PM, Slava Pestov via swift-evolution > wrote: > >> Perhaps a diagnostic like this would cause problems if you started with an >> @inlinable function that called an @abiPublic function and then in a >> subsequent version of your module

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: > >

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

> On Dec 20, 2017, at 4:19 PM, Ted Kremenek wrote: > > The review of "SE-0193 - Cross-module inlining and specialization" begins now > and runs through January 5, 2018. > > The proposal is available here: > >

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

Hi Brent, > On Dec 20, 2017, at 9:35 PM, Brent Royal-Gordon via swift-evolution > wrote: > > I concur. If we don't care about its ungainly size, the blindingly obvious > solution would be `@inlineCallable`. Another solution might be to declare the > symbol with a

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

> On Dec 20, 2017, at 4:19 PM, 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: > >

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

This seems like a problem worth solving — or rather worth making the solution public, since this is already in use as an undocumented feature! A concern: how would a library author reason about, and check for bugs in, the combinatorial explosion of old and new implementations that could exist

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

> On Dec 20, 2017, at 7:01 PM, Xiaodi Wu via swift-evolution > wrote: > > My one bikeshedding issue here is the name @abiPublic, which smells too much > like fileprivate in my subjective opinion. A more concrete objection here is > the very much non-ideal

Re: [swift-evolution] [Proposal] Random Unification

I'd like to add a pointer to the information here: http://xoroshiro.di.unimi.it since AFAICS, the xoroshiro128+ generator and the method of "Generating uniform doubles in the unit interval" should probably be implemented in any modern general purpose Random API. Please correct me if there are

[swift-evolution] [Pitch] @static imports

There’s a lot of talk in the non-exhaustive enum discussion about the source transition. So let me suggest a possible solution: @static imports. Basically, it seems to me like resilience is going to introduce a lot of indirection, both in generated instructions and in the language. I think that

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

> On 20. Dec 2017, at 14:36, Karl Wagner wrote: > > > >> On 19. Dec 2017, at 23:58, Ted Kremenek via swift-evolution >> > wrote: >> >> The review of "SE 0192 - Non-Exhaustive Enums" begins now and runs through

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

On 20.12.2017 1:58, 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 Reviews

Re: [swift-evolution] [Proposal] Random Unification

xoroshiro128+ is not a cryptographically secure algorithm and would not be incorporated into the Random API, though it is trivial to implement your own; the proposal outlines sources of randomness that are cryptographically secure. On Wed, Dec 20, 2017 at 09:46 Jens Persson via swift-evolution <

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

Hello everyone, One major pain point I've run into with Swift is the inability to evaluate the case of an enum that has associated values in a way that just returns a bool. We've been given the ability in a switch statement: enum Enum { case a(param: String) case b(param: String) } let

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

I thought I would add another case that isn’t possible with current syntax (so far as I’m aware). You can’t negate the comparison to do something for all cases except a particular case. You have to have an empty if block and use the else block, or have an empty case in a switch statement and

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] [Proposal] Random Unification

Oh OK, I must have misunderstood this thread: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171204/042034.html ( "The strong opinion of the core team is that such an API should *not* be designed with an attempt to service people writing crypto code." "It is general goodness if

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

I very much agree with the motivations for this proposal. It identifies a clear, urgent need. I disagree that the proposed solution is a good solution. It makes a very significant, and confusing, change to the language that does not have much precedent in other languages. This goes against the

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

I agree this would be useful. At the moment I have to hack around it with things like `var isFoo: Bool { if case .foo = self …`* with cases I commonly need, but this is definitely a feature that has come up before and I support. It is potentially related to getting the values through an

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

> On Dec 19, 2017, at 3: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: > >

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

This would be easily solved if pattern matching was available as an expression, such as in Haskell, OCaml / Standard ML, and Scala / Kotlin. :-) > On Dec 20, 2017, at 11:44 AM, Ethan Diamond via swift-evolution > wrote: > > Hello everyone, > > One major pain point

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

> On Dec 19, 2017, at 2:58 PM, Ted Kremenek via swift-evolution > wrote: > When reviewing a proposal, here are some questions to consider: > > What is your evaluation of the proposal? > Strong -1 as is. I think I would support having an explicit ‘futureCase’ which

Re: [swift-evolution] [Proposal] Random Unification

On Wed, Dec 20, 2017 at 13:13 Jens Persson wrote: > Oh OK, I must have misunderstood this thread: > > https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171204/042034.html > ( > "The strong opinion of the core team is that such an API should *not* be > designed

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 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

> 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

Proposal link:  https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md What is your evaluation of the proposal? -1. Is the problem being addressed significant enough to warrant a change to Swift? I’m afraid not. >From my perspective as a Swift user, this

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

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 makes sense to make the enums non-exhaustive as the apps are

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

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 unless I have the time to implement it. Is that still true? This is a major pain point for me to avoid having to write

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

> 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 > define a library's API. Polymorphic variants are ad-hoc union types

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

In the past, we’ve discussed synthesizing predicate members onto enums. E.g. given: enum E { case X case Y(Int) } you’d get something like: extension E { func isX() -> Bool { return self == .X } func getY() -> Int? { … } } which would solve the client side of this nicely. -Chris

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

> On Dec 20, 2017, at 1:36 PM, Chris Lattner via swift-evolution > wrote: > >> On Dec 19, 2017, at 11:26 PM, Douglas Gregor wrote: >> >>> Beyond that, they are small extensions with low complexity, scale to >>> supporting many different dynamic

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

> On Dec 19, 2017, at 11:26 PM, Douglas Gregor wrote: > >> Beyond that, they are small extensions with low complexity, scale to >> supporting many different dynamic languages over time, require a level of >> engineering effort that is plausible to be built, and do not

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

> I am part of the people mentioned in "Preserve exhaustiveness diagnostics for > non-exhaustive enums" : I see the completeness check as a major feature of > enums, that makes a difference between it and a list of constants in multiple > cases. > So much that in the coding rules of the

Re: [swift-evolution] [Pitch] @static imports

Hi Karl, This is an interesting idea and part of something we would like to explore in the future, which is resilience domains that span more than one module. However keep in mind that in the current design, resilience is something you opt into when building a library, with a compiler flag. If

Re: [swift-evolution] [Pitch] @static imports

> On Dec 20, 2017, at 8:56 AM, Karl Wagner via swift-evolution > wrote: > > There’s a lot of talk in the non-exhaustive enum discussion about the source > transition. So let me suggest a possible solution: @static imports. > > Basically, it seems to me like

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

Would that synthesize an isY() even though .Y has an associated value there? enum E { case X case Y(Int?) } If I had to run that through getY() -> Int??, it still wouldn't be quite what I was looking for with regards to intent. If you are planning an doing an isY though, that would work

Re: [swift-evolution] [Pitch] @static imports

> On 20. Dec 2017, at 22:30, Slava Pestov via swift-evolution > wrote: > > Hi Karl, > > This is an interesting idea and part of something we would like to explore in > the future, which is resilience domains that span more than one module. > > However keep in

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

> On Dec 20, 2017, at 2:12 PM, Ethan Diamond wrote: > > Would that synthesize an isY() even though .Y has an associated value there? I’m not aware of a concrete design for this idea. The details would definitely need to be figured out, but I don’t see why a double

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

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/proposals/0193-cross-module-inlining-and-specialization.md Reviews are an important part of the

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

It feels like it solves my current problem in a way that's almost as undesirable as the current solution. Say I have: Enum A { case x(String?) case y(String) } Right now I have code like this peppered throughout my code, which I think we can agree is pretty undesirable: if let case .x =

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

On Wed, Dec 20, 2017 at 18:19 Ted Kremenek via swift-evolution < swift-evolution@swift.org> wrote: > The review of "SE-0193 - Cross-module inlining and specialization" begins > now and runs through *January 5, 2018*. > > The proposal is available here: > > >

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

On Wed, Dec 20, 2017 at 10:01 PM, Xiaodi Wu via swift-evolution < swift-evolution@swift.org> wrote: > > I have been doing the unkosher thing of using these underscored attributes > and would very much like to see these formalized. > > My one bikeshedding issue here is the name @abiPublic, which

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

> 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 three areas: 1. The `@exhaustive` attribute may be confusing

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

Hi Xiaodi, Thanks for taking the time to look over the proposal. > On Dec 20, 2017, at 7:01 PM, Xiaodi Wu via swift-evolution > wrote: > > Does this proposal fit well with the feel and direction of Swift? > > Yes, with a caveat. It seems a little unfortunate that

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

> On Dec 20, 2017, at 10: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

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

Hi Nevin, Thanks for taking the time to review the proposal! > On Dec 20, 2017, at 7:08 PM, Nevin Brackett-Rozinsky via swift-evolution > wrote: > > Alternatively, since the “@abiPublic” attribute allows objects to be used by > inlined code, why not spell it

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

On Wed, Dec 20, 2017 at 4:19 PM Ted Kremenek via swift-evolution < swift-evolution@swift.org> wrote: > The review of "SE-0193 - Cross-module inlining and specialization" begins > now and runs through *January 5, 2018*. > > The proposal is available here: > > >

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

Hi Tony, Thanks for the review! > On Dec 20, 2017, at 8:09 PM, Tony Allevato via swift-evolution > wrote: > > A related question (with some background): My assumption is that conditional > compilation directives (e.g., #if DEBUG) are resolved *before* an @inlinable

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

Thanks for the review, Kelvin. > On Dec 20, 2017, at 8:52 PM, Kelvin Ma via swift-evolution > wrote: > > it makes sense to have @abiPublic on private and fileprivate declarations too > and i hope this gets added, because private and fileprivate are tools for > code

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

glad to see this finally moving forward! On Wed, Dec 20, 2017 at 6:19 PM, Ted Kremenek via swift-evolution < swift-evolution@swift.org> wrote: > The review of "SE-0193 - Cross-module inlining and specialization" begins > now and runs through *January 5, 2018*. > > The proposal is available here: