Re: [swift-evolution] ValueEnumerable protocol with derived implementation for enums

> To me, it seems that a "magic protocol" with no public requirements, > producing an internal (non-resilient) static array, is a reasonable solution > that might be able to fit into the Swift 3 timeframe, and I think that'd be a > huge boon to language users. I also don't think it precludes fur

Re: [swift-evolution] ValueEnumerable protocol with derived implementation for enums

> Personally, I'm fine with ValuesEnumerable being a "magic protocol" like > ErrorProtocol, because the most important use case is being able to write > e.g. `NSTextAlignment.allValues` with a compiler-provided implementation. A > proper associatedtype declaration can come later, once generics are

Re: [swift-evolution] ValueEnumerable protocol with derived implementation for enums

...1 month passes... On Mon, Apr 25, 2016 at 8:31 AM, Vladimir.S via swift-evolution < swift-evolution@swift.org> wrote: > Sorry, if was discussed earlier, tried to find in conversations in this > thread but didn't find: > > Could someone please briefly describe why "community is in agreement" -

Re: [swift-evolution] ValueEnumerable protocol with derived implementation for enums

Sorry, if was discussed earlier, tried to find in conversations in this thread but didn't find: Could someone please briefly describe why "community is in agreement" - "The "allValues" behavior should be provided by conformance to some protocol" ? I mean, what is purpose of the protocol? What e

Re: [swift-evolution] ValueEnumerable protocol with derived implementation for enums

If you wrote: enum Ex { case one, two, three } And the compiler translated that into the equivalent of: - struct Ex : OptionSetType { - let rawValue: UInt - init(rawValue: UInt

Re: [swift-evolution] ValueEnumerable protocol with derived implementation for enums

> On Apr 22, 2016, at 11:48 PM, Jacob Bandes-Storch wrote: > On Fri, Apr 22, 2016 at 11:34 PM, John McCall > wrote: >> On Apr 22, 2016, at 11:11 PM, Jacob Bandes-Storch > > wrote: >> On Fri, Apr 22, 2016 at 10:50 PM, John McCall >

Re: [swift-evolution] ValueEnumerable protocol with derived implementation for enums

On Fri, Apr 22, 2016 at 11:34 PM, John McCall wrote: > On Apr 22, 2016, at 11:11 PM, Jacob Bandes-Storch > wrote: > On Fri, Apr 22, 2016 at 10:50 PM, John McCall wrote: > >> >> I have not been following this discussion, but I would be extremely antsy >> about guaranteeing any particular represe

Re: [swift-evolution] ValueEnumerable protocol with derived implementation for enums

> On Apr 22, 2016, at 11:11 PM, Jacob Bandes-Storch wrote: > On Fri, Apr 22, 2016 at 10:50 PM, John McCall > wrote: > > I have not been following this discussion, but I would be extremely antsy > about guaranteeing any particular representation for the set of values.

Re: [swift-evolution] ValueEnumerable protocol with derived implementation for enums

On Fri, Apr 22, 2016 at 10:50 PM, John McCall wrote: > > I have not been following this discussion, but I would be extremely antsy > about guaranteeing any particular representation for the set of values. > Guaranteeing a contiguous array implementation seems like a really bad > idea, especially

Re: [swift-evolution] ValueEnumerable protocol with derived implementation for enums

> On Apr 22, 2016, at 10:18 PM, Jacob Bandes-Storch wrote: > On Sat, Apr 16, 2016 at 5:20 AM, plx via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > > > My 2c is that if this is to go in the standard library, it should be done > “right”, which would be more like this version of

Re: [swift-evolution] ValueEnumerable protocol with derived implementation for enums

On Sat, Apr 16, 2016 at 5:20 AM, plx via swift-evolution < swift-evolution@swift.org> wrote: > > > My 2c is that if this is to go in the standard library, it should be done > “right”, which would be more like this version of it: > > protocol ValueEnumerable { > associatedtype ValueCollection : C

Re: [swift-evolution] ValueEnumerable protocol with derived implementation for enums

On Sat, Apr 16, 2016 at 3:56 AM, Brent Royal-Gordon wrote: > (I favor "Values" because "Value" in the singular implies to me that you > can take a single value and enumerate it somehow, which is not what I have > in mind.) > OK, after reading it this way long enough, I'm on board with that. Anyw

Re: [swift-evolution] ValueEnumerable protocol with derived implementation for enums

On 16.04.2016 5:00, Jacob Bandes-Storch via swift-evolution wrote: I believe the community is in agreement about the following: • The "allValues" behavior should be provided by conformance to some protocol, named ValueEnumerable or ValuesEnumerable or similar. • The compiler should deri

Re: [swift-evolution] ValueEnumerable protocol with derived implementation for enums

Re. OptionSetType If you wrote: enum Ex { case one, two, three } The compiler could do: - struct Ex : OptionSetType { - private let weight: Int - private init(_ weight: Int

Re: [swift-evolution] ValueEnumerable protocol with derived implementation for enums

> On Apr 15, 2016, at 9:00 PM, Jacob Bandes-Storch via swift-evolution > wrote: > > This discussion is about a proposal for API to enumerate/count all possible > values of a type, particularly enums. The goal is to address potential issues > with an old proposal, so it can go up for review so

Re: [swift-evolution] ValueEnumerable protocol with derived implementation for enums

> • The "allValues" behavior should be provided by conformance to some > protocol, named ValueEnumerable or ValuesEnumerable or similar. > • The compiler should derive an allValues implementation for "simple" > enums (those without associated values). Agreed on my part. (I favor "Values

Re: [swift-evolution] ValueEnumerable protocol with derived implementation for enums

> I would suggest that ValuesEnumerable should expose allValues and the type of > allValues should be a custom OptionSet implementation that iterates in > declaration order. That would make sense if OptionSet were a generic type which took any integer-ish RawRepresentable (which I've advocated

Re: [swift-evolution] ValueEnumerable protocol with derived implementation for enums

I would suggest that ValuesEnumerable should expose allValues and the type of allValues should be a custom OptionSet implementation that iterates in declaration order. I base this preference on Java, that does exactly this and it works well in my experience. On Saturday, 16 April 2016, Jacob Bande

[swift-evolution] ValueEnumerable protocol with derived implementation for enums

This discussion is about a proposal for API to enumerate/count all possible values of a type, particularly enums. The goal is to address potential issues with an old proposal, so it can go up for review soon. Core Team / Standard Library Team feedback would be particularly welcome here, because we