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

2017-12-30 Thread Matthew Johnson via swift-evolution 
This looks really nice.  Thank you for doing the legwork of researching 
previous discussions and writing up a detailed proposal!

The motivation discusses the common use case of using an enum in a data source 
implementation which requires 0-based Int indices.  However, the proposed 
solution as-written does not specifically address this use case.  Is the intent 
that the compiler-synthesized implementation always uses indices meeting 
0-based Int requirement?  If so it is probably worth stating this explicitly in 
the proposal.

Sent from my iPad

> On Dec 30, 2017, at 5:12 PM, Jacob Bandes-Storch via swift-evolution 
>  wrote:
> 
> Sorry for the delay. I've just updated the proposal text to incorporate 
> various changes, some contributed by others.
> 
> https://github.com/jtbandes/swift-evolution/blob/case-enumerable/proposals/-derived-collection-of-enum-cases.md
> 
> Robert's implementation is a good start, but will need to be updated to match 
> the naming choice in the final proposal, and to use associatedtype.
> 
>> On Fri, Dec 8, 2017 at 9:19 PM, Step Christopher 
>>  wrote:
>> Has this stalled out again? I would like to help with the proposal and even 
>> attempt implementation. 
>> 
>> I also need to catch up on the resilient discussion regarding enum case 
>> ordering. 
>> 
>>> On Nov 14, 2017, at 10:50 PM, Jacob Bandes-Storch via swift-evolution 
>>>  wrote:
>>> 
>>> 
>>> 
>>> Jacob Bandes-Storch
>>> 
>>> On Tue, Nov 14, 2017 at 9:06 PM, Brent Royal-Gordon 
>>>  wrote:
>> On Nov 14, 2017, at 5:21 PM, Xiaodi Wu  wrote:
>> 
>> 1. It must be possible to easily access the count of values, and to 
>> access any particular value using contiguous `Int` indices. This could 
>> be achieved either by directly accessing elements in the list of values 
>> through an Int subscript, or by constructing an Array from the list of 
>> values.
>> 
>> 2. It must be possible to control the order of values in the list of 
>> values, either by using source order or through some other simple, 
>> straightforward mechanism.
>  
> OK, first of all, nowhere in the proposal text are these requirements 
> stated as part of the use case. You're free to put forward new use cases, 
> but here I am trying to design the most elegant way to fulfill a stated 
> need and you're telling me that it's something other than what's written.
 
 Honestly, re-reading the proposal, it never cites a fully-formed use case. 
 Instead, it cites several blog posts, Stack Overflow questions, and small 
 code samples without digging in to the underlying reasons why developers 
 are doing what they're doing. Most of the people discussing it so far seem 
 to have had a tacit understanding that we wanted roughly Array-like 
 access, but we haven't explicitly dug into which properties of an Array 
 are important.
 
 (If anyone involved feels like they had a different understanding of the 
 use case, please speak up.)
 
 I think this is a place where the proposal can be improved, and I'm 
 willing to do some writing to improve it.
>>> 
>>> For the record, I would be happy to add co-authors (or even relinquish 
>>> authorship entirely—I don't really care whose name is on this, it just 
>>> needs to happen!) if you or anyone else has improved wording, motivation, 
>>> justification, etc. to contribute.
>>> ___
>>> 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] [swift-dev] Re-pitch: Deriving collections of enum cases

2017-12-30 Thread Jacob Bandes-Storch via swift-evolution 
Re-reading this thread and thinking about it more, I think I agree :)
Updating again...

On Sat, Dec 30, 2017 at 3:44 PM, Chris Lattner  wrote:

> On Dec 30, 2017, at 3:12 PM, Jacob Bandes-Storch via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Sorry for the delay. I've just updated the proposal text to incorporate
> various changes, some contributed by others.
>
> https://github.com/jtbandes/swift-evolution/blob/case-
> enumerable/proposals/-derived-collection-of-enum-cases.md
>
>
> I would really love to see this happen.  I did a pass over the proposal, I
> strong suggest that you get Joe Groff’s input on this, because he has some
> opinions as well.
>
> IMO, the proposal looks really great except for one thing:   In "proposed
> solution”, I think it is very important that conformance to ValueEnumerable
> be explicitly requested in the code.  Specifically:
>
> enum Ma { case 马, 吗, 妈, 码, 骂, 麻, 🐎, 🐴 }
> Ma.allValues   // error.
>
> enum Ma : ValueEnumerable { case 马, 吗, 妈, 码, 骂, 麻, 🐎, 🐴 }
> Ma.allValues   // works!
>
>
> This is for two reasons:
> 1) Consistency with other similar features in Swift.  Types are not
> hashable just because their members could be.  This is because we want
> people to think about and explicitly opt into API features like this.
> 2) To align with our resilience design.  An enum with no value-associated
> cases today could acquire them in the future, and doing so would implicitly
> remove this conformance.  This would be surprising and bad.
>
> Thanks for pushing this forward!
>
> -Chris
>
>
>
>
>
>
> Robert's implementation
>  is
> a good start, but will need to be updated to match the naming choice in the
> final proposal, and to use associatedtype.
>
> On Fri, Dec 8, 2017 at 9:19 PM, Step Christopher <
> schristop...@bignerdranch.com> wrote:
>
>> Has this stalled out again? I would like to help with the proposal and
>> even attempt implementation.
>>
>> I also need to catch up on the resilient discussion regarding enum case
>> ordering.
>>
>> On Nov 14, 2017, at 10:50 PM, Jacob Bandes-Storch via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>
>>
>> Jacob Bandes-Storch
>>
>> On Tue, Nov 14, 2017 at 9:06 PM, Brent Royal-Gordon <
>> br...@architechies.com> wrote:
>>
>>> On Nov 14, 2017, at 5:21 PM, Xiaodi Wu  wrote:
>>>
>>> 1. It must be possible to easily access the count of values, and to
 access any particular value using contiguous `Int` indices. This could be
 achieved either by directly accessing elements in the list of values
 through an Int subscript, or by constructing an Array from the list of
 values.

 2. It must be possible to control the order of values in the list of
 values, either by using source order or through some other simple,
 straightforward mechanism.

>>>
>>> OK, first of all, nowhere in the proposal text are these requirements
>>> stated as part of the use case. You're free to put forward new use cases,
>>> but here I am trying to design the most elegant way to fulfill a stated
>>> need and you're telling me that it's something other than what's written.
>>>
>>>
>>> Honestly, re-reading the proposal, it never cites a fully-formed use
>>> case. Instead, it cites several blog posts, Stack Overflow questions, and
>>> small code samples without digging in to the underlying reasons why
>>> developers are doing what they're doing. Most of the people discussing it
>>> so far seem to have had a tacit understanding that we wanted roughly
>>> Array-like access, but we haven't explicitly dug into which properties of
>>> an Array are important.
>>>
>>> (If anyone involved feels like they had a different understanding of the
>>> use case, please speak up.)
>>>
>>> I think this is a place where the proposal can be improved, and I'm
>>> willing to do some writing to improve it.
>>>
>>
>> For the record, I would be happy to add co-authors (or even relinquish
>> authorship entirely—I don't really care whose name is on this, it just
>> needs to happen!) if you or anyone else has improved wording, motivation,
>> justification, etc. to contribute.
>>
>> ___
>> 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] [swift-dev] Re-pitch: Deriving collections of enum cases

2017-12-30 Thread Chris Lattner via swift-evolution 
On Dec 30, 2017, at 3:12 PM, Jacob Bandes-Storch via swift-evolution 
 wrote:
> Sorry for the delay. I've just updated the proposal text to incorporate 
> various changes, some contributed by others.
> 
> https://github.com/jtbandes/swift-evolution/blob/case-enumerable/proposals/-derived-collection-of-enum-cases.md
>  
> 
I would really love to see this happen.  I did a pass over the proposal, I 
strong suggest that you get Joe Groff’s input on this, because he has some 
opinions as well.

IMO, the proposal looks really great except for one thing:   In "proposed 
solution”, I think it is very important that conformance to ValueEnumerable be 
explicitly requested in the code.  Specifically:

enum Ma { case 马, 吗, 妈, 码, 骂, 麻, 🐎, 🐴 }
Ma.allValues   // error.

enum Ma : ValueEnumerable { case 马, 吗, 妈, 码, 骂, 麻, 🐎, 🐴 }
Ma.allValues   // works!


This is for two reasons:
1) Consistency with other similar features in Swift.  Types are not hashable 
just because their members could be.  This is because we want people to think 
about and explicitly opt into API features like this.
2) To align with our resilience design.  An enum with no value-associated cases 
today could acquire them in the future, and doing so would implicitly remove 
this conformance.  This would be surprising and bad.

Thanks for pushing this forward!

-Chris






> Robert's implementation 
>  is 
> a good start, but will need to be updated to match the naming choice in the 
> final proposal, and to use associatedtype.
> 
> On Fri, Dec 8, 2017 at 9:19 PM, Step Christopher 
> mailto:schristop...@bignerdranch.com>> wrote:
> Has this stalled out again? I would like to help with the proposal and even 
> attempt implementation. 
> 
> I also need to catch up on the resilient discussion regarding enum case 
> ordering. 
> 
> On Nov 14, 2017, at 10:50 PM, Jacob Bandes-Storch via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
>> 
>> 
>> Jacob Bandes-Storch
>> 
>> On Tue, Nov 14, 2017 at 9:06 PM, Brent Royal-Gordon > > wrote:
>>> On Nov 14, 2017, at 5:21 PM, Xiaodi Wu >> > wrote:
>>> 
>>> 1. It must be possible to easily access the count of values, and to access 
>>> any particular value using contiguous `Int` indices. This could be achieved 
>>> either by directly accessing elements in the list of values through an Int 
>>> subscript, or by constructing an Array from the list of values.
>>> 
>>> 2. It must be possible to control the order of values in the list of 
>>> values, either by using source order or through some other simple, 
>>> straightforward mechanism.
>>>  
>>> OK, first of all, nowhere in the proposal text are these requirements 
>>> stated as part of the use case. You're free to put forward new use cases, 
>>> but here I am trying to design the most elegant way to fulfill a stated 
>>> need and you're telling me that it's something other than what's written.
>> 
>> Honestly, re-reading the proposal, it never cites a fully-formed use case. 
>> Instead, it cites several blog posts, Stack Overflow questions, and small 
>> code samples without digging in to the underlying reasons why developers are 
>> doing what they're doing. Most of the people discussing it so far seem to 
>> have had a tacit understanding that we wanted roughly Array-like access, but 
>> we haven't explicitly dug into which properties of an Array are important.
>> 
>> (If anyone involved feels like they had a different understanding of the use 
>> case, please speak up.)
>> 
>> I think this is a place where the proposal can be improved, and I'm willing 
>> to do some writing to improve it.
>> 
>> For the record, I would be happy to add co-authors (or even relinquish 
>> authorship entirely—I don't really care whose name is on this, it just needs 
>> to happen!) if you or anyone else has improved wording, motivation, 
>> justification, etc. to contribute.
>> ___
>> 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] [swift-dev] Re-pitch: Deriving collections of enum cases

2017-12-30 Thread Jacob Bandes-Storch via swift-evolution 
Sorry for the delay. I've just updated the proposal text to incorporate
various changes, some contributed by others.

https://github.com/jtbandes/swift-evolution/blob/case-enumerable/proposals/-derived-collection-of-enum-cases.md

Robert's implementation
 is
a good start, but will need to be updated to match the naming choice in the
final proposal, and to use associatedtype.

On Fri, Dec 8, 2017 at 9:19 PM, Step Christopher <
schristop...@bignerdranch.com> wrote:

> Has this stalled out again? I would like to help with the proposal and
> even attempt implementation.
>
> I also need to catch up on the resilient discussion regarding enum case
> ordering.
>
> On Nov 14, 2017, at 10:50 PM, Jacob Bandes-Storch via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
>
> Jacob Bandes-Storch
>
> On Tue, Nov 14, 2017 at 9:06 PM, Brent Royal-Gordon <
> br...@architechies.com> wrote:
>
>> On Nov 14, 2017, at 5:21 PM, Xiaodi Wu  wrote:
>>
>> 1. It must be possible to easily access the count of values, and to
>>> access any particular value using contiguous `Int` indices. This could be
>>> achieved either by directly accessing elements in the list of values
>>> through an Int subscript, or by constructing an Array from the list of
>>> values.
>>>
>>> 2. It must be possible to control the order of values in the list of
>>> values, either by using source order or through some other simple,
>>> straightforward mechanism.
>>>
>>
>> OK, first of all, nowhere in the proposal text are these requirements
>> stated as part of the use case. You're free to put forward new use cases,
>> but here I am trying to design the most elegant way to fulfill a stated
>> need and you're telling me that it's something other than what's written.
>>
>>
>> Honestly, re-reading the proposal, it never cites a fully-formed use
>> case. Instead, it cites several blog posts, Stack Overflow questions, and
>> small code samples without digging in to the underlying reasons why
>> developers are doing what they're doing. Most of the people discussing it
>> so far seem to have had a tacit understanding that we wanted roughly
>> Array-like access, but we haven't explicitly dug into which properties of
>> an Array are important.
>>
>> (If anyone involved feels like they had a different understanding of the
>> use case, please speak up.)
>>
>> I think this is a place where the proposal can be improved, and I'm
>> willing to do some writing to improve it.
>>
>
> For the record, I would be happy to add co-authors (or even relinquish
> authorship entirely—I don't really care whose name is on this, it just
> needs to happen!) if you or anyone else has improved wording, motivation,
> justification, etc. to contribute.
>
> ___
> 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