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

[David Owens via swift-evolution]

I very much agree with the high-level of the proposal. The concept definitely 
needs to exist. However, I feel that the options presented do so in a 
non-intuitive way.

There are two concepts here: closed and open listing of values that make up a 
set of possible options to be used. I think of this much like struct vs. class 
in terms having to determine conceptually which is the right approach for the 
problem you are solving. As such, I feel that this is a significant enough 
difference between the concepts that it warrants a declarative difference via a 
keyword, not just some annotation.

Further, for me personally, putting conditional differences on access level has 
always been a very annoying and frustrating experience in Swift, and this adds 
to that. Using a keyword to distinguish helps with that.

I don’t know the best spelling for, but I’d want something like this:

enumset GregorianWeekday
{ 
case monday // ISO 8601 says weeks start on Monday
case tuesday
case wednesday
case thursday
case friday
case saturday
case sunday
}

That’s the exhaustive list, no others can be added. Access level does not 
matter.

enum Emotions
{
case happy
case sad
case angry
}

This is a non-exhaustive list. Others can be added via extensions. Access level 
does not matter.

-David

> On Dec 19, 2017, at 2:58 PM, Ted Kremenek via swift-evolution 
>  wrote:
> 
> The review of "SE 0192 - Non-Exhaustive Enums" begins now and runs through 
> January 3, 2018.
> 
> The proposal is available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md
>  
> 
> Reviews are an important part of the Swift evolution process. All review 
> feedback 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/0192-non-exhaustive-enums.md
>  
> 
> ...
> Reply text
> ...
> Other replies
> What goes into a review of a proposal?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. 
> 
> When reviewing a proposal, here are some questions to consider:
> 
> 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?
> 
> Thanks,
> Ted Kremenek
> 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] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

[David Owens via swift-evolution]

I like the proposal. I think it’s simple and straight forward and provides some 
really nice ergonomics for working with dynamic data.

I appreciate the option to change the names too.

If I understand it correctly, you could also call “add_trick” via:

dog.addTrick("Roll over");

And simply update the subscript implementation to provide additional name 
look-ups. Cool!

And I like that the DynamicCallable provides the next level that I want to make 
the API more “Swift-like” and make use of named parameters:

dog.add(trick: "Roll over");

Or maybe more appropriate:

dog.addTrick("Roll over”, favorite: true);

I didn’t look at the implementation details, but I think the overall approach. 
I’d like it better if we have provisions to create these types of tools outside 
of the compiler, but that’s another topic.

-David

> On Nov 26, 2017, at 10:04 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> I’d like to formally propose the inclusion of user-defined dynamic member 
> lookup types.
> 
> Here is my latest draft of the proposal:
> https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438
> https://github.com/apple/swift-evolution/pull/768
> 
> An implementation of this design is available here:
> https://github.com/apple/swift/pull/13076
> 
> The implementation is straight-forward and (IMO) non-invasive in the compiler.
> 
> -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