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

I read: Ma.allValues.count // returns 8 But that sounds like all values will need to be computed in order to get the count, so some people will be tempted to write: Ma.lazy.allValues.count // returns 8 To avoid that, it may be nicer to make enum `Ma` behaves like a collection directly, so

Re: [swift-evolution] [Proposal] Revamp the playground quicklook APIs

Saagar Jha > On Jan 9, 2018, at 22:02, Chris Lattner via swift-evolution > wrote: > > On Jan 9, 2018, at 3:19 PM, Connor Wakamo via swift-evolution > > wrote: >> Good afternoon, > > Hi Connor, > > Huge

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

And what about, as an alternative: case (_, #unknown): … matches any int and any unknown enum case ... case _: … matches anything ... Then it clearly goes the "pattern matching" way. Le mer. 10 janv. 2018 à 14:17, Chris Lattner via swift-evolution < swift-evolution@swift.org> a écrit : > On

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

On Jan 9, 2018, at 10:26 PM, Xiaodi Wu via swift-evolution wrote: > My objection to the "ValueEnumerable" design--especially in its generalized > form here (versus "CaseEnumerable")--is that the protocol's semantics (and, > we'll recall, protocols in Swift must offer

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

Disclaimer: I’m reordering your comments below to suit my nefarious purposes: :-) On Jan 9, 2018, at 3:48 PM, Ben Cohen wrote: >> More to the point though, this seems like an implementation detail of >> Mirrors. What is the plan for Mirrors + ABI stability? >> > >

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

On Mon, Jan 8, 2018 at 1:02 PM, Douglas Gregor via swift-evolution < swift-evolution@swift.org> wrote: > Hello Swift community, > > The review of SE-0194 "Derived Collection of Enum Cases" begins now and > runs through January 11, 2018. The proposal is available here: > >

Re: [swift-evolution] Proposal: Add a sequence-based initializer to Dictionary

> On Jan 8, 2018, at 3:23 PM, Gregg Wonderly via swift-evolution > wrote: > > But why wouldn’t the key also be available so that you might be able to have > selective handling of first vs last for each key? Having only the values allows you to do some nice

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

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

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

On Tue, Jan 9, 2018 at 5:12 AM, Jonathan Hull via swift-evolution < swift-evolution@swift.org> wrote: > Some thoughts: > > - How do I randomly select an enum? > carefully, of course > > - I like that RandomNumberGenerator doesn’t have an associated type. I > agree that we should just spit out

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

On Jan 9, 2018, at 3:07 PM, Jose Cheyo Jimenez wrote: > Hi Chris, > > This is great. Thanks for spending time on this! I am in favor of `case > #unknown` to only match unknown cases. > > 1) Would #uknown be available to RawRepresentable structs? I haven’t considered

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

On Jan 9, 2018, at 12:27 PM, Vladimir.S wrote: >> 2) Swift also has other facilities for pattern matching, including ‘if >> case’. Making switch inconsistent with them is not great. >> 3) As pitched, “unknown case” will match *known* cases too, which is (in my >> opinion :-)

Re: [swift-evolution] [Proposal] Revamp the playground quicklook APIs

On Jan 9, 2018, at 3:19 PM, Connor Wakamo via swift-evolution wrote: > Good afternoon, Hi Connor, Huge +1 for this proposal, I’m thrilled you’re cleaning this up. Couple of detail questions: > >

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

I'm not in favor to distinguish #unknown and #known, as it may lead to surprises, like something that previously was unknown becomes known on a newer iOS version for instance. And version-dependant code is clearer if solely handled by the `@available()` syntax. I like the new pattern matching

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

> On Jan 9, 2018, at 4:46 PM, Jordan Rose via swift-evolution > wrote: > > - FWIW I can't actually think of a use case for using this with `if case` or > anything else. I'm not against it, but I don't know why you would ever do it, > just like I don't know why you

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

> On Jan 9, 2018, at 9:04 PM, Brent Royal-Gordon via swift-evolution > wrote: > > The problem is that this isn't currently expressible in the type system. If > we can, I would actually support including some kind of unprincipled private > hack so we could say `where

Re: [swift-evolution] [swift-dev] Re-pitch: Deriving collections of enum cases

> On Jan 8, 2018, at 11:02 AM, Robert Widmann via swift-evolution > wrote: > > As you note, integral types and Bool and some enums that fall outside the > scope of the synthesis requirements fit this mold quite nicely. We do not > include them in the proposal

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

Oops. Kindly disregard my previous emails. Ben was kind enough to point out to me that I was confusing dictionary literals with DictionaryLiteral On Tue, Jan 9, 2018 at 8:56 PM, Ben Cohen <> wrote: > Hi Charles, > > The naming issue strikes again :) > > Your code is making use of dictionary

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

> On Jan 8, 2018, at 4:29 PM, Ben Cohen via swift-evolution > wrote: > > I’m canvassing for opinions on what it ought to be called. Some suggestions > so far: > > - `AssociationCollection`: Following the term of art from some other > languages. Slightly

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

Hi Nevin (et al) Here's the relevant section of my code. It's from a protocol I use called "ParameterSet" to extend OptionSets to contain small numbers (like an Enum with an associated type, but all the data is stored in the UInt). Wouldn't be my first choice to share, as it breaks KISS. Anyhow,

Re: [swift-evolution] Incremental ABI stability

+1000 I would like to be even more conservative, only locking down the things we know we have received actual human attention of some sort. The all-or-nothing approach is actively harmful in my mind. Thanks, Jon Sent from my iPhone > On Jan 9, 2018, at 6:30 PM, Nevin Brackett-Rozinsky via

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

On Tue, Jan 9, 2018 at 9:27 PM, Hooman Mehr via swift-evolution < swift-evolution@swift.org> wrote: > I think this type might become more useful if we find a good name for it > and better document it. For example, it is a natural fit for parameter list > of Chris’ callable type proposal. > >

[swift-evolution] Incremental ABI stability

I’m just spitballing here, and I’m not an expert on matters of ABI, however the thought occurs to me that the current all-or-nothing approach might lead to suboptimal results. In particular, some recent discussions on this list have mentioned that certain parts of the standard library, such as

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

I think this type might become more useful if we find a good name for it and better document it. For example, it is a natural fit for parameter list of Chris’ callable type proposal. Since this type accepts duplicate “keys” and does not provide key-based lookup, the first thing that deserves a

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

On Tue, Jan 9, 2018 at 7:47 PM, char...@charlesism.com < charlesism@gmail.com> wrote: > I used a DictionaryLiteral only yesterday, and it turned what would have a > typically unreadable array of Structs into something much more elegant. I'm > pretty sure the only reason Literals (of all

Re: [swift-evolution] [Proposal] Revamp the playground quicklook APIs

> On Jan 9, 2018, at 4:21 PM, Ben Rimmington wrote: > > Something like this was attempted (and reverted) for Swift 3: > > > >

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] 100% bikeshed topic: DictionaryLiteral

I used a DictionaryLiteral only yesterday, and it turned what would have a typically unreadable array of Structs into something much more elegant. I'm pretty sure the only reason Literals (of all varieties) aren't used more often is because Swift programmers don't realize they are available and

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] [Proposal] Revamp the playground quicklook APIs

Something like this was attempted (and reverted) for Swift 3:

Re: [swift-evolution] [Proposal] Revamp the playground quicklook APIs

Yes, it will — if a type does not conform to `CustomPlaygroundRepresentable`, PlaygroundLogger will continue to log it structurally. Connor > On Jan 9, 2018, at 3:56 PM, Saagar Jha wrote: > > I’ve just glanced through this, so I apologize if this was already addressed,

Re: [swift-evolution] [Proposal] Revamp the playground quicklook APIs

Big +1 to this. Getting these types out of the standard library and into a more suitable domain-specific framework, prior to declaring ABI Stability, will give us flexibility to evolve them appropriately over time. > On Jan 9, 2018, at 3:19 PM, Connor Wakamo via swift-evolution >

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

> On Jan 9, 2018, at 11:48 AM, Chris Lattner wrote: > >> On Jan 9, 2018, at 10:23 AM, Ben Cohen wrote: The old name can live on indefinitely via a typealias (which has no ABI consequences, so could be retired at a later date once

[swift-evolution] [Proposal] Revamp the playground quicklook APIs

Good afternoon, In preparation for ABI stability, I’ve reviewed the API exposed by the standard library for providing customized “quick looks” in playgrounds. This is exposed as the PlaygroundQuickLook enum and the CustomPlaygroundQuickLookable protocol. The PlaygroundQuickLook has a handful

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

Hi Chris, This is great. Thanks for spending time on this! I am in favor of `case #unknown` to only match unknown cases. 1) Would #uknown be available to RawRepresentable structs? 2) How is the #uknown pattern accomplished? Are you suggesting to capture all the compile time known cases so you

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

On 09.01.2018 21:43, Kevin Nattinger via swift-evolution wrote: Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0194-derived-collection-of-enum-cases.md *

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

> On Jan 9, 2018, at 8:28 AM, Nate Cook wrote: > >> On Jan 9, 2018, at 4:12 AM, Jonathan Hull > > wrote: >> >> Some thoughts: >> >> - How do I randomly select an enum? > > Vote for SE-0194! :) > >> - I like that

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

Something like `#unknown` or `#undiscovered` in the pattern matching syntax makes complete sense. -Richard > 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 >

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

Hi Chris, thank you for the new idea! FWIW, after first reading, it looks like more elegant solution than "unknown case" in initial proposal. Swift's enums deserve powerful and flexible solution! I really like the syntax of switch val { case .one: ... case .two: ... case #unknown: ... }

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

> On Jan 9, 2018, at 10:43 AM, Kevin Nattinger via swift-evolution > wrote: > >> Proposal link: >> >> https://github.com/apple/swift-evolution/blob/master/proposals/0194-derived-collection-of-enum-cases.md >> >> What is your evaluation of the proposal? > +1 on the

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

> On Jan 9, 2018, at 10:23 AM, Ben Cohen wrote: >>> >>> The old name can live on indefinitely via a typealias (which has no ABI >>> consequences, so could be retired at a later date once everyone has had >>> plenty of time to address the deprecation warnings). Removing it

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

> On Jan 9, 2018, at 8:16 AM, Zach Waldowski via swift-evolution > wrote: > > I'm not sure a valid use case by a third party makes it hold its weight for > inclusion in the stdlib. Reproducing its feature set is extremely trivial, > and would probably allow you to

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

> On Jan 9, 2018, at 11:01 AM, Ben Cohen via swift-evolution > wrote: > > > >> On Jan 9, 2018, at 2:12 AM, Jonathan Hull via swift-evolution >> > wrote: >> >> - Why bother supporting non-closed Ranges

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

> On Jan 9, 2018, at 2:12 AM, Jonathan Hull via swift-evolution > wrote: > > - Why bother supporting non-closed Ranges at all? If you only allow closed > ranges, then you can’t end up with an empty range. The only difference in > behavior I can think of is on

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

> Proposal link: > > https://github.com/apple/swift-evolution/blob/master/proposals/0194-derived-collection-of-enum-cases.md > > >

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

> On Jan 8, 2018, at 10:12 PM, Chris Lattner wrote: > > >> On Jan 8, 2018, at 4:29 PM, Ben Cohen via swift-evolution >> > wrote: >> There exists in the standard library a type `DictionaryLiteral` that >>

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

> > What is your evaluation of the proposal? +1 it’s something I often hack myself > 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? Yes - I think it will encourage the use of enumerations

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

I’m overall +1, but I’m curious: would you be able to conform an enum from another module to ValueEnumerable via an extension, and still have the compiler generate the protocol requirements for you? I can imagine that the client of a framework with an enum may have a valid use for iterating

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

> Le 9 janv. 2018 à 18:18, Nate Cook a écrit : > >> On Jan 9, 2018, at 11:00 AM, Gwendal Roué via swift-evolution >> > wrote: >> >>> >>> Le 9 janv. 2018 à 17:16, Zach Waldowski via swift-evolution >>>

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

Now that I think of it, this type would be great for storing results from a SQL query run on a database, for instance. This is a valid SQL statement: SELECT `firstname`, `lastname`, `firstname` FROM `employees`; Note there is two copies of “firstname”. Don’t ask why. All that matters is that

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

How about renaming DictionaryLiteral to Row, TabularRow or TableRow? I think most developers are familiar with the idea that a table row contains multiple columns (in specific order), and each column has a name and a value (key/value). Some other name suggestions: - Record (kind of an old name

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

> On Jan 9, 2018, at 11:00 AM, Gwendal Roué via swift-evolution > wrote: > >> >> Le 9 janv. 2018 à 17:16, Zach Waldowski via swift-evolution >> > a écrit : >> >> I'm not sure a valid use case by a third

Re: [swift-evolution] [swift-corelibs-dev] Discourse rollout re-schedule

Hi Nicole, > Am 15.12.2017 um 03:59 schrieb Nicole Jacque via swift-corelibs-dev > : > > Hi All- > > First of all, a big thank you to everyone who has provided feedback on our > prototype Discourse forum. Based on the fact that we’re still receiving > feedback,

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

> Le 9 janv. 2018 à 17:16, Zach Waldowski via swift-evolution > a écrit : > > I'm not sure a valid use case by a third party makes it hold its weight for > inclusion in the stdlib. You're definitely right, and that's why I wrote with the most humble tone I could.

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

Having reviewed much of the commentary on this proposal, I keep coming back to the same thought: why not use @versioned and @available keywords for this instead of some concept related to “exhaustive”? The issue here is not whether a given enum is “exhaustive” over the enumerated problem

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

On Mon, Jan 8, 2018 at 11:02 AM Douglas Gregor via swift-evolution < swift-evolution@swift.org> wrote: > Hello Swift community, > > The review of SE-0194 "Derived Collection of Enum Cases" begins now and > runs through January 11, 2018. The proposal is available here: > > >

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

> On Jan 9, 2018, at 4:12 AM, Jonathan Hull wrote: > > Some thoughts: > > - How do I randomly select an enum? Vote for SE-0194! :) > - I like that RandomNumberGenerator doesn’t have an associated type. I agree > that we should just spit out UInt64s for simplicity. It

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

> On Jan 9, 2018, at 3:12 AM, Jonathan Hull via swift-evolution > wrote: > > Some thoughts: > > - How do I randomly select an enum? Well… combine this with SE-0194 and you have all the basics you need: the set of all enum values in a collection, and a way to pick

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

On Tue, Jan 9, 2018 at 05:12 Jonathan Hull via swift-evolution < swift-evolution@swift.org> wrote: > Some thoughts: > > - How do I randomly select an enum? > > - I like that RandomNumberGenerator doesn’t have an associated type. I > agree that we should just spit out UInt64s for simplicity. > > -

Re: [swift-evolution] Renaming SwiftObject

Well, there’s always the option of Swift._NonObjcSwiftObject…but to be honest what this class looks like from the Swift side is much less of a concern to me. Getting “Swift” in the mangled name is probably good enough. Saagar Jha > On Jan 8, 2018, at 15:00, Greg Parker