<div dir="ltr">Thanks for the feedback, Brent! Responses inline:<div class="gmail_extra">
<br><div class="gmail_quote">On Mon, Jan 18, 2016 at 9:17 PM, Brent Royal-Gordon <span dir="ltr"><<a href="mailto:brent@architechies.com" target="_blank">brent@architechies.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">> • CaseEnumerable could have a user-visible declaration requiring static var cases, which would allow users to add conformances for custom non-enum types.<br>
<br>
I think this is an excellent idea. As Joe points out, this would imply that the protocol and property should have names which don't include the word "case". (Renaming is also a good idea because if the property is `cases`, you'll be tempted to say `for case in Foo.cases`, but `for case` will be misparsed.)<br>
<br>
Simply start the discussion, I suggest this definition:<br>
<br>
/// Any type which can only take on one of a limited, easily enumerable list of values may<br>
/// conform to FiniteType to make that list easy to access. For certain simple types,<br>
/// Swift will automatically generate an implementation of `values`.<br>
protocol FiniteType {<br>
/// A collection containing all possible values of this type.<br>
///<br>
/// Invariant: T.values.contains(valueOfTypeT) for any valueOfTypeT. In other words, `values`<br>
/// must be truly exhaustive.<br>
static var values: ...<br>
}<br></blockquote><div><br></div><div>OK, I can see the argument here. I was worried about making this proposal so broad that it wouldn't be seriously considered, but I agree that choosing more general names will open it up to future expansion.</div><div><br></div><div>Here are some more name ideas:</div><div><br></div><div>- CaseEnumerable (in the proposal draft)<br class="">- T.cases (in the proposal draft)<br></div><div>- T.allCases</div><div>- FiniteType (as you suggested)</div><div>- FiniteValueType</div><div>- ValueEnumerable</div><div>- T.values</div><div>- T.allValues</div><div><br></div><div>Thoughts? More suggestions? I think I like ValueEnumerable.</div><div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
> • This would probably require cases to be AnySequence<Self>, or to introduce an AnyCollection, since we aren't able to say associatedtype CaseCollection: CollectionType where CaseCollection.Generator.Element == Self.<br>
<br>
Ouch, that's an ugly limitation. Is this going to change in Swift 3?<br></blockquote><div><br></div><div>I can't speak to that. You might want to search the list to see if you can find what's been said about the plan for Swift 3 generics so far.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">> • It would be nice to have a way of supporting this for OptionSetType structs. I would recommend that cases for an OptionSetType should include only the already-declared static properties (not all possible combinations of them). However, I'm not sure it fits into this proposal.<br>
<br>
Theoretically, `cases` on an OptionSetType should return all combinations of options, so I think we'd need something different there.<br></blockquote><div><br></div><div>As a user, I'd really love to be able to enumerate the individual "bits" of an OptionSetType, such as all the NSWindow styleMask types: Borderless, Titled, etc. .cases or .values seems to be a natural place to return those, but I guess you're right that these wouldn't really encompass <b>all</b> possible cases/values, so maybe it doesn't fit as well as I'd hope.</div><div><br></div><div>Is it too crazy to suggest synthesizing a collection of all the <b>static members</b> of a type which are of type Self? This would cover enum cases and OptionSetType fields.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
> • Support for enum case names. It would be useful to get case names even for enums which have integer rawValues. This could be part of the existing reflection APIs, or it could take the form of derived implementations of StringLiteralConvertible/CustomStringConvertible.<br>
<br>
I very strongly believe this is a job for reflection, not for our case mechanism. (So, I agree with you.)<br></blockquote><div><br></div><div>Playing devil's advocate: if handling names are a job for reflection, why isn't getting all cases/values also a job for reflection?</div><div><br></div><div>Jacob</div></div></div></div>