Re: [swift-evolution] [Review] SE-0155: Normalize Enum Case Representation

Thanks again for a detailed review. I have a few comments inline. > On Apr 1, 2017, at 9:50 AM, Xiaodi Wu via swift-evolution > wrote: > > • Does this proposal fit well with the feel and direction of Swift? > > The "Pattern consistency" section does not align

Re: [swift-evolution] [Draft] Dictionary & Set Enhancements

Some thoughts after reviewing it a second time: I am not sure I like having global functions first(_:_:) and last(_:_:). Would it be possible to default the closure to do what last(_:_:) would do? I'm assuming the most popular thing to do is to have the values from the second dictionary

Re: [swift-evolution] [Review] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

> I wish CoreData (or similar object-to-relational-mapping module) in Swift > eventually leverage smart keys and key paths to make our code beautiful when > building sort orderings, qualifiers (predicates or whatever they are called > in CoreData) to build queries or apply them in-memory to

Re: [swift-evolution] [Review] SE-0155: Normalize Enum Case Representation

On Sat, Apr 1, 2017 at 3:38 PM, Daniel Duan wrote: > Thanks again for a detailed review. I have a few comments inline. > > On Apr 1, 2017, at 9:50 AM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > • Does this proposal fit well with the feel and

Re: [swift-evolution] [Review] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

> On 2 Apr 2017, at 02:56, Karl Wagner wrote: > > struct UnaryPredicate { > let evaluate: (Parameter) -> Bool > } > struct BinaryPredicate { > let evaluate: (Left, Right) -> Bool > } > > extension KeyPath where Value: Equatable { > func

Re: [swift-evolution] [Review] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

> On Apr 1, 2017, at 5:56 PM, Karl Wagner via swift-evolution > wrote: > >> let isPuppyQualifier = Pet.type.equals(.dog).and(Pet.age.lessThan(12)) >> let familyQualifier = Family.pets.hasAtLeastOne(satisfying: isPuppyQualifier) >> let familiesWithPuppies =

Re: [swift-evolution] [Draft] Dictionary & Set Enhancements

It looks very useful. I did not quite get the role of the DictionaryLiteral but everything looks very nice. > On Apr 1, 2017, at 3:58 PM, Nate Cook via swift-evolution > wrote: > > Yep, here it is -- didn't realize the length would cause such problems! > >

Re: [swift-evolution] [Pitch] Add an all algorithm to Sequence

> On 02 Apr 2017, at 07:51, Karl Wagner via swift-evolution > wrote: > > Given the relationship to contains, why not keep it simple and go with: > > onlyContains(_ element:) > onlyContains(_ matching:) > > [9, 9, 9, 9, 9].onlyContains(9) // true > [1, 2, 3, 2,

[swift-evolution] [Pitch] Add an all algorithm to Sequence

It figures, the hardest thing to pick is the name of this function… I like forAll the best so far, but I worry that it sounds too much like forEach and would be confusing. What does everyone think of withoutException? nums.withoutException(isEven) and nums.withoutException { isEven($0) } make

Re: [swift-evolution] [Pitch] Add an all algorithm to Sequence

On 01.04.2017 9:17, Richard Wei via swift-evolution wrote: I agree. But I don’t think the predicate needs an argument label. `membersSatisfy(_:)` or `forAll(_:)` sounds better. checkAll(areEqualTo:) ? -Richard On Mar 31, 2017, at 23:02, Will Stanton via swift-evolution

Re: [swift-evolution] [Review #2] SE-0160: Limiting @objc inference

You're right, I had to re-read the proposal a few times to grasp fully the intention there. There was some discussion in the previous thread that this would be needed to infer @objc for implementations of @objc protocol requirements, but I see that this is inferred without any such annotation in

Re: [swift-evolution] [Pitch] Add an all algorithm to Sequence

I agree. But I don’t think the predicate needs an argument label. `membersSatisfy(_:)` or `forAll(_:)` sounds better. -Richard > On Mar 31, 2017, at 23:02, Will Stanton via swift-evolution > wrote: > > +1 to adding, but the name `all` suggests (to me) the return of

Re: [swift-evolution] [Pitch] Add an all algorithm to Sequence

On Sat, Apr 1, 2017 at 3:40 AM, David Hart via swift-evolution < swift-evolution@swift.org> wrote: > > On 1 Apr 2017, at 09:50, Brandon Trussell wrote: > > I agree that based on the method name, I thought a collection would be > returned. > > > Now that I think more about

Re: [swift-evolution] [Pitch] Add an all algorithm to Sequence

> ``` > areAll(equalTo:) > areAll(matching:) > ``` +1, that sounds very Swifty to me! -g. ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Factory Initializers

> On 01 Apr 2017, at 01:35, Riley Testut via swift-evolution > wrote: > > >> On Mar 20, 2017, at 8:07 PM, Greg Parker wrote: >> >> This needs more explanation. It is allowed for a subclass to implement a >> convenience initializer that has the

Re: [swift-evolution] [Pitch] Add an all algorithm to Sequence

> On 1 Apr 2017, at 06:02, Will Stanton via swift-evolution > wrote: > > +1 to adding, but the name `all` suggests (to me) the return of another > sequence, not a Bool. I'm not too concerned because the mandatory labels makes it clear. > Perhaps the function name

Re: [swift-evolution] [Pitch] Add an all algorithm to Sequence

On 01.04.2017 10:50, Brandon Trussell via swift-evolution wrote: I agree that based on the method name, I thought a collection would be returned. From the other side, for example C# has the similar IEnumerable.All() method which "Determines whether all elements of a sequence satisfy a

Re: [swift-evolution] [Proposal] Factory Initializers

First, you should fix the indent in the code samples. Second, remove any access modifier from inside a protocol. Third, we don’t support default implementations directly inside protocols yet, so that’s a not valid example. Now my personal concerns. As far as I can tell XIB files in an iOS

[swift-evolution] Swift String problem with Thai language

Hello Swift Community, I’ve found a problem on Swift String API with Thai language. In Thai, we have 44 Consonants, 32 vowels and 5 tone marks. A special attribute of Thai vowels is that they can be put on anywhere around a consonant, some of them are placed after a consonant (ชา), some are

Re: [swift-evolution] [Pitch] Add an all algorithm to Sequence

> On 01 Apr 2017, at 16:10, David Hart wrote: > >> >> On 1 Apr 2017, at 11:32, Rien wrote: >> >> >>> On 01 Apr 2017, at 10:47, Xiaodi Wu via swift-evolution >>> wrote: >>> >>> On Sat, Apr 1, 2017 at 3:40 AM, David Hart

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0155: Normalize Enum Case Representation

> • What is your evaluation of the proposal? +1. I am very happy with the tradeoffs made in the revision of this proposal. It feels like the right step for Swift 4. It updates enum cases to align with the general direction Swift has taken. This improves consistency now and provides

Re: [swift-evolution] [Review] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

> > What is your evaluation of the proposal? +1. This is a fantastic proposal! I have been looking forward to the ability to access unbound properties ever since Swift was first released. I am very happy to see it coming to the language. The design of this feature is even better than I had

Re: [swift-evolution] [Pitch] Add an all algorithm to Sequence

I agree that based on the method name, I thought a collection would be returned. On Sat, Apr 1, 2017 at 12:36 AM, David Hart via swift-evolution < swift-evolution@swift.org> wrote: > > > > On 1 Apr 2017, at 06:02, Will Stanton via swift-evolution < > swift-evolution@swift.org> wrote: > > > > +1

Re: [swift-evolution] [Pitch] Add an all algorithm to Sequence

> On 1 Apr 2017, at 09:50, Brandon Trussell wrote: > > I agree that based on the method name, I thought a collection would be > returned. Now that I think more about it, I think you're right. It is confusing. Perhaps: allAre(equalTo: ) allAre(matching: ) >> On Sat,

Re: [swift-evolution] [Pitch] Add an all algorithm to Sequence

> On 1 Apr 2017, at 11:32, Rien wrote: > > >> On 01 Apr 2017, at 10:47, Xiaodi Wu via swift-evolution >> wrote: >> >> On Sat, Apr 1, 2017 at 3:40 AM, David Hart via swift-evolution >> wrote: >> >>> On 1 Apr

Re: [swift-evolution] Pitch: @objc attribute for top-level functions

> Le 1 avr. 2017 à 00:53, Joe Groff via swift-evolution > a écrit : > >> >> On Mar 31, 2017, at 8:00 AM, Charles Srstka via swift-evolution >> wrote: >> >> MOTIVATION: >> >> Sometimes, it’s necessary to write a top-level C function in

Re: [swift-evolution] [Draft] Dictionary & Set Enhancements

I really like the merging methods and have already needed to write my own. Zach, do you mind showing a comparison of what you're thinking? Nate, do you mind throwing this up in a gist or something? My email client isn't letting me see the whole thing. Thanks, Jason On Fri, Mar 31, 2017 at

Re: [swift-evolution] [Pitch] Add an all algorithm to Sequence

At this stage, it's rather confuse to me, if return boolean, probably sizeOf and boolOf is easier for me. boolOf(equalTo:) boolOf(matching:) On Sat, Apr 1, 2017 at 10:54 PM, Rien via swift-evolution < swift-evolution@swift.org> wrote: > > > On 01 Apr 2017, at 16:10, David Hart

Re: [swift-evolution] [Review] SE-0155: Normalize Enum Case Representation

On Fri, Mar 31, 2017 at 12:33 PM, John McCall via swift-evolution < swift-evolution@swift.org> wrote: > Hello Swift community, > > The review of "SE-0155: Normalize Enum Case Representation" begins now and > runs through the Monday after next, April 10th. The proposal is available > here: >

Re: [swift-evolution] [Pitch] Add an all algorithm to Sequence

> On Sat, Apr 1, 2017 at 3:40 AM, David Hart via > swift-evolutionwrote: > > > > On 1 Apr 2017, at 09:50, Brandon > > Trussellwrote: > > > > > I agree that based on the method name,

Re: [swift-evolution] [Draft] Dictionary & Set Enhancements

Yep, here it is -- didn't realize the length would cause such problems! https://gist.github.com/natecook1000/4bd8f20736eb99ed3c5a4cdcc41e9a5f Nate > On Apr 1, 2017, at 12:01 PM, Jason Gregori via swift-evolution > wrote: > > I really like the merging

Re: [swift-evolution] [Review] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

> On Mar 30, 2017, at 12:25 PM, Douglas Gregor via swift-evolution > wrote: > > Hello Swift community, > > The review of SE-0161 "Smart KeyPaths: Better Key-Value Coding for Swift" > begins now and runs through April 5, 2017. The proposal is available here: > >

Re: [swift-evolution] [Pitch] Add an all algorithm to Sequence

If indeed “all(equal:)” is rarely needed, then perhaps it is best to leave it out *and also* leave out the argument label from “all(matching:)”. Then the signature would be similar to, func all(_ predicate: (Element)->Bool) -> Bool and the points-of-use would look like: nums.all( isEven )

Re: [swift-evolution] [Pitch] Add an all algorithm to Sequence

I agree that if “contains” has its place in the standard library, so does “all” I also regularly use the extension func forAll(suchThat predicate: (Element) -> Bool) -> Bool which I use like so [0,1,2,3,4].forAll(suchThat: isEven) [0,1,2,3,4].forAll { $0 < 5} > On 1 Apr 2017, at 19:58,

Re: [swift-evolution] [Pitch] Add an all algorithm to Sequence

Hi all, I think that when used without the argument label it is not as clear what it does. For example: nums.all { $0 % 2 == 0 } can be interpreted as give me all the even elements. So if the argument label were to be left out, then I would rename it. Some options: nums.allSatisfy { $0 %

Re: [swift-evolution] [Review] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

-1 (there has always somebody who disagrees ;-) Yes, KeyPaths are nice, solve a problem that's probably significant, and type safety is very important in Swift… but I don't think it's that urgent to have this feature now: Maybe there are some secret plans that depend on smart KeyPaths, but from