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

[Hooman Mehr via swift-evolution]

A strong +1 on this approach instead of the current revision of SE-0194.

This is a very focused solution to a very focused need. It sidesteps the issues 
of a protocol based approach (potential for abuse or deciding/defining the 
intended uses of such protocol). Also, we already have the underpinnings of 
such literals, which makes it straightforward to implement. 

If we decide to do anything other than this, it will need a pretty strong 
argument.

This is also the least disrupting solution as it is basically what we are 
manually doing right now: We declare a static property that is nothing more 
than an array literal that captures cases that exist at the time of compilation 
in the source code order. We can just replace the manually written array 
literal with this one and be sure it will stay in sync, which minimizes 
overhead of transition for existing code and does not impose any particular 
style or arise the questions about the data type of this “collection”. (We can 
use any type that is `ExpressibleByArrayLiteral`)

We could also have a variant of this literal that would also capture the 
related metadata. For example, each element of the literal array could be 
tuples of each case value and another literal (an enum case maybe) that 
represents the availability metadata for that case.

Hooman

> On Jan 14, 2018, at 8:16 AM, Ben Rimmington via swift-evolution 
>  wrote:
> 
> An alternative is a special #knownCases(of:) literal.
> 
> Its value is an array literal of the enum cases known at compile time.
> 
> This could also work with enums imported from Objective-C.
> 
> -- Ben
> 
>> On 10 Jan 2018, at 22:54, Jordan Rose wrote:
>> 
>> [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 cannot conform to ValueEnumerable, just because 
>> imported enums won't. (But especially while knee-deep in SE-0192, I think 
>> it's correct that imported enums won't. The exception could be C enums 
>> marked `enum_extensibility(closed)`, but I'm not convinced we need that yet.)
>> 
>> The biggest problem I have is unavailable cases. An unavailable case must 
>> not be instantiated—consider an enum where some cases are only available on 
>> iOS and not macOS. (I bet we optimize based on this, which makes it all the 
>> more important to get right.)
>> 
>> I think you should explicitly call out that the derived implementation only 
>> kicks in when ValueEnumerable is declared on the enum itself, not an 
>> extension. Or if that's not the case, it should be limited to extensions in 
>> the same module as the enum. (You could add "unless the enum is '@frozen'", 
>> but that's not really necessary.)
>> 
>> I don't think this should be implemented with a run-time function; 
>> compile-time code generation makes more sense to me. But that's an 
>> implementation detail; it doesn't change the language surface.
>> 
>> Jordan
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ben Rimmington via swift-evolution]

An alternative is a special #knownCases(of:) literal.

Its value is an array literal of the enum cases known at compile time.

This could also work with enums imported from Objective-C.

-- Ben

> On 10 Jan 2018, at 22:54, Jordan Rose wrote:
> 
> [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 cannot conform to ValueEnumerable, just because 
> imported enums won't. (But especially while knee-deep in SE-0192, I think 
> it's correct that imported enums won't. The exception could be C enums marked 
> `enum_extensibility(closed)`, but I'm not convinced we need that yet.)
> 
> The biggest problem I have is unavailable cases. An unavailable case must not 
> be instantiated—consider an enum where some cases are only available on iOS 
> and not macOS. (I bet we optimize based on this, which makes it all the more 
> important to get right.)
> 
> I think you should explicitly call out that the derived implementation only 
> kicks in when ValueEnumerable is declared on the enum itself, not an 
> extension. Or if that's not the case, it should be limited to extensions in 
> the same module as the enum. (You could add "unless the enum is '@frozen'", 
> but that's not really necessary.)
> 
> I don't think this should be implemented with a run-time function; 
> compile-time code generation makes more sense to me. But that's an 
> implementation detail; it doesn't change the language surface.
> 
> Jordan
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

On Wed, Jan 10, 2018 at 5:06 AM, Brent Royal-Gordon 
wrote:

> On Jan 9, 2018, at 10:26 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I continue to have concerns about this proposal, and I'm gravely and very
> bitterly disappointed that the concerns have not even been acknowledged in
> the Alternatives section, which is in my view the minimum action that an
> author should take when points are raised during a pitch phase, even (and
> especially) when the author disagrees, along with a cogent write-up of why
> the proposed design is superior in the author's view to the alternative. In
> this case, the proposal authors write:
>
>   "The community has not raised any solutions whose APIs differ
> significantly from this proposal, except for solutions which provide
> strictly more functionality."
>
> This is false, as I have offered a solution in the past whose API differs
> entirely from this proposal, and which provides strictly a subset of the
> functionality which goes to the core of the issue at stake.
>
>
> I can't speak for the other co-authors, but for my part, this was an
> oversight and I apologize for it. I think we should have discussed your
> `MyType.self` alternative.
>
> I won't rehash the entire discussion in previous threads, but to summarize
> my objections:
>

Again, I do appreciate the detailed reply. Time is never enough, so I'll
try to be both concise and complete in my reply. Hopefully, it'll live up
to your example in terms of thoroughness.


> 1. `MyType.self` is harder to understand for someone who's never seen it
> than `MyType.allValues`. For instance, the expression
> `AccountStatus.allValues[0]` is completely self-explanatory, while
> `AccountStatus.self[0]` is more obscure and would require a trip to the
> documentation. (And since `self` here is a language keyword, not a real
> member, the most obvious route to the documentation is not available.) In
> my opinion, we should not prefer the `MyType.self` syntax.
>
> 2. Even if the community disagrees with me and thinks `MyType.self` is a
> better syntax than `MyType.allValues`, it is not better *enough* to
> outweigh the costs:
>
> • The metatype solution provides no additional functionality; it is merely
> a matter of which syntax we choose to support, and how much effort this
> support requires.
>
> • Conforming the metatype to `Collection` requires a lot of type system
> features we do not currently have. Currently, structural types cannot
> conform to protocols, and metatypes are a structural type. Metatypes also
> cannot have subscripts currently. Your proposed design has a lot of
> prerequisites. That is not in and of itself disqualifying, but it should be
> weighed against it.
>
> • You suggest that we should add bits and pieces of "`Collection`
> functionality" incrementally as engineering resources become available. The
> problem is that the most valuable part of the "`Collection` functionality"
> is conformance to `Collection` or at least `Sequence`, not the existence of
> any particular members of `Collection`, and this is the part that would
> require the most engineering resources.
>
> • A large part of the work we would do before supporting this conformance
> would be disposed of immediately once we could get it. For instance, all of
> the work to support having a metatype instead of a sequence in a `for-in`
> statement would be thrown away as soon as we could conform to `Sequence`.
> So this looks less like slowly building up pieces of the feature until we
> have all of them in place, and more like creating temporary hacks to
> emulate the feature until we have the time to do it right.
>
> • While this feature is not a showstopper, it is a highly desirable
> convenience. The proposal documents the high demand for this feature, so I
> won't elaborate on this point further.
>
> • Therefore, adopting this design would add a lot of engineering
> complexity before we could fully support a highly desirable feature, merely
> to get a syntax that we *might* prefer.
>
> To summarize the summary: The primary advantage of `MyType.self` is that
> it's elegant. To get that elegance, we must trade away getting a
> fully-functional implementation sooner, spending a lot of engineering
> resources (much of which would be wasted in the end), and—most crucially in
> my opinion—clarity at the point of use. It's not worth it.
>
>
Let me take two steps back, then address your points (1) and (2). One
overarching critique of mine is that you are conflating two (related)
features into one. The stated motivation is the desire to enumerate all the
cases of an enum (let's call this problem A). The presented solution
enlarges the problem to be solved to that of enumerating all the values of
a type (let's call this problem B, which is kind of (*) a superset of
problem A).

(*) More on the "kind of" part later.

It does not follow that simply because a solution to A is often requested,

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

[Paul Cantrell via swift-evolution]

> On Jan 11, 2018, at 11:42 PM, Brent Royal-Gordon  
> wrote:
> 
>> On Jan 11, 2018, at 4:21 PM, Paul Cantrell > > wrote:
>> 
>> This raises a question related to Chris’s: what is the utility of having 
>> Limb conform to a protocol instead of just providing allValues ad hoc? Does 
>> CaseEnumerable / ValueEnumerable serve any purpose other than triggering 
>> special behavior in the compiler? Would the protocol ever be used as the 
>> type of something in code?
>> 
>> My answers, admittedly weak ones, are: (1) conventions are nice and 
>> consistency is nice, and (2) you never know how an abstraction might be 
>> used, but you do know that people will be angry when it should fit but 
>> doesn’t. I can’t come up with a more compelling or specific argument than 
>> those.
> 
> Here's a place where you might want to use the protocol: Suppose you're 
> writing a table view data source that displays editable controls for a form. 
> You support several different types of controls, one of which is a list of 
> choices for a picker controller.
> 
>   enum Control {
>   case textField
>   case picker(choices: [Value])
>   …
>   
>   func makeView() -> UIView { … }
>   subscript(valueOf view: UIView) -> Value { get { … } set { … } }
>   }
> 
> Presumably you end up writing a schema which looks something like:
> 
>   formDataSource = FormDataSource(value: person)
>   formDataSource.fields = [
>   Section(title: nil, fields: [
>   Field(title: "Name", keyPath: \.name, control: 
> .textField),
>   Field(title: "Gender", keyPath: \.gender, control: . 
> picker(choices: Array(Gender.allValues))),
>   …
>   ])
>   ]
>   tableView.dataSource = formDataSource
> 
> The `Array(Gender.allValues)` here is clutter; it'd be nice if we didn't have 
> to write it explicitly. After all, if you're choosing a value of something 
> you know is an enum, it's sensible to assume that you want to choose from all 
> values if it doesn't specify anything more specific. If `ValueEnumerable` is 
> a formalized protocol, you can do that with a constrained extension:
> 
>   extension Control where Value: ValueEnumerable {
>   static var picker: Control {
>   return .picker(choices: Array(Value.allValues))
>   }
>   }
> 
> And now you just need to write:
> 
>   Field(title: "Gender", keyPath: \.gender, control: . 
> picker)

One magic future day, the protocol could be Chris’s narrower CaseEnumerable, 
Brent’s hypothetical picker could use a more general ValueEnumerable, and we 
could short-circuit the whole debate with:

extension CaseEnumerable: ValueEnumerable {
var allValues: WhateverThisTypeIsSupposedToBe {
return allCases
}
}

…but I recall a particularly thorny “alternatives considered” section about the 
implications of allowing extensions to add protocol conformance to other 
protocols!

Absent that language feature, I do think Brent has a point.

I tend to agree with Chris’s assessment here, which to my eyes doesn’t 
contradict Brent’s example:

> On Jan 12, 2018, at 1:28 AM, Chris Lattner  wrote:
> 

> While we generally generally steer protocols towards being a “bag of 
> semantics” instead of a “bag of syntax”, there are definitely exceptions to 
> that rule, including the ExpressibleBy and other compiler intrinsic protocols 
> which really are *all about* defining syntax.  These protocols are not 
> particularly useful for generic algorithms.
> 
> The next level down are protocols like hashable/comparable that are useful 
> for generic algorithms, but are also particularly interesting because of 
> compiler synthesized conformances.  They are unique because they are both 
> sometimes interesting for generic algorithms, but also sometimes interesting 
> just because you want the synthesized members on *concrete* types for 
> non-generic uses.  IMO, this is the bucket that this proposal falls into.


That seems right: this CaseEnumerable / ValueEnumerable protocol will usually 
be about synthesized conformance, but occasionally be about semantics that are 
useful for generic algorithms.

I wouldn’t want to touch the “all possible values for all types” idea with an 
ℵ₀-foot pole.[1] However, I don’t see the harm in going Brent’s direction: a 
protocol whose “bag of semantics” is along the lines of “has a limited, known 
set of possible values that does not change during execution, and that might 
reasonably be iterated over or displayed to the user as a set of choices.”

That suggests to me the name ValueEnumerable. As with Equatable, it is named 
for the generic use, but synthesized by the compiler in a specific situation 
where it makes obvious sense to do 

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

[Vladimir.S via swift-evolution]

On 11.01.2018 1:54, Jordan Rose via swift-evolution wrote:

[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 /cannot/ conform to ValueEnumerable, just because imported enums 
won't. (But especially while knee-deep in SE-0192, I think it's /correct/ that imported enums won't. The exception could 
be C enums marked `enum_extensibility(closed)`, but I'm not convinced we need that yet.)


The biggest problem I have is unavailable cases. An unavailable case /must not/ be instantiated—consider an enum where 
some cases are only available on iOS and not macOS. (I bet we optimize based on this, which makes it all the more 
important to get right.)


I think you should explicitly call out that the derived implementation only kicks in when ValueEnumerable is declared on 
the enum itself, not an extension. Or if that's not the case, it should be limited to extensions in the same module as 
the enum. (You could add "unless the enum is '@frozen'", but that's not really necessary.)




I'd also ask to append that information into the proposal, as IMO it is very 
important point.
I was under impression that we'll be allowed to retroactively conform to ValueEnumerable for frozen enums from other 
modules. Wouldn't this be a very requested feature of ValueEnumerable ? I.e. when we have a module with frozen enum, but 
author of that enum didn't consider conforming to ValueEnumerable for some reason.


Vladimir.

I don't think this should be implemented with a run-time function; compile-time code generation makes more sense to me. 
But that's an implementation detail; it doesn't change the language surface.


Jordan


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Chris Lattner via swift-evolution]

> On Jan 11, 2018, at 9:26 PM, Gwendal Roué via swift-evolution 
>  wrote:
> 
> Hello,
> 
>> Le 12 janv. 2018 à 02:36, Paul Cantrell via swift-evolution 
>>  a écrit :
>> 
>> The question I was weighing on it — what I thought Chris and Brent were 
>> discussing — was whether this new protocol should be used narrowly for cases 
>> of enums without associated types (which Chris favors), or whether it should 
>> find more broad use to mean “type which can enumerate all of its possible 
>> values” (which Brent finds interesting with caveats). This question has a 
>> bearing on whether the protocol’s name should be CaseEnumerable or 
>> ValueEnumerable.
> 
> A classic mantra on this mailing list is that stdlib protocols ought to come 
> with generic use cases and algorithms.

While this is a good general goal, I don’t think this is an absolute 
requirement.  As usual, I think the reality of the situation is more 
complicated:

While we generally generally steer protocols towards being a “bag of semantics” 
instead of a “bag of syntax”, there are definitely exceptions to that rule, 
including the ExpressibleBy and other compiler intrinsic protocols which really 
are *all about* defining syntax.  These protocols are not particularly useful 
for generic algorithms.

The next level down are protocols like hashable/comparable that are useful for 
generic algorithms, but are also particularly interesting because of compiler 
synthesized conformances.  They are unique because they are both sometimes 
interesting for generic algorithms, but also sometimes interesting just because 
you want the synthesized members on *concrete* types for non-generic uses.  
IMO, this is the bucket that this proposal falls into.

Finally, there is the “normal” user defined protocol case, which are clearly 
about defining the semantics of types and nothing more.  Duck typing and 
“defined by syntax” conformance is clearly out of bounds for these.

-Chris



___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Gwendal Roué via swift-evolution]

> Le 12 janv. 2018 à 06:42, Brent Royal-Gordon via swift-evolution 
>  a écrit :
> 
> Basically, having `ValueEnumerable` be a formal protocol means we can extend 
> this small automatic behavior into larger automatic behaviors. I can imagine, 
> for instance, building a fuzzer which, given a list of `WritableKeyPath`s 
> whose types are all `ValueEnumerable`, automatically generates random 
> instances of a type and feeds them into a test function. If we get read-write 
> reflection, we might be able to do this automatically and recursively. That'd 
> be pretty cool.

Yes! This is an argument for ValueEnumerable (vs. CaseEnumerable), ins't it ?

Gwendal

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jacob Bandes-Storch via swift-evolution]

On Wed, Jan 10, 2018 at 3:06 AM, Brent Royal-Gordon via swift-evolution <
swift-evolution@swift.org> wrote:

> On Jan 9, 2018, at 10:26 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I continue to have concerns about this proposal, and I'm gravely and very
> bitterly disappointed that the concerns have not even been acknowledged in
> the Alternatives section, which is in my view the minimum action that an
> author should take when points are raised during a pitch phase, even (and
> especially) when the author disagrees, along with a cogent write-up of why
> the proposed design is superior in the author's view to the alternative. In
> this case, the proposal authors write:
>
>   "The community has not raised any solutions whose APIs differ
> significantly from this proposal, except for solutions which provide
> strictly more functionality."
>
> This is false, as I have offered a solution in the past whose API differs
> entirely from this proposal, and which provides strictly a subset of the
> functionality which goes to the core of the issue at stake.
>
>
> I can't speak for the other co-authors, but for my part, this was an
> oversight and I apologize for it. I think we should have discussed your
> `MyType.self` alternative.
>

I echo Brent's sentiment — omissions were not intentionally disingenuous
but the result of a slow proposal writing/revision process, and clearly my
failure to adequately capture all of the mailing list discussion in the
proposal & alternatives even when it was updated in the days before the
review began. In the event the proposal is returned for revision, we can
revisit this to ensure all viewpoints are represented. Thanks, as always,
for your detailed reply.

Jacob


>
> I won't rehash the entire discussion in previous threads, but to summarize
> my objections:
>
> 1. `MyType.self` is harder to understand for someone who's never seen it
> than `MyType.allValues`. For instance, the expression
> `AccountStatus.allValues[0]` is completely self-explanatory, while
> `AccountStatus.self[0]` is more obscure and would require a trip to the
> documentation. (And since `self` here is a language keyword, not a real
> member, the most obvious route to the documentation is not available.) In
> my opinion, we should not prefer the `MyType.self` syntax.
>
> 2. Even if the community disagrees with me and thinks `MyType.self` is a
> better syntax than `MyType.allValues`, it is not better *enough* to
> outweigh the costs:
>
> • The metatype solution provides no additional functionality; it is merely
> a matter of which syntax we choose to support, and how much effort this
> support requires.
>
> • Conforming the metatype to `Collection` requires a lot of type system
> features we do not currently have. Currently, structural types cannot
> conform to protocols, and metatypes are a structural type. Metatypes also
> cannot have subscripts currently. Your proposed design has a lot of
> prerequisites. That is not in and of itself disqualifying, but it should be
> weighed against it.
>
> • You suggest that we should add bits and pieces of "`Collection`
> functionality" incrementally as engineering resources become available. The
> problem is that the most valuable part of the "`Collection` functionality"
> is conformance to `Collection` or at least `Sequence`, not the existence of
> any particular members of `Collection`, and this is the part that would
> require the most engineering resources.
>
> • A large part of the work we would do before supporting this conformance
> would be disposed of immediately once we could get it. For instance, all of
> the work to support having a metatype instead of a sequence in a `for-in`
> statement would be thrown away as soon as we could conform to `Sequence`.
> So this looks less like slowly building up pieces of the feature until we
> have all of them in place, and more like creating temporary hacks to
> emulate the feature until we have the time to do it right.
>
> • While this feature is not a showstopper, it is a highly desirable
> convenience. The proposal documents the high demand for this feature, so I
> won't elaborate on this point further.
>
> • Therefore, adopting this design would add a lot of engineering
> complexity before we could fully support a highly desirable feature, merely
> to get a syntax that we *might* prefer.
>
> To summarize the summary: The primary advantage of `MyType.self` is that
> it's elegant. To get that elegance, we must trade away getting a
> fully-functional implementation sooner, spending a lot of engineering
> resources (much of which would be wasted in the end), and—most crucially in
> my opinion—clarity at the point of use. It's not worth it.
>
> Earlier in this thread (or was it in the companion one?), another
> community member suggested that if `allValues` were to conform to
> `Sequence` instead of `Collection`, then even types that have an infinite
> number of possible values could conform to 

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

[Brent Royal-Gordon via swift-evolution]

> On Jan 11, 2018, at 4:21 PM, Paul Cantrell  wrote:
> 
> This raises a question related to Chris’s: what is the utility of having Limb 
> conform to a protocol instead of just providing allValues ad hoc? Does 
> CaseEnumerable / ValueEnumerable serve any purpose other than triggering 
> special behavior in the compiler? Would the protocol ever be used as the type 
> of something in code?
> 
> My answers, admittedly weak ones, are: (1) conventions are nice and 
> consistency is nice, and (2) you never know how an abstraction might be used, 
> but you do know that people will be angry when it should fit but doesn’t. I 
> can’t come up with a more compelling or specific argument than those.

Here's a place where you might want to use the protocol: Suppose you're writing 
a table view data source that displays editable controls for a form. You 
support several different types of controls, one of which is a list of choices 
for a picker controller.

enum Control {
case textField
case picker(choices: [Value])
…

func makeView() -> UIView { … }
subscript(valueOf view: UIView) -> Value { get { … } set { … } }
}

Presumably you end up writing a schema which looks something like:

formDataSource = FormDataSource(value: person)
formDataSource.fields = [
Section(title: nil, fields: [
Field(title: "Name", keyPath: \.name, control: 
.textField),
Field(title: "Gender", keyPath: \.gender, control: . 
picker(choices: Array(Gender.allValues))),
…
])
]
tableView.dataSource = formDataSource

The `Array(Gender.allValues)` here is clutter; it'd be nice if we didn't have 
to write it explicitly. After all, if you're choosing a value of something you 
know is an enum, it's sensible to assume that you want to choose from all 
values if it doesn't specify anything more specific. If `ValueEnumerable` is a 
formalized protocol, you can do that with a constrained extension:

extension Control where Value: ValueEnumerable {
static var picker: Control {
return .picker(choices: Array(Value.allValues))
}
}

And now you just need to write:

Field(title: "Gender", keyPath: \.gender, control: . 
picker)

Basically, having `ValueEnumerable` be a formal protocol means we can extend 
this small automatic behavior into larger automatic behaviors. I can imagine, 
for instance, building a fuzzer which, given a list of `WritableKeyPath`s whose 
types are all `ValueEnumerable`, automatically generates random instances of a 
type and feeds them into a test function. If we get read-write reflection, we 
might be able to do this automatically and recursively. That'd be pretty cool.

-- 
Brent Royal-Gordon
Architechies

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Gwendal Roué via swift-evolution]

Hello,

> Le 12 janv. 2018 à 02:36, Paul Cantrell via swift-evolution 
>  a écrit :
> 
> The question I was weighing on it — what I thought Chris and Brent were 
> discussing — was whether this new protocol should be used narrowly for cases 
> of enums without associated types (which Chris favors), or whether it should 
> find more broad use to mean “type which can enumerate all of its possible 
> values” (which Brent finds interesting with caveats). This question has a 
> bearing on whether the protocol’s name should be CaseEnumerable or 
> ValueEnumerable.

A classic mantra on this mailing list is that stdlib protocols ought to come 
with generic use cases and algorithms.

Is there any such use case, for either CaseEnumerable or ValueEnumerable, that 
are not already covered by sequence and the various collection protocols?

Did I miss them in the proposal? Did I miss Xiaodi's post about the lack of 
such use cases?

Gwendal

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Howard Lovatt via swift-evolution]

I missed that sorry.

I think it will find other uses and therefore should be ValueEnumerable. 

-- Howard.

> On 11 Jan 2018, at 6:36 pm, Paul Cantrell  wrote:
> 
>> On Jan 11, 2018, at 7:28 PM, Howard Lovatt  wrote:
>> 
>> I am in favour of a protocol that you have to explicitly declare, it feels 
>> much more like Swift to me. For example you have to say Equatable 
>> explicitly. 
> 
> Howard — Either you’ve missed something or I have. I didn’t view requiring 
> types to explicitly declare conformance as being up for debate at all.
> 
> The question I was weighing on it — what I thought Chris and Brent were 
> discussing — was whether this new protocol should be used narrowly for cases 
> of enums without associated types (which Chris favors), or whether it should 
> find more broad use to mean “type which can enumerate all of its possible 
> values” (which Brent finds interesting with caveats). This question has a 
> bearing on whether the protocol’s name should be CaseEnumerable or 
> ValueEnumerable.
> 
> In either case, the conformance is always explicitly declared; the compiler 
> merely synthesizes the implementation for enums without associated types.
> 
> I think?
> 
>> As a contra example in Java it feels natural that the compiler just provides 
>> the functionality because that is consistent across the language, you don’t 
>> declare something as equatable and you don’t tell the compiler that you want 
>> the values array generating. 
>> 
>> ‘Horses for courses’, this is what Swift does. 
>> 
>> As a more hard-core example, suppose you want to use statics as an enum like 
>> construct, e.g.:
>> 
>> struct Ex: ValueEnumerable {
>> let x1: Int
>> let x2: Int
>> init(x1: Int, x2: Int) { self.x1 = x1, self.x2 = x2 }
>> static let allValues = [x1, x2]
>> }
>> 
>> Perhaps the above Ex started as an enum but was changed to a struct during 
>> enhancements to the program because the values of x1 and x2 are now read in 
>> rather than constants. 
>> 
>> -- Howard.
>> 
>>> On 11 Jan 2018, at 5:21 pm, Paul Cantrell via swift-evolution 
>>>  wrote:
>>> 
>>> 
>>> 
 On Jan 10, 2018, at 10:21 PM, Chris Lattner via swift-evolution 
  wrote:
 
 Brent, thanks for the detailed response, one question about it:
 
> On Jan 10, 2018, at 3:06 AM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
> But that's beside the point. What I think the "`allValues` should be 
> allowed to be infinite" suggestion misses is that one of 
> `ValueEnumerable`'s semantics is that it's not only theoretically 
> *possible* to enumerate all the values, but actually *reasonable* to do 
> so.
 ...
> Some types, of course, fall into a gray area. `Int8` is fairly 
> reasonable, but larger integer types get increasingly unreasonable until, 
> by `Int64`, we reach types that would take decades to enumerate. Where 
> the line should be drawn is a matter of opinion. (My opinion, to be 
> clear, is that we shouldn't conform any of them; if someone really wants 
> to do it, they can add a retroactive conformance.)
 
 I’m not sure which way you’re arguing here, but that’s ok. :-)
 
 In my opinion, while I can see where you are coming from (that it could be 
 “reasonable” to allow random types to be ValueEnumerable) I don’t see what 
 the *utility* or *benefit* that would provide.
 
 If we went with a simpler design - one that named this CaseEnumerable and 
 .allCases - we would be heavily biasing the design of the feature towards 
 enum-like applications that do not have associated types.  This is “the” 
 problem to be solved in my opinion, and would lead to a more clear and 
 consistently understood feature that doesn’t have the ambiguity and “gray 
 areas” that you discuss above.  Given this bias, it is clear that infinite 
 sequences are not interesting.
 
 Of course it would certainly be *possible* for someone to conform a 
 non-enum-like type to CaseEnumerable, but that would be an abuse of the 
 feature, and not a "gray area”.  
 
 
 Is there some specific *utility* and *benefit* from creeping this feature 
 beyond “enumerating cases in enums that don’t have associated types”?  Is 
 that utility and benefit large enough to make it worthwhile to water down 
 the semantics of this protocol by making it so abstract?
>>> 
>>> I gave an example in my review of an enumerable thing where the items are 
>>> analogous to cases but are not actually cases, and where I thought 
>>> `allCases` would cause confusion but `allValues` would make sense:
>>> 
> On Jan 10, 2018, at 10:22 AM, Paul Cantrell via swift-evolution 
>  wrote:
> 
 Contra Chris, I slightly prefer 

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

[Paul Cantrell via swift-evolution]

> On Jan 11, 2018, at 7:28 PM, Howard Lovatt  wrote:
> 
> I am in favour of a protocol that you have to explicitly declare, it feels 
> much more like Swift to me. For example you have to say Equatable explicitly. 

Howard — Either you’ve missed something or I have. I didn’t view requiring 
types to explicitly declare conformance as being up for debate at all.

The question I was weighing on it — what I thought Chris and Brent were 
discussing — was whether this new protocol should be used narrowly for cases of 
enums without associated types (which Chris favors), or whether it should find 
more broad use to mean “type which can enumerate all of its possible values” 
(which Brent finds interesting with caveats). This question has a bearing on 
whether the protocol’s name should be CaseEnumerable or ValueEnumerable.

In either case, the conformance is always explicitly declared; the compiler 
merely synthesizes the implementation for enums without associated types.

I think?

> As a contra example in Java it feels natural that the compiler just provides 
> the functionality because that is consistent across the language, you don’t 
> declare something as equatable and you don’t tell the compiler that you want 
> the values array generating. 
> 
> ‘Horses for courses’, this is what Swift does. 
> 
> As a more hard-core example, suppose you want to use statics as an enum like 
> construct, e.g.:
> 
> struct Ex: ValueEnumerable {
> let x1: Int
> let x2: Int
> init(x1: Int, x2: Int) { self.x1 = x1, self.x2 = x2 }
> static let allValues = [x1, x2]
> }
> 
> Perhaps the above Ex started as an enum but was changed to a struct during 
> enhancements to the program because the values of x1 and x2 are now read in 
> rather than constants. 
> 
> -- Howard.
> 
> On 11 Jan 2018, at 5:21 pm, Paul Cantrell via swift-evolution 
> > wrote:
> 
>> 
>> 
>>> On Jan 10, 2018, at 10:21 PM, Chris Lattner via swift-evolution 
>>> > wrote:
>>> 
>>> Brent, thanks for the detailed response, one question about it:
>>> 
 On Jan 10, 2018, at 3:06 AM, Brent Royal-Gordon via swift-evolution 
 > wrote:
 
 But that's beside the point. What I think the "`allValues` should be 
 allowed to be infinite" suggestion misses is that one of 
 `ValueEnumerable`'s semantics is that it's not only theoretically 
 *possible* to enumerate all the values, but actually *reasonable* to do so.
>>> ...
 Some types, of course, fall into a gray area. `Int8` is fairly reasonable, 
 but larger integer types get increasingly unreasonable until, by `Int64`, 
 we reach types that would take decades to enumerate. Where the line should 
 be drawn is a matter of opinion. (My opinion, to be clear, is that we 
 shouldn't conform any of them; if someone really wants to do it, they can 
 add a retroactive conformance.)
>>> 
>>> I’m not sure which way you’re arguing here, but that’s ok. :-)
>>> 
>>> In my opinion, while I can see where you are coming from (that it could be 
>>> “reasonable” to allow random types to be ValueEnumerable) I don’t see what 
>>> the *utility* or *benefit* that would provide.
>>> 
>>> If we went with a simpler design - one that named this CaseEnumerable and 
>>> .allCases - we would be heavily biasing the design of the feature towards 
>>> enum-like applications that do not have associated types.  This is “the” 
>>> problem to be solved in my opinion, and would lead to a more clear and 
>>> consistently understood feature that doesn’t have the ambiguity and “gray 
>>> areas” that you discuss above.  Given this bias, it is clear that infinite 
>>> sequences are not interesting.
>>> 
>>> Of course it would certainly be *possible* for someone to conform a 
>>> non-enum-like type to CaseEnumerable, but that would be an abuse of the 
>>> feature, and not a "gray area”.  
>>> 
>>> 
>>> Is there some specific *utility* and *benefit* from creeping this feature 
>>> beyond “enumerating cases in enums that don’t have associated types”?  Is 
>>> that utility and benefit large enough to make it worthwhile to water down 
>>> the semantics of this protocol by making it so abstract?
>> 
>> I gave an example in my review of an enumerable thing where the items are 
>> analogous to cases but are not actually cases, and where I thought 
>> `allCases` would cause confusion but `allValues` would make sense:
>> 
>>> On Jan 10, 2018, at 10:22 AM, Paul Cantrell via swift-evolution 
>>> > wrote:
>> 
>>> 
>> 
>>> Contra Chris, I slightly prefer ValueEnumerable, because it extends to 
>>> situations where we still want to enumerate a fixed set of possibilities 
>>> which don’t strictly correspond to enum cases but still 

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

[Howard Lovatt via swift-evolution]

I am in favour of a protocol that you have to explicitly declare, it feels much 
more like Swift to me. For example you have to say Equatable explicitly. 

As a contra example in Java it feels natural that the compiler just provides 
the functionality because that is consistent across the language, you don’t 
declare something as equatable and you don’t tell the compiler that you want 
the values array generating. 

‘Horses for courses’, this is what Swift does. 

As a more hard-core example, suppose you want to use statics as an enum like 
construct, e.g.:

struct Ex: ValueEnumerable {
let x1: Int
let x2: Int
init(x1: Int, x2: Int) { self.x1 = x1, self.x2 = x2 }
static let allValues = [x1, x2]
}

Perhaps the above Ex started as an enum but was changed to a struct during 
enhancements to the program because the values of x1 and x2 are now read in 
rather than constants. 

-- Howard.

> On 11 Jan 2018, at 5:21 pm, Paul Cantrell via swift-evolution 
>  wrote:
> 
> 
> 
>> On Jan 10, 2018, at 10:21 PM, Chris Lattner via swift-evolution 
>>  wrote:
>> 
>> Brent, thanks for the detailed response, one question about it:
>> 
>>> On Jan 10, 2018, at 3:06 AM, Brent Royal-Gordon via swift-evolution 
>>>  wrote:
>>> 
>>> But that's beside the point. What I think the "`allValues` should be 
>>> allowed to be infinite" suggestion misses is that one of 
>>> `ValueEnumerable`'s semantics is that it's not only theoretically 
>>> *possible* to enumerate all the values, but actually *reasonable* to do so.
>> ...
>>> Some types, of course, fall into a gray area. `Int8` is fairly reasonable, 
>>> but larger integer types get increasingly unreasonable until, by `Int64`, 
>>> we reach types that would take decades to enumerate. Where the line should 
>>> be drawn is a matter of opinion. (My opinion, to be clear, is that we 
>>> shouldn't conform any of them; if someone really wants to do it, they can 
>>> add a retroactive conformance.)
>> 
>> I’m not sure which way you’re arguing here, but that’s ok. :-)
>> 
>> In my opinion, while I can see where you are coming from (that it could be 
>> “reasonable” to allow random types to be ValueEnumerable) I don’t see what 
>> the *utility* or *benefit* that would provide.
>> 
>> If we went with a simpler design - one that named this CaseEnumerable and 
>> .allCases - we would be heavily biasing the design of the feature towards 
>> enum-like applications that do not have associated types.  This is “the” 
>> problem to be solved in my opinion, and would lead to a more clear and 
>> consistently understood feature that doesn’t have the ambiguity and “gray 
>> areas” that you discuss above.  Given this bias, it is clear that infinite 
>> sequences are not interesting.
>> 
>> Of course it would certainly be *possible* for someone to conform a 
>> non-enum-like type to CaseEnumerable, but that would be an abuse of the 
>> feature, and not a "gray area”.  
>> 
>> 
>> Is there some specific *utility* and *benefit* from creeping this feature 
>> beyond “enumerating cases in enums that don’t have associated types”?  Is 
>> that utility and benefit large enough to make it worthwhile to water down 
>> the semantics of this protocol by making it so abstract?
> 
> I gave an example in my review of an enumerable thing where the items are 
> analogous to cases but are not actually cases, and where I thought `allCases` 
> would cause confusion but `allValues` would make sense:
> 
>>> On Jan 10, 2018, at 10:22 AM, Paul Cantrell via swift-evolution 
>>>  wrote:
>>> 
>> Contra Chris, I slightly prefer ValueEnumerable, because it extends to 
>> situations where we still want to enumerate a fixed set of possibilities 
>> which don’t strictly correspond to enum cases but still have that sort of 
>> flavor. For example, one might want:
>> 
>> enum SideOfBody
>>   {
>>   case left
>>   case right
>>   }
>> 
>> enum Limb: ValueEnumerable
>>   {
>>   case arm(SideOfBody)
>>   case leg(SideOfBody)
>> 
>>   static let allValues =
>> [
>> arm(.left),
>> arm(.right),
>> leg(.left),
>> leg(.right)
>> ]
>>   }
>> 
>> To my eyes, this code reads better than it would with CaseEnumerable / 
>> allCases.
> 
> This raises a question related to Chris’s: what is the utility of having Limb 
> conform to a protocol instead of just providing allValues ad hoc? Does 
> CaseEnumerable / ValueEnumerable serve any purpose other than triggering 
> special behavior in the compiler? Would the protocol ever be used as the type 
> of something in code?
> 
> My answers, admittedly weak ones, are: (1) conventions are nice and 
> consistency is nice, and (2) you never know how an abstraction might be used, 
> but you do know that people will be angry when it should fit but doesn’t. I 
> can’t come up with 

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

[Paul Cantrell via swift-evolution]

> On Jan 10, 2018, at 10:21 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> Brent, thanks for the detailed response, one question about it:
> 
>> On Jan 10, 2018, at 3:06 AM, Brent Royal-Gordon via swift-evolution 
>>  wrote:
>> 
>> But that's beside the point. What I think the "`allValues` should be allowed 
>> to be infinite" suggestion misses is that one of `ValueEnumerable`'s 
>> semantics is that it's not only theoretically *possible* to enumerate all 
>> the values, but actually *reasonable* to do so.
> ...
>> Some types, of course, fall into a gray area. `Int8` is fairly reasonable, 
>> but larger integer types get increasingly unreasonable until, by `Int64`, we 
>> reach types that would take decades to enumerate. Where the line should be 
>> drawn is a matter of opinion. (My opinion, to be clear, is that we shouldn't 
>> conform any of them; if someone really wants to do it, they can add a 
>> retroactive conformance.)
> 
> I’m not sure which way you’re arguing here, but that’s ok. :-)
> 
> In my opinion, while I can see where you are coming from (that it could be 
> “reasonable” to allow random types to be ValueEnumerable) I don’t see what 
> the *utility* or *benefit* that would provide.
> 
> If we went with a simpler design - one that named this CaseEnumerable and 
> .allCases - we would be heavily biasing the design of the feature towards 
> enum-like applications that do not have associated types.  This is “the” 
> problem to be solved in my opinion, and would lead to a more clear and 
> consistently understood feature that doesn’t have the ambiguity and “gray 
> areas” that you discuss above.  Given this bias, it is clear that infinite 
> sequences are not interesting.
> 
> Of course it would certainly be *possible* for someone to conform a 
> non-enum-like type to CaseEnumerable, but that would be an abuse of the 
> feature, and not a "gray area”.  
> 
> 
> Is there some specific *utility* and *benefit* from creeping this feature 
> beyond “enumerating cases in enums that don’t have associated types”?  Is 
> that utility and benefit large enough to make it worthwhile to water down the 
> semantics of this protocol by making it so abstract?

I gave an example in my review of an enumerable thing where the items are 
analogous to cases but are not actually cases, and where I thought `allCases` 
would cause confusion but `allValues` would make sense:

> On Jan 10, 2018, at 10:22 AM, Paul Cantrell via swift-evolution 
>  wrote:

> 

> Contra Chris, I slightly prefer ValueEnumerable, because it extends to 
> situations where we still want to enumerate a fixed set of possibilities 
> which don’t strictly correspond to enum cases but still have that sort of 
> flavor. For example, one might want:
> 
> enum SideOfBody
>   {
>   case left
>   case right
>   }
> 
> enum Limb: ValueEnumerable
>   {
>   case arm(SideOfBody)
>   case leg(SideOfBody)
> 
>   static let allValues =
> [
> arm(.left),
> arm(.right),
> leg(.left),
> leg(.right)
> ]
>   }
> 
> To my eyes, this code reads better than it would with CaseEnumerable / 
> allCases.

This raises a question related to Chris’s: what is the utility of having Limb 
conform to a protocol instead of just providing allValues ad hoc? Does 
CaseEnumerable / ValueEnumerable serve any purpose other than triggering 
special behavior in the compiler? Would the protocol ever be used as the type 
of something in code?

My answers, admittedly weak ones, are: (1) conventions are nice and consistency 
is nice, and (2) you never know how an abstraction might be used, but you do 
know that people will be angry when it should fit but doesn’t. I can’t come up 
with a more compelling or specific argument than those.

Cheers,

Paul

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Chris Lattner via swift-evolution]

Brent, thanks for the detailed response, one question about it:

> On Jan 10, 2018, at 3:06 AM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
> But that's beside the point. What I think the "`allValues` should be allowed 
> to be infinite" suggestion misses is that one of `ValueEnumerable`'s 
> semantics is that it's not only theoretically *possible* to enumerate all the 
> values, but actually *reasonable* to do so.
...
> Some types, of course, fall into a gray area. `Int8` is fairly reasonable, 
> but larger integer types get increasingly unreasonable until, by `Int64`, we 
> reach types that would take decades to enumerate. Where the line should be 
> drawn is a matter of opinion. (My opinion, to be clear, is that we shouldn't 
> conform any of them; if someone really wants to do it, they can add a 
> retroactive conformance.)

I’m not sure which way you’re arguing here, but that’s ok. :-)

In my opinion, while I can see where you are coming from (that it could be 
“reasonable” to allow random types to be ValueEnumerable) I don’t see what the 
*utility* or *benefit* that would provide.

If we went with a simpler design - one that named this CaseEnumerable and 
.allCases - we would be heavily biasing the design of the feature towards 
enum-like applications that do not have associated types.  This is “the” 
problem to be solved in my opinion, and would lead to a more clear and 
consistently understood feature that doesn’t have the ambiguity and “gray 
areas” that you discuss above.  Given this bias, it is clear that infinite 
sequences are not interesting.

Of course it would certainly be *possible* for someone to conform a 
non-enum-like type to CaseEnumerable, but that would be an abuse of the 
feature, and not a "gray area”.  


Is there some specific *utility* and *benefit* from creeping this feature 
beyond “enumerating cases in enums that don’t have associated types”?  Is that 
utility and benefit large enough to make it worthwhile to water down the 
semantics of this protocol by making it so abstract?

-Chris

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

On Wed, Jan 10, 2018 at 5:06 AM, Brent Royal-Gordon 
wrote:

> On Jan 9, 2018, at 10:26 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I continue to have concerns about this proposal, and I'm gravely and very
> bitterly disappointed that the concerns have not even been acknowledged in
> the Alternatives section, which is in my view the minimum action that an
> author should take when points are raised during a pitch phase, even (and
> especially) when the author disagrees, along with a cogent write-up of why
> the proposed design is superior in the author's view to the alternative. In
> this case, the proposal authors write:
>
>   "The community has not raised any solutions whose APIs differ
> significantly from this proposal, except for solutions which provide
> strictly more functionality."
>
> This is false, as I have offered a solution in the past whose API differs
> entirely from this proposal, and which provides strictly a subset of the
> functionality which goes to the core of the issue at stake.
>
>
> I can't speak for the other co-authors, but for my part, this was an
> oversight and I apologize for it. I think we should have discussed your
> `MyType.self` alternative.
>
> I won't rehash the entire discussion in previous threads, but to summarize
> my objections:
>

I appreciate the detailed reply below. Time constraints prohibit an
immediate reply with the same level of thoroughness, but I look forward to
composing one within a few days' time. Bear with me.


> 1. `MyType.self` is harder to understand for someone who's never seen it
> than `MyType.allValues`. For instance, the expression
> `AccountStatus.allValues[0]` is completely self-explanatory, while
> `AccountStatus.self[0]` is more obscure and would require a trip to the
> documentation. (And since `self` here is a language keyword, not a real
> member, the most obvious route to the documentation is not available.) In
> my opinion, we should not prefer the `MyType.self` syntax.
>
> 2. Even if the community disagrees with me and thinks `MyType.self` is a
> better syntax than `MyType.allValues`, it is not better *enough* to
> outweigh the costs:
>
> • The metatype solution provides no additional functionality; it is merely
> a matter of which syntax we choose to support, and how much effort this
> support requires.
>
> • Conforming the metatype to `Collection` requires a lot of type system
> features we do not currently have. Currently, structural types cannot
> conform to protocols, and metatypes are a structural type. Metatypes also
> cannot have subscripts currently. Your proposed design has a lot of
> prerequisites. That is not in and of itself disqualifying, but it should be
> weighed against it.
>
> • You suggest that we should add bits and pieces of "`Collection`
> functionality" incrementally as engineering resources become available. The
> problem is that the most valuable part of the "`Collection` functionality"
> is conformance to `Collection` or at least `Sequence`, not the existence of
> any particular members of `Collection`, and this is the part that would
> require the most engineering resources.
>
> • A large part of the work we would do before supporting this conformance
> would be disposed of immediately once we could get it. For instance, all of
> the work to support having a metatype instead of a sequence in a `for-in`
> statement would be thrown away as soon as we could conform to `Sequence`.
> So this looks less like slowly building up pieces of the feature until we
> have all of them in place, and more like creating temporary hacks to
> emulate the feature until we have the time to do it right.
>
> • While this feature is not a showstopper, it is a highly desirable
> convenience. The proposal documents the high demand for this feature, so I
> won't elaborate on this point further.
>
> • Therefore, adopting this design would add a lot of engineering
> complexity before we could fully support a highly desirable feature, merely
> to get a syntax that we *might* prefer.
>
> To summarize the summary: The primary advantage of `MyType.self` is that
> it's elegant. To get that elegance, we must trade away getting a
> fully-functional implementation sooner, spending a lot of engineering
> resources (much of which would be wasted in the end), and—most crucially in
> my opinion—clarity at the point of use. It's not worth it.
>
> Earlier in this thread (or was it in the companion one?), another
> community member suggested that if `allValues` were to conform to
> `Sequence` instead of `Collection`, then even types that have an infinite
> number of possible values could conform to `ValueEnumerable`. Here's the
> rub: the definition of a type, or at least one of them, _is_ precisely the
> set of all possible values of a variable. If unconstrained by finiteness,
> then *all types* would meet the semantic requirements of `ValueEnumerable`.
>
>
> Not quite. There are types whose 

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

[Cheyo Jimenez via swift-evolution]

On Jan 10, 2018, at 8:22 AM, Paul Cantrell via swift-evolution 
 wrote:

>> What is your evaluation of the proposal?
> 
> +1. Yes please. Long overdue.
> 
>> Is the problem being addressed significant enough to warrant a change to 
>> Swift?
> 
> It’s a long-standing sore thumb. The proposal’s evidence of community demand 
> fits my own experience: I’ve wanted this on multiple occasions.
> 
>> Does this proposal fit well with the feel and direction of Swift?
> 
> Yes, and in particular, on the name bikeshedding:
> 
> I favor property names with the “all” prefix, whether allValues or allCases. 
> Looking over my own code, I’ve almost always used the word “all” for this 
> when I had to hand-roll it — and either allValues or allCases make reasonable 
> sense in my code when I substitute them.
> 
> Whichever protocol name we choose, the property name should be consistent:
> 
>   ValueEnumerable → allValues
>   CaseEnumerable → allCases

this is good point. I think it would be awesome to also have a compile time 
version named .cases.

.allCases would include unknown cases at runtime.
.cases would only include known at compile time cases. 


> Either ValueEnumerable or CaseEnumerable would be a fine name. Contra Chris, 
> I slightly prefer ValueEnumerable, because it extends to situations where we 
> still want to enumerate a fixed set of possibilities which don’t strictly 
> correspond to enum cases but still have that sort of flavor. For example, one 
> might want:
> 
> enum SideOfBody
>   {
>   case left
>   case right
>   }
> 
> enum Limb: ValueEnumerable
>   {
>   case arm(SideOfBody)
>   case leg(SideOfBody)
> 
>   static let allValues =
> [
> arm(.left),
> arm(.right),
> leg(.left),
> leg(.right)
> ]
>   }
> 
> To my eyes, this code reads better than it would with CaseEnumerable / 
> allCases.
> 
>> If you have used other languages or libraries with a similar feature, how do 
>> you feel that this proposal compares to those?
> 
> Java’s enums had this from the beginning, and Josh Bloch’s design for that 
> feature has always worked nicely. Java’s design is slightly different: 
> `Foo.values()` returns Foo[]. However, Swift doesn’t need to follow either 
> that name or type choice: (1) Java doesn’t use the term “case” as Swift does, 
> (2) the “all” prefix better fits Swift’s API guidelines IMO, and (3) using a 
> concrete array type has as opposed to Collection has different implications 
> in Java than it does Swift.
> 
> I _do_ agree  that the proposal should consider constraining the Collection 
> to be Int-indexed. Why should it ever be otherwise? What’s the motivation for 
> leaving that open?
> 
>> How much effort did you put into your review? A glance, a quick reading, or 
>> an in-depth study?
> 
> Medium quick study.
> 
> Cheers, P
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jordan Rose via swift-evolution]

[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 cannot conform to ValueEnumerable, just because imported enums 
won't. (But especially while knee-deep in SE-0192, I think it's correct that 
imported enums won't. The exception could be C enums marked 
`enum_extensibility(closed)`, but I'm not convinced we need that yet.)

The biggest problem I have is unavailable cases. An unavailable case must not 
be instantiated—consider an enum where some cases are only available on iOS and 
not macOS. (I bet we optimize based on this, which makes it all the more 
important to get right.)

I think you should explicitly call out that the derived implementation only 
kicks in when ValueEnumerable is declared on the enum itself, not an extension. 
Or if that's not the case, it should be limited to extensions in the same 
module as the enum. (You could add "unless the enum is '@frozen'", but that's 
not really necessary.)

I don't think this should be implemented with a run-time function; compile-time 
code generation makes more sense to me. But that's an implementation detail; it 
doesn't change the language surface.

Jordan___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Paul Cantrell via swift-evolution]

> On Jan 10, 2018, at 2:23 PM, Kevin Nattinger  wrote:
> 
>> [...]
>> 
>> I don’t agree that the Collection should be Int-indexed. Source-order is not 
>> a very strong guarantee IMO, and it wouldn’t be good if people started 
>> writing things like "MyEnum.allValues[3]” to reference a specific case.
> 
> So how do you propose to use allValues with a table view? That's one of the 
> motivating examples, and probably the most common use case. Certainly the 
> most common I've seen.

I assume the mildly inconvenient

static let valuesForTableView = Array(MyEnum.allValues)

…or some such.

> 
>> 
>> If you know the specific case you are looking for, just write it directly. 
>> If you found an interesting case while iterating allValues, remember its 
>> (opaque) index and come back to it later.
>> 
>> I’m not a fan of Int-indexes in general. It’s practical to allow it for 
>> Array, but in general, for generic Collections, I think it implies an awful 
>> lot of knowledge about the Collection’s contents.
>> 
>> - Karl
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Kevin Nattinger via swift-evolution]

> [...]
> 
> I don’t agree that the Collection should be Int-indexed. Source-order is not 
> a very strong guarantee IMO, and it wouldn’t be good if people started 
> writing things like "MyEnum.allValues[3]” to reference a specific case.

So how do you propose to use allValues with a table view? That's one of the 
motivating examples, and probably the most common use case. Certainly the most 
common I've seen.

> 
> If you know the specific case you are looking for, just write it directly. If 
> you found an interesting case while iterating allValues, remember its 
> (opaque) index and come back to it later.
> 
> I’m not a fan of Int-indexes in general. It’s practical to allow it for 
> Array, but in general, for generic Collections, I think it implies an awful 
> lot of knowledge about the Collection’s contents.
> 
> - Karl
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Paul Cantrell via swift-evolution]

> On Jan 10, 2018, at 12:44 PM, Karl Wagner  wrote:
> 
> 
> 
>> On 10. Jan 2018, at 17:22, Paul Cantrell via swift-evolution 
>> > wrote:
>> 
>>> What is your evaluation of the proposal?
>> 
>> +1. Yes please. Long overdue.
>> 
>>> Is the problem being addressed significant enough to warrant a change to 
>>> Swift?
>> 
>> It’s a long-standing sore thumb. The proposal’s evidence of community demand 
>> fits my own experience: I’ve wanted this on multiple occasions.
>> 
>>> Does this proposal fit well with the feel and direction of Swift?
>> 
>> Yes, and in particular, on the name bikeshedding:
>> 
>> I favor property names with the “all” prefix, whether allValues or allCases. 
>> Looking over my own code, I’ve almost always used the word “all” for this 
>> when I had to hand-roll it — and either allValues or allCases make 
>> reasonable sense in my code when I substitute them.
>> 
>> Whichever protocol name we choose, the property name should be consistent:
>> 
>>  ValueEnumerable → allValues
>>  CaseEnumerable → allCases
>> 
>> Either ValueEnumerable or CaseEnumerable would be a fine name. Contra Chris, 
>> I slightly prefer ValueEnumerable, because it extends to situations where we 
>> still want to enumerate a fixed set of possibilities which don’t strictly 
>> correspond to enum cases but still have that sort of flavor. For example, 
>> one might want:
>> 
>> enum SideOfBody
>>   {
>>   case left
>>   case right
>>   }
>> 
>> enum Limb: ValueEnumerable
>>   {
>>   case arm(SideOfBody)
>>   case leg(SideOfBody)
>> 
>>   static let allValues =
>> [
>> arm(.left),
>> arm(.right),
>> leg(.left),
>> leg(.right)
>> ]
>>   }
>> 
>> To my eyes, this code reads better than it would with CaseEnumerable / 
>> allCases.
>> 
>>> If you have used other languages or libraries with a similar feature, how 
>>> do you feel that this proposal compares to those?
>> 
>> Java’s enums had this from the beginning, and Josh Bloch’s design for that 
>> feature has always worked nicely. Java’s design is slightly different: 
>> `Foo.values()` returns Foo[]. However, Swift doesn’t need to follow either 
>> that name or type choice: (1) Java doesn’t use the term “case” as Swift 
>> does, (2) the “all” prefix better fits Swift’s API guidelines IMO, and (3) 
>> using a concrete array type has as opposed to Collection has different 
>> implications in Java than it does Swift.
>> 
>> I _do_ agree  that the proposal should consider constraining the Collection 
>> to be Int-indexed. Why should it ever be otherwise? What’s the motivation 
>> for leaving that open?
> 
> 
> I don’t agree that the Collection should be Int-indexed. Source-order is not 
> a very strong guarantee IMO, and it wouldn’t be good if people started 
> writing things like "MyEnum.allValues[3]” to reference a specific case.

You do make a good point about the hidden brittleness of MyEnum.allValues[3].

Direct indexing of collections using arbitrary hard-coded int indexes is a way 
to introduce brittleness in many other existing contexts, and I’d say 
developers already know that it has a bad smell (or are making other far larger 
mistakes as well). However, using int indices for serialization seems a pitfall 
that would catch many people. Is there a way to make transient use of ints 
convenient (as in the proposal’s table view example) but persistent int values 
inconvenient? No.

There are clearly enums where source ordering is intentional and significant, 
and others where the enum is inherently unordered. An alternative would be two 
protocols, one where allValues is a Set and one where it is an Array, or 
something along those lines. That feels like overkill to me, however.

Perhaps the proposal as it stands is the best compromise: everything is 
ordered, even if the ordering is not stable between versions, but int indexing 
is inconvenient enough to turn away the more careless among us.

Cheers, P

> 
> If you know the specific case you are looking for, just write it directly. If 
> you found an interesting case while iterating allValues, remember its 
> (opaque) index and come back to it later.
> 
> I’m not a fan of Int-indexes in general. It’s practical to allow it for 
> Array, but in general, for generic Collections, I think it implies an awful 
> lot of knowledge about the Collection’s contents.
> 
> - Karl

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Dave DeLong via swift-evolution]

Yes please to Int indexes.

One of the things I despise most about the Collection protocol is how it allows 
for arbitrary index types. That, IMO, was an awful, awful mistake.

Dave

> On Jan 10, 2018, at 11:45 AM, C. Keith Ray via swift-evolution 
>  wrote:
> 
> Simple is better. Int indexes, please. 
> 
> --
> C. Keith Ray
> 
> * https://leanpub.com/wepntk  <- buy my book?
> * http://www.thirdfoundationsw.com/keith_ray_resume_2014_long.pdf 
> 
> * http://agilesolutionspace.blogspot.com/ 
> 
> 
> On Jan 10, 2018, at 10:44 AM, Karl Wagner via swift-evolution 
> > wrote:
> 
>> 
>> 
>>> On 10. Jan 2018, at 17:22, Paul Cantrell via swift-evolution 
>>> > wrote:
>>> 
 What is your evaluation of the proposal?
>>> 
>>> +1. Yes please. Long overdue.
>>> 
 Is the problem being addressed significant enough to warrant a change to 
 Swift?
>>> 
>>> It’s a long-standing sore thumb. The proposal’s evidence of community 
>>> demand fits my own experience: I’ve wanted this on multiple occasions.
>>> 
 Does this proposal fit well with the feel and direction of Swift?
>>> 
>>> Yes, and in particular, on the name bikeshedding:
>>> 
>>> I favor property names with the “all” prefix, whether allValues or 
>>> allCases. Looking over my own code, I’ve almost always used the word “all” 
>>> for this when I had to hand-roll it — and either allValues or allCases make 
>>> reasonable sense in my code when I substitute them.
>>> 
>>> Whichever protocol name we choose, the property name should be consistent:
>>> 
>>> ValueEnumerable → allValues
>>> CaseEnumerable → allCases
>>> 
>>> Either ValueEnumerable or CaseEnumerable would be a fine name. Contra 
>>> Chris, I slightly prefer ValueEnumerable, because it extends to situations 
>>> where we still want to enumerate a fixed set of possibilities which don’t 
>>> strictly correspond to enum cases but still have that sort of flavor. For 
>>> example, one might want:
>>> 
>>> enum SideOfBody
>>>   {
>>>   case left
>>>   case right
>>>   }
>>> 
>>> enum Limb: ValueEnumerable
>>>   {
>>>   case arm(SideOfBody)
>>>   case leg(SideOfBody)
>>> 
>>>   static let allValues =
>>> [
>>> arm(.left),
>>> arm(.right),
>>> leg(.left),
>>> leg(.right)
>>> ]
>>>   }
>>> 
>>> To my eyes, this code reads better than it would with CaseEnumerable / 
>>> allCases.
>>> 
 If you have used other languages or libraries with a similar feature, how 
 do you feel that this proposal compares to those?
>>> 
>>> Java’s enums had this from the beginning, and Josh Bloch’s design for that 
>>> feature has always worked nicely. Java’s design is slightly different: 
>>> `Foo.values()` returns Foo[]. However, Swift doesn’t need to follow either 
>>> that name or type choice: (1) Java doesn’t use the term “case” as Swift 
>>> does, (2) the “all” prefix better fits Swift’s API guidelines IMO, and (3) 
>>> using a concrete array type has as opposed to Collection has different 
>>> implications in Java than it does Swift.
>>> 
>>> I _do_ agree  that the proposal should consider constraining the Collection 
>>> to be Int-indexed. Why should it ever be otherwise? What’s the motivation 
>>> for leaving that open?
>>> 
 How much effort did you put into your review? A glance, a quick reading, 
 or an in-depth study?
>>> 
>>> Medium quick study.
>>> 
>>> Cheers, P
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
>> 
>> 
>> I don’t agree that the Collection should be Int-indexed. Source-order is not 
>> a very strong guarantee IMO, and it wouldn’t be good if people started 
>> writing things like "MyEnum.allValues[3]” to reference a specific case.
>> 
>> If you know the specific case you are looking for, just write it directly. 
>> If you found an interesting case while iterating allValues, remember its 
>> (opaque) index and come back to it later.
>> 
>> I’m not a fan of Int-indexes in general. It’s practical to allow it for 
>> Array, but in general, for generic Collections, I think it implies an awful 
>> lot of knowledge about the Collection’s contents.
>> 
>> - Karl
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
> ___
> 

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

[C. Keith Ray via swift-evolution]

Simple is better. Int indexes, please. 

--
C. Keith Ray

* https://leanpub.com/wepntk <- buy my book?
* http://www.thirdfoundationsw.com/keith_ray_resume_2014_long.pdf
* http://agilesolutionspace.blogspot.com/

> On Jan 10, 2018, at 10:44 AM, Karl Wagner via swift-evolution 
>  wrote:
> 
> 
> 
>>> On 10. Jan 2018, at 17:22, Paul Cantrell via swift-evolution 
>>>  wrote:
>>> 
>>> What is your evaluation of the proposal?
>> 
>> +1. Yes please. Long overdue.
>> 
>>> Is the problem being addressed significant enough to warrant a change to 
>>> Swift?
>> 
>> It’s a long-standing sore thumb. The proposal’s evidence of community demand 
>> fits my own experience: I’ve wanted this on multiple occasions.
>> 
>>> Does this proposal fit well with the feel and direction of Swift?
>> 
>> Yes, and in particular, on the name bikeshedding:
>> 
>> I favor property names with the “all” prefix, whether allValues or allCases. 
>> Looking over my own code, I’ve almost always used the word “all” for this 
>> when I had to hand-roll it — and either allValues or allCases make 
>> reasonable sense in my code when I substitute them.
>> 
>> Whichever protocol name we choose, the property name should be consistent:
>> 
>>  ValueEnumerable → allValues
>>  CaseEnumerable → allCases
>> 
>> Either ValueEnumerable or CaseEnumerable would be a fine name. Contra Chris, 
>> I slightly prefer ValueEnumerable, because it extends to situations where we 
>> still want to enumerate a fixed set of possibilities which don’t strictly 
>> correspond to enum cases but still have that sort of flavor. For example, 
>> one might want:
>> 
>> enum SideOfBody
>>   {
>>   case left
>>   case right
>>   }
>> 
>> enum Limb: ValueEnumerable
>>   {
>>   case arm(SideOfBody)
>>   case leg(SideOfBody)
>> 
>>   static let allValues =
>> [
>> arm(.left),
>> arm(.right),
>> leg(.left),
>> leg(.right)
>> ]
>>   }
>> 
>> To my eyes, this code reads better than it would with CaseEnumerable / 
>> allCases.
>> 
>>> If you have used other languages or libraries with a similar feature, how 
>>> do you feel that this proposal compares to those?
>> 
>> Java’s enums had this from the beginning, and Josh Bloch’s design for that 
>> feature has always worked nicely. Java’s design is slightly different: 
>> `Foo.values()` returns Foo[]. However, Swift doesn’t need to follow either 
>> that name or type choice: (1) Java doesn’t use the term “case” as Swift 
>> does, (2) the “all” prefix better fits Swift’s API guidelines IMO, and (3) 
>> using a concrete array type has as opposed to Collection has different 
>> implications in Java than it does Swift.
>> 
>> I _do_ agree  that the proposal should consider constraining the Collection 
>> to be Int-indexed. Why should it ever be otherwise? What’s the motivation 
>> for leaving that open?
>> 
>>> How much effort did you put into your review? A glance, a quick reading, or 
>>> an in-depth study?
>> 
>> Medium quick study.
>> 
>> Cheers, P
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> 
> I don’t agree that the Collection should be Int-indexed. Source-order is not 
> a very strong guarantee IMO, and it wouldn’t be good if people started 
> writing things like "MyEnum.allValues[3]” to reference a specific case.
> 
> If you know the specific case you are looking for, just write it directly. If 
> you found an interesting case while iterating allValues, remember its 
> (opaque) index and come back to it later.
> 
> I’m not a fan of Int-indexes in general. It’s practical to allow it for 
> Array, but in general, for generic Collections, I think it implies an awful 
> lot of knowledge about the Collection’s contents.
> 
> - Karl
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Karl Wagner via swift-evolution]

> On 10. Jan 2018, at 17:22, Paul Cantrell via swift-evolution 
>  wrote:
> 
>> What is your evaluation of the proposal?
> 
> +1. Yes please. Long overdue.
> 
>> Is the problem being addressed significant enough to warrant a change to 
>> Swift?
> 
> It’s a long-standing sore thumb. The proposal’s evidence of community demand 
> fits my own experience: I’ve wanted this on multiple occasions.
> 
>> Does this proposal fit well with the feel and direction of Swift?
> 
> Yes, and in particular, on the name bikeshedding:
> 
> I favor property names with the “all” prefix, whether allValues or allCases. 
> Looking over my own code, I’ve almost always used the word “all” for this 
> when I had to hand-roll it — and either allValues or allCases make reasonable 
> sense in my code when I substitute them.
> 
> Whichever protocol name we choose, the property name should be consistent:
> 
>   ValueEnumerable → allValues
>   CaseEnumerable → allCases
> 
> Either ValueEnumerable or CaseEnumerable would be a fine name. Contra Chris, 
> I slightly prefer ValueEnumerable, because it extends to situations where we 
> still want to enumerate a fixed set of possibilities which don’t strictly 
> correspond to enum cases but still have that sort of flavor. For example, one 
> might want:
> 
> enum SideOfBody
>   {
>   case left
>   case right
>   }
> 
> enum Limb: ValueEnumerable
>   {
>   case arm(SideOfBody)
>   case leg(SideOfBody)
> 
>   static let allValues =
> [
> arm(.left),
> arm(.right),
> leg(.left),
> leg(.right)
> ]
>   }
> 
> To my eyes, this code reads better than it would with CaseEnumerable / 
> allCases.
> 
>> If you have used other languages or libraries with a similar feature, how do 
>> you feel that this proposal compares to those?
> 
> Java’s enums had this from the beginning, and Josh Bloch’s design for that 
> feature has always worked nicely. Java’s design is slightly different: 
> `Foo.values()` returns Foo[]. However, Swift doesn’t need to follow either 
> that name or type choice: (1) Java doesn’t use the term “case” as Swift does, 
> (2) the “all” prefix better fits Swift’s API guidelines IMO, and (3) using a 
> concrete array type has as opposed to Collection has different implications 
> in Java than it does Swift.
> 
> I _do_ agree  that the proposal should consider constraining the Collection 
> to be Int-indexed. Why should it ever be otherwise? What’s the motivation for 
> leaving that open?
> 
>> How much effort did you put into your review? A glance, a quick reading, or 
>> an in-depth study?
> 
> Medium quick study.
> 
> Cheers, P
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution


I don’t agree that the Collection should be Int-indexed. Source-order is not a 
very strong guarantee IMO, and it wouldn’t be good if people started writing 
things like "MyEnum.allValues[3]” to reference a specific case.

If you know the specific case you are looking for, just write it directly. If 
you found an interesting case while iterating allValues, remember its (opaque) 
index and come back to it later.

I’m not a fan of Int-indexes in general. It’s practical to allow it for Array, 
but in general, for generic Collections, I think it implies an awful lot of 
knowledge about the Collection’s contents.

- Karl___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Paul Cantrell via swift-evolution]

> What is your evaluation of the proposal?

+1. Yes please. Long overdue.

> Is the problem being addressed significant enough to warrant a change to 
> Swift?

It’s a long-standing sore thumb. The proposal’s evidence of community demand 
fits my own experience: I’ve wanted this on multiple occasions.

> Does this proposal fit well with the feel and direction of Swift?

Yes, and in particular, on the name bikeshedding:

I favor property names with the “all” prefix, whether allValues or allCases. 
Looking over my own code, I’ve almost always used the word “all” for this when 
I had to hand-roll it — and either allValues or allCases make reasonable sense 
in my code when I substitute them.

Whichever protocol name we choose, the property name should be consistent:

ValueEnumerable → allValues
CaseEnumerable → allCases

Either ValueEnumerable or CaseEnumerable would be a fine name. Contra Chris, I 
slightly prefer ValueEnumerable, because it extends to situations where we 
still want to enumerate a fixed set of possibilities which don’t strictly 
correspond to enum cases but still have that sort of flavor. For example, one 
might want:

enum SideOfBody
  {
  case left
  case right
  }

enum Limb: ValueEnumerable
  {
  case arm(SideOfBody)
  case leg(SideOfBody)

  static let allValues =
[
arm(.left),
arm(.right),
leg(.left),
leg(.right)
]
  }

To my eyes, this code reads better than it would with CaseEnumerable / allCases.

> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?

Java’s enums had this from the beginning, and Josh Bloch’s design for that 
feature has always worked nicely. Java’s design is slightly different: 
`Foo.values()` returns Foo[]. However, Swift doesn’t need to follow either that 
name or type choice: (1) Java doesn’t use the term “case” as Swift does, (2) 
the “all” prefix better fits Swift’s API guidelines IMO, and (3) using a 
concrete array type has as opposed to Collection has different implications in 
Java than it does Swift.

I _do_ agree  that the proposal should consider constraining the Collection to 
be Int-indexed. Why should it ever be otherwise? What’s the motivation for 
leaving that open?

> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?

Medium quick study.

Cheers, P

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Brent Royal-Gordon via swift-evolution]

> On Jan 9, 2018, at 10:26 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> I continue to have concerns about this proposal, and I'm gravely and very 
> bitterly disappointed that the concerns have not even been acknowledged in 
> the Alternatives section, which is in my view the minimum action that an 
> author should take when points are raised during a pitch phase, even (and 
> especially) when the author disagrees, along with a cogent write-up of why 
> the proposed design is superior in the author's view to the alternative. In 
> this case, the proposal authors write:
> 
>   "The community has not raised any solutions whose APIs differ significantly 
> from this proposal, except for solutions which provide strictly more 
> functionality."
> 
> This is false, as I have offered a solution in the past whose API differs 
> entirely from this proposal, and which provides strictly a subset of the 
> functionality which goes to the core of the issue at stake.

I can't speak for the other co-authors, but for my part, this was an oversight 
and I apologize for it. I think we should have discussed your `MyType.self` 
alternative.

I won't rehash the entire discussion in previous threads, but to summarize my 
objections:

1. `MyType.self` is harder to understand for someone who's never seen 
it than `MyType.allValues`. For instance, the expression 
`AccountStatus.allValues[0]` is completely self-explanatory, while 
`AccountStatus.self[0]` is more obscure and would require a trip to the 
documentation. (And since `self` here is a language keyword, not a real member, 
the most obvious route to the documentation is not available.) In my opinion, 
we should not prefer the `MyType.self` syntax.

2. Even if the community disagrees with me and thinks `MyType.self` is 
a better syntax than `MyType.allValues`, it is not better *enough* to outweigh 
the costs:

• The metatype solution provides no additional functionality; 
it is merely a matter of which syntax we choose to support, and how much effort 
this support requires.

• Conforming the metatype to `Collection` requires a lot of 
type system features we do not currently have. Currently, structural types 
cannot conform to protocols, and metatypes are a structural type. Metatypes 
also cannot have subscripts currently. Your proposed design has a lot of 
prerequisites. That is not in and of itself disqualifying, but it should be 
weighed against it.

• You suggest that we should add bits and pieces of 
"`Collection` functionality" incrementally as engineering resources become 
available. The problem is that the most valuable part of the "`Collection` 
functionality" is conformance to `Collection` or at least `Sequence`, not the 
existence of any particular members of `Collection`, and this is the part that 
would require the most engineering resources.

• A large part of the work we would do before supporting this 
conformance would be disposed of immediately once we could get it. For 
instance, all of the work to support having a metatype instead of a sequence in 
a `for-in` statement would be thrown away as soon as we could conform to 
`Sequence`. So this looks less like slowly building up pieces of the feature 
until we have all of them in place, and more like creating temporary hacks to 
emulate the feature until we have the time to do it right.

• While this feature is not a showstopper, it is a highly 
desirable convenience. The proposal documents the high demand for this feature, 
so I won't elaborate on this point further.

• Therefore, adopting this design would add a lot of 
engineering complexity before we could fully support a highly desirable 
feature, merely to get a syntax that we *might* prefer.

To summarize the summary: The primary advantage of `MyType.self` is that it's 
elegant. To get that elegance, we must trade away getting a fully-functional 
implementation sooner, spending a lot of engineering resources (much of which 
would be wasted in the end), and—most crucially in my opinion—clarity at the 
point of use. It's not worth it.

> Earlier in this thread (or was it in the companion one?), another community 
> member suggested that if `allValues` were to conform to `Sequence` instead of 
> `Collection`, then even types that have an infinite number of possible values 
> could conform to `ValueEnumerable`. Here's the rub: the definition of a type, 
> or at least one of them, _is_ precisely the set of all possible values of a 
> variable. If unconstrained by finiteness, then *all types* would meet the 
> semantic requirements of `ValueEnumerable`.

Not quite. There are types whose valid values are unknowable; for instance, a 
type representing "the ID of a record on the server" cannot know which IDs 
actually exist on the server, merely which ones *could* exist, and so an 
implementation of `allValues` would 

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

[Antoine Cœur via swift-evolution]

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 that we can write:

Ma.count   // returns 8
Ma.map { return "\($0)" }   // returns a stringification

A little bit like what was done on String when we dropped the requirement
of writing `.characters`, it would be perfect to directly drop the
requirement of writing `.allValues`.

Le mer. 10 janv. 2018 à 14:40, Chris Lattner via swift-evolution <
swift-evolution@swift.org> a écrit :

> On Jan 9, 2018, at 10:26 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> 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 semantics that
> make possible useful generic algorithms) are so broad as to be little more
> than essentially what it means to be a type.
>
> Thank you for writing this up Xiaodi.  I completely agree with you that
> “CaseEnumerable” is a better name for this: it is more specific and
> purposeful and make it more clear what the purpose and scope is.
>
> Your later suggestion of “Enumerable” seems to broad and potentially
> confusing to me.  Tying it to the things that are being enumerated (enum
> cases) seems more purposeful.
>
>
> > Brent just wrote that he might later propose to extend `ValueEnumerable`
> to `Bool` and `Optional`,
>
> To be fair, Optional *is* an enum, and Bool really should be (we only
> switched it to its current design for internal optimizer reasons).
>
> Making Bool conform to this would require manual conformance - if we were
> motivated to give Bool all the enum-like facilities (including a Bool.true
> and Bool.false member) then having it conform seems conceptually fine to me.
>
> I would personally object to attempts to make optional conform though. One
> of its cases has an associated value and this isn’t something we should
> support IMO.  I believe that this is one of the roots of your objection.
>
> -Chris
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Chris Lattner via swift-evolution]

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 semantics that make possible 
> useful generic algorithms) are so broad as to be little more than essentially 
> what it means to be a type.

Thank you for writing this up Xiaodi.  I completely agree with you that 
“CaseEnumerable” is a better name for this: it is more specific and purposeful 
and make it more clear what the purpose and scope is.

Your later suggestion of “Enumerable” seems to broad and potentially confusing 
to me.  Tying it to the things that are being enumerated (enum cases) seems 
more purposeful.


> Brent just wrote that he might later propose to extend `ValueEnumerable` to 
> `Bool` and `Optional`,

To be fair, Optional *is* an enum, and Bool really should be (we only switched 
it to its current design for internal optimizer reasons).  

Making Bool conform to this would require manual conformance - if we were 
motivated to give Bool all the enum-like facilities (including a Bool.true and 
Bool.false member) then having it conform seems conceptually fine to me.

I would personally object to attempts to make optional conform though. One of 
its cases has an associated value and this isn’t something we should support 
IMO.  I believe that this is one of the roots of your objection.

-Chris


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

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:
>
> https://github.com/apple/swift-evolution/blob/master/
> proposals/0194-derived-collection-of-enum-cases.md
>
> Reviews are an important part of the Swift evolution process. All reviews
> should be sent to the swift-evolution mailing list at
>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> or, if you would like to keep your feedback private, directly to the
> review manager. When replying, please try to keep the proposal link at the
> top of the message:
>
> Proposal link:
>
> https://github.com/apple/swift-evolution/blob/master/
> proposals/0194-derived-collection-of-enum-cases.md
>
> Reply text
>
> Other replies
>
>
> What
> goes into a review?
>
> The goal of the review process is to improve the proposal under review
> through constructive criticism and, eventually, determine the direction of
> Swift. When writing your review, here are some questions you might want to
> answer in your review:
>
>- What is your evaluation of the proposal?
>
> I continue to have concerns about this proposal, and I'm gravely and very
bitterly disappointed that the concerns have not even been acknowledged in
the Alternatives section, which is in my view the minimum action that an
author should take when points are raised during a pitch phase, even (and
especially) when the author disagrees, along with a cogent write-up of why
the proposed design is superior in the author's view to the alternative. In
this case, the proposal authors write:

  "The community has not raised any solutions whose APIs differ
significantly from this proposal, except for solutions which provide
strictly more functionality."

This is false, as I have offered a solution in the past whose API differs
entirely from this proposal, and which provides strictly a subset of the
functionality which goes to the core of the issue at stake.

In the past, I have stated on this list that once a statement has been
made, it should not be repeated simply because one is disappointed in the
outcome, as one should operate on the presumption that all actors proceed
in good faith and have already considered the statement. Here, however,
given that the write-up literally denies the existence of what I have
already written, I will restate my concerns here once again. I would expect
that on revision the authors will properly record a considered reply.

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 semantics that make possible
useful generic algorithms) are so broad as to be little more than
essentially what it means to be a type.

Earlier in this thread (or was it in the companion one?), another community
member suggested that if `allValues` were to conform to `Sequence` instead
of `Collection`, then even types that have an infinite number of possible
values could conform to `ValueEnumerable`. Here's the rub: the definition
of a type, or at least one of them, _is_ precisely the set of all possible
values of a variable. If unconstrained by finiteness, then *all types*
would meet the semantic requirements of `ValueEnumerable`.

As proposed, "`ValueEnumerable`...indicate[s] that a type has a finite,
enumerable set of values"; now, we have the constraint that the type merely
must have an upper bound in terms of memory referenced. Brent just wrote
that he might later propose to extend `ValueEnumerable` to `Bool` and
`Optional`, but theoretically and practically speaking it appears that it
can correctly be extended to any type in the standard library that is not a
`Sequence`, and with minimal effort even `Collection` types of fixed size
(e.g., CollectionOfOne with the right constraints as to the generic type
T).

Put another way, there are two issues with generalizing the very specific
use case of "I want to know all the cases of an enum" to what is proposed
here in terms of a protocol. First, "ValueEnumerable"-ness is neither
universal to all enums (as those with associated types, indirect cases
(think of all those tutorials about linked lists implemented as Swift
enums), etc., are clearly not enumerable) nor unique as a property of
enums, yet this proposal first makes a large generalization of the proposed
protocol's semantics when the stated motivation is only about enums, then
proceeds only to implement protocol conformance for enums. Second, the
collection of all values is properly just the type and not a property of
the type, for the reasons outlined above.

So far, the justification I have heard for ignoring this objection is that
(a) lots of people want the 

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

[Vladimir.S via swift-evolution]

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


  


  * What is your evaluation of the proposal?

+1 on the general problem, but I have a few comments on the design specifics

- I'd very much prefer automatic synthesis with enums,
- I strongly feel the compiler should auto-generate the implementation in an 
extension for enums.
- Should we add `ValueCollection.Index == Int` to the associatedtype so it can 
always be indexed as in a table?
   - At the least, we should ensure the synthesized implementation is 
int-indexed for tables.
- I feel we should allow auto-generation of imported c enums in an extension, as just an array of the known cases rather 
than the magical metadata iterator if necessary.




FWIW +1 for all Kevin said


  * Is the problem being addressed significant enough to warrant a change to 
Swift?

Definitely. It's been a gaping hole in the language since the beginning.


  * Does this proposal fit well with the feel and direction of Swift?

Yes


  * If you have used other languages or libraries with a similar feature, how 
do you feel that this proposal compares
to those?

I prefer Java's automatic allValues(), but this is better than nothing.


  * How much effort did you put into your review? A glance, a quick reading, or 
an in-depth study?

Followed at least the start of several threads and read the proposal.


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Cheyo Jimenez via swift-evolution]

> 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 general problem, but I have a few comments on the design specifics
> 
> - I'd very much prefer automatic synthesis with enums, 
> - I strongly feel the compiler should auto-generate the implementation in an 
> extension for enums.
> - Should we add `ValueCollection.Index == Int` to the associatedtype so it 
> can always be indexed as in a table? 
>   - At the least, we should ensure the synthesized implementation is 
> int-indexed for tables.
> - I feel we should allow auto-generation of imported c enums in an extension, 
> as just an array of the known cases rather than the magical metadata iterator 
> if necessary. 
> 
+1 for known cases at compile time. 


>> Is the problem being addressed significant enough to warrant a change to 
>> Swift?
> Definitely. It's been a gaping hole in the language since the beginning.
> 
>> Does this proposal fit well with the feel and direction of Swift?
> Yes
> 
>> If you have used other languages or libraries with a similar feature, how do 
>> you feel that this proposal compares to those?
> I prefer Java's automatic allValues(), but this is better than nothing.
> 
>> How much effort did you put into your review? A glance, a quick reading, or 
>> an in-depth study?
> Followed at least the start of several threads and read the proposal.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Kevin Nattinger via swift-evolution]

> 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 general problem, but I have a few comments on the design specifics

- I'd very much prefer automatic synthesis with enums, 
- I strongly feel the compiler should auto-generate the implementation in an 
extension for enums.
- Should we add `ValueCollection.Index == Int` to the associatedtype so it can 
always be indexed as in a table? 
  - At the least, we should ensure the synthesized implementation is 
int-indexed for tables.
- I feel we should allow auto-generation of imported c enums in an extension, 
as just an array of the known cases rather than the magical metadata iterator 
if necessary. 

> Is the problem being addressed significant enough to warrant a change to 
> Swift?
Definitely. It's been a gaping hole in the language since the beginning.

> Does this proposal fit well with the feel and direction of Swift?
Yes

> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
I prefer Java's automatic allValues(), but this is better than nothing.

> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
Followed at least the start of several threads and read the proposal.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Daniel Steinberg via swift-evolution]

> 
> 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 in more places where 
they are appropriate
> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
A quick reading and followed the issue when it came up before. 
> More information about the Swift evolution process is available at
> 
> https://github.com/apple/swift-evolution/blob/master/process.md 
> 
> Thank you,
> 
> -Doug Gregor
> 
> Review Manager
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Riley Testut via swift-evolution]

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 over all values that 
the author didn’t foresee, and I would very much like the client to be able to 
opt-in to the compiler code generation.

(Personally, I’d prefer that all simple enums automatically conform to the 
protocol and have automatic implementations, since I don’t really see a 
downside to this that exists for some other compiler-magic protocols like 
Codable)

> On Jan 9, 2018, at 8:45 AM, Tony Allevato via swift-evolution 
>  wrote:
> 
>> On Mon, Jan 8, 2018 at 11:02 AM Douglas Gregor via swift-evolution 
>>  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:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0194-derived-collection-of-enum-cases.md
>> Reviews are an important part of the Swift evolution process. All reviews 
>> should be sent to the swift-evolution mailing list at
>> 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> or, if you would like to keep your feedback private, directly to the review 
>> manager. When replying, please try to keep the proposal link at the top of 
>> the message:
>> 
>> Proposal link:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0194-derived-collection-of-enum-cases.md
>> Reply text
>> Other replies
>> What goes into a review?
>> 
>> The goal of the review process is to improve the proposal under review 
>> through constructive criticism and, eventually, determine the direction of 
>> Swift. When writing your review, here are some questions you might want to 
>> answer in your review:
>> 
>> What is your evaluation of the proposal?
> Big +1. I've been looking forward to something like this for a long time.
> 
> I'm extremely happy with the API chosen here. ValueEnumerable and allValues 
> are absolutely the correct names, because the protocol is not *restricted* to 
> enums, it is merely *synthesized automatically* for enums. That's a very 
> important distinction. Someone could provide their own conformance to 
> ValueEnumerable and use it in generic algorithms and have everything work as 
> expected.
> 
> In a perfect world I would argue that the associated type of allValues should 
> be a Sequence instead of a Collection as this would allow it to be extended 
> to infinite sequences (i.e., cases with associated values that are deeply 
> ValueEnumerable), but I'll admit that I've never come up with a compelling 
> use case for this beyond obscure combinatorial algorithms. Since getting the 
> count of values is important to many users, Collection is a reasonable 
> compromise and I don't have any objections.
>  
>> Is the problem being addressed significant enough to warrant a change to 
>> Swift?
> Yes. It's a frequently requested feature and has utility both in UI-driven 
> logic (table view sections based on an enum) and other algorithms.
> 
>  
>> Does this proposal fit well with the feel and direction of Swift?
> Yes. The API design fits right into other stdlib concepts, and the conditions 
> for synthesis align with the synthesis of other synthesized protocols.
> 
>  
>> If you have used other languages or libraries with a similar feature, how do 
>> you feel that this proposal compares to those?
> Just Java's values() function that is present on all enums. The functionality 
> provided here is what I would expect, similar to other languages.
> 
>  
>> How much effort did you put into your review? A glance, a quick reading, or 
>> an in-depth study?
> An in-depth read and I was heavily involved in some of the earlier discussion 
> threads.
> 
>  
>> More information about the Swift evolution process is available at
>> 
>> https://github.com/apple/swift-evolution/blob/master/process.md
>> Thank you,
>> 
>> -Doug Gregor
>> 
>> Review Manager
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Tony Allevato via swift-evolution]

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:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0194-derived-collection-of-enum-cases.md
>
> Reviews are an important part of the Swift evolution process. All reviews
> should be sent to the swift-evolution mailing list at
>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> or, if you would like to keep your feedback private, directly to the
> review manager. When replying, please try to keep the proposal link at the
> top of the message:
>
> Proposal link:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0194-derived-collection-of-enum-cases.md
>
> Reply text
>
> Other replies
>
>
> What
> goes into a review?
>
> The goal of the review process is to improve the proposal under review
> through constructive criticism and, eventually, determine the direction of
> Swift. When writing your review, here are some questions you might want to
> answer in your review:
>
>- What is your evaluation of the proposal?
>
> Big +1. I've been looking forward to something like this for a long time.

I'm extremely happy with the API chosen here. ValueEnumerable and allValues
are absolutely the correct names, because the protocol is not *restricted*
to enums, it is merely *synthesized automatically* for enums. That's a very
important distinction. Someone could provide their own conformance to
ValueEnumerable and use it in generic algorithms and have everything work
as expected.

In a perfect world I would argue that the associated type of allValues
should be a Sequence instead of a Collection as this would allow it to be
extended to infinite sequences (i.e., cases with associated values that are
deeply ValueEnumerable), but I'll admit that I've never come up with a
compelling use case for this beyond obscure combinatorial algorithms. Since
getting the count of values is important to many users, Collection is a
reasonable compromise and I don't have any objections.


>
>- Is the problem being addressed significant enough to warrant a
>change to Swift?
>
> Yes. It's a frequently requested feature and has utility both in UI-driven
logic (table view sections based on an enum) and other algorithms.



>
>- Does this proposal fit well with the feel and direction of Swift?
>
> Yes. The API design fits right into other stdlib concepts, and the
conditions for synthesis align with the synthesis of other synthesized
protocols.



>
>- If you have used other languages or libraries with a similar
>feature, how do you feel that this proposal compares to those?
>
> Just Java's values() function that is present on all enums. The
functionality provided here is what I would expect, similar to other
languages.



>
>- How much effort did you put into your review? A glance, a quick
>reading, or an in-depth study?
>
> An in-depth read and I was heavily involved in some of the earlier
discussion threads.



> More information about the Swift evolution process is available at
>
> https://github.com/apple/swift-evolution/blob/master/process.md
>
> Thank you,
>
> -Doug Gregor
>
> Review Manager
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Cheyo Jimenez via swift-evolution]

> What is your evaluation of the proposal?
+1
How does this work with public non exhaustive enums?

Can we have a version of this that is compile time only? This would be very 
helpful specially if non exhaustive enums make it into the language. Perhaps 
also having compile time allCases could also gets us closer to objc enum 
support. 

I much rather take the extra copy of all the cases in my binary than having 
surprising results during runtime (new cases or removed cases).

> 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
> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
N/a
> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
Followed the first PR and most of the discussions. ___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Waite via swift-evolution]

> https://github.com/apple/swift-evolution/blob/master/proposals/0194-derived-collection-of-enum-cases.md
>  
> 
> What is your evaluation of the proposal?
Generally +1

I would like the behavior of the generated ValueEnumerable to be defined, even 
if that behavior is based on the proposed implementation. Would this be 
declaration order? Would it be out of declaration order if a raw integer value 
was used and the cases did not have consistently increasing raw values?

I don’t know if there is an application compatibility suggestion here, such as 
‘new enumerable values should be added to the end’.

I can also understand the value of not having the static property be an 
Array to save memory, but instead be Array-like. To this end, I think the 
allValues property should have an additional constraint of an Index 
associatedtype of Int. I don’t know if there is an additional requirement for 
the indices being all the values from 0.. Is the problem being addressed significant enough to warrant a change to 
> Swift?
I think so.

> Does this proposal fit well with the feel and direction of Swift?
Yes.

> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
I use Java’s version of this feature a fair bit. One common extension I see is 
to convert textual names to enum values, something that it doesn’t support well 
natively. 

> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
A quick reading

-DW___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Letanyan Arumugam via swift-evolution]

> What is your evaluation of the proposal?
+1 This is a very useful feature.


> Is the problem being addressed significant enough to warrant a change to 
> Swift?
Yes for what I’ve wanted to do.

> Does this proposal fit well with the feel and direction of Swift?
It fits the design of similar synthesis features in the language.

> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
Have not used a similar feature

> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
A couple read throughs

> More information about the Swift evolution process is available at
> 
> https://github.com/apple/swift-evolution/blob/master/process.md 
> 
> Thank you,
> 
> -Doug Gregor
> 
> Review Manager
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jarod Long via swift-evolution]

>
> • What is your evaluation of the proposal?
>
+1, very happy to see this coming together! I've been interested in this 
feature since the early days of Swift.

My only reservation is that I would have expected to be able to access the list 
of values without any extra annotations. Is there a reason to not automatically 
give ValueEnumerable conformance to any enum that fits the criteria for 
synthesis?

>
> • Is the problem being addressed significant enough to warrant a change to 
> Swift?
>
Definitely, for the reasons mentioned in the proposal's motivation.

>
> • Does this proposal fit well with the feel and direction of Swift?
>
Yes, this feels like a very natural addition to the language.

>
> • If you have used other languages or libraries with a similar feature, how 
> do you feel that this proposal compares to those?
>
I've used the GetValues API in C#, and though I think the proposed API is a 
much better fit for Swift, I did appreciate that GetValues could be used on any 
enum without needing to opt in manually.

>
> • How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
>
Full reading.


Jarod
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Rod Brown via swift-evolution]

> What is your evaluation of the proposal?
+1 to the idea. Disappointing that we don’t seem to be able to add this to 
@objc enums. Could we come up with some kind of workaround for this?

> Is the problem being addressed significant enough to warrant a change to 
> Swift?
Yes, this is a common problem where I constantly write all case static 
properties, and where I use the count. To be honest, for such a robust system, 
I found it a glaring omission.

> Does this proposal fit well with the feel and direction of Swift?
Yes, the way the proposed solution is designed seems to work well.

> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
I’ve done a lot of hacked enum “allCases” implementations in Swift, and we 
really didn’t have this power in the other languages I’ve used.

> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
Quick reading.

Sent from my iPad

> On 9 Jan 2018, at 6:02 am, Douglas Gregor via swift-evolution 
>  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:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0194-derived-collection-of-enum-cases.md
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
> https://lists.swift.org/mailman/listinfo/swift-evolution
> or, if you would like to keep your feedback private, directly to the review 
> manager. When replying, please try to keep the proposal link at the top of 
> the message:
> 
> Proposal link:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0194-derived-collection-of-enum-cases.md
> Reply text
> Other replies
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. When writing your review, here are some questions you might want to 
> answer in your review:
> 
> What is your evaluation of the proposal?
> Is the problem being addressed significant enough to warrant a change to 
> Swift?
> Does this proposal fit well with the feel and direction of Swift?
> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
> More information about the Swift evolution process is available at
> 
> https://github.com/apple/swift-evolution/blob/master/process.md
> Thank you,
> 
> -Doug Gregor
> 
> Review Manager
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Hart via swift-evolution]

> What is your evaluation of the proposal?
I’m hugely in favour of the proposal but am quite worried about that fact that 
ValueEnumerable will not work for @objc enums and enums imported from C/Obj-C 
headers. It seems like a very common scenario and the lack of support for it 
will be both surprising and fustrating. Is there no way around it?

> 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, apart from the Objective-C support.

> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
Very few languages provide this functionality and I am very happy that Swift is 
finally providing it.

> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
Several reads.

> More information about the Swift evolution process is available at
> 
> https://github.com/apple/swift-evolution/blob/master/process.md 
> 
> Thank you,
> 
> -Doug Gregor
> 
> Review Manager
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution