Thanks Brent. Was that real code? :-)
If it was, I did not realize it was possible to do something like that in
Swift. That seems very cool, attractive and powerful. It certainly would look
much better with the sugary syntax.
I can imagine building a collection of sort orderings like this fo
> On Apr 3, 2017, at 1:47 PM, Joshua Alvarado via swift-evolution
> wrote:
>
> Example:
> struct Foo {
> var firstName: String
> var lastName: String
> }
>
You would need to spell out #keyPath(Foo, .firstName) here, or decorate the
type on keyPaths like so:
let keyPaths : [KeyPath]
> On Apr 3, 2017, at 1:47 PM, Joshua Alvarado via swift-evolution
> wrote:
>
> Quesition about this proposal. Will it be possibly to create an array of
> keyPaths and set an objects value with enumeration.
>
> Example:
> struct Foo {
> var firstName: String
> var lastName: String
> }
Quesition about this proposal. Will it be possibly to create an array of
keyPaths and set an objects value with enumeration.
Example:
struct Foo {
var firstName: String
var lastName: String
}
let keyPaths = [#keyPath(.firstName), #keyPath(.lastName)]
for key in keyPaths {
foo[keyPath
> On Apr 3, 2017, at 7:24 AM, Ricardo Parada via swift-evolution
> wrote:
>
> By the way, does anybody know why the proposed syntax require a leading
> period for the key path?
>
> #keyPath(Family, .pets.first)
Grammatically, it's a series of postfix expression components, including
propert
On Thu, Mar 30, 2017 at 9:25 AM Douglas Gregor via swift-evolution <
swift-evolution@swift.org> 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:
>
>
> https://g
> On Apr 3, 2017, at 8:27 AM, James Berry wrote:
>
> On balance, I’m +1 on this proposal, with caveats below…
>
> I’ve expressed, I don’t really like the #keyPath(Foo, .bar.baz) syntax,
> because I feel it is confusing to differentiate from the more natural
> #keyPath(Foo.bar.baz) legacy synt
On Thu, Mar 30, 2017, at 12:25 PM, Douglas Gregor wrote:
> * What is your evaluation of the proposal?
Weak +0.5. This is absolutely needed, and I don't want to see the
feature broken down any further through interminable bikeshedding,
so I'd be more willing to let it ride as-is than miss out on
By the way, does anybody know why the proposed syntax require a leading period
for the key path?
#keyPath(Family, .pets.first)
In other words, why not just this:
#keyPath(Family, pets.first)
Or Brent's proposed:
#keyPath(pets.first)
> On Apr 3, 2017, at 2:08 AM, Brent Royal-Gordon via sw
> What is your evaluation of the proposal?
I am very excited about the usefulness of this proposal right now and about its
potential in the future. This is big step towards enabling a lot of “dynamic”
features.
But, like Brent, I continue to think that the syntax is much too heavy: I was a
big
> Proposal link:
> https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md
> • What is your evaluation of the proposal?
I continue to believe that the chosen syntax is unnecessarily cumbersome, that
the design is overly conservative in terms of making sure people
> 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 = Family.fetch(editingContext, familyQua
> 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 equals(_ value: Value) -> UnaryPredicate {
>
> 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 arra
> 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:
>
> https://github.com/apple/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
>
> 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
- What is your evaluation of the proposal?
+1
- 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,
> • What is your evaluation of the proposal?
+1
> • Is the problem being addressed significant enough to warrant a change
> to Swift?
I do not see this as a problem, but as added functionality that would be
beneficial
> • Does this proposal fit well with the feel and direc
> On Mar 30, 2017, at 1:08 PM, Karl Wagner via swift-evolution
> wrote:
>
>> • What is your evaluation of the proposal?
> +1
>
>> • Is the problem being addressed significant enough to warrant a change
>> to Swift?
> Yes
>
>> • Does this proposal fit well with the feel and dir
> What is your evaluation of the proposal?
+1
> 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 fee
> What is your evaluation of the proposal?
+1
> 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 fee
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:
https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md
Reviews are an important part of the Swift
23 matches
Mail list logo
