Re: [swift-evolution] Smart KeyPaths

> Is it always in the form of $R? No. Prefixing a variable with a '$' allows you to create a long-lasting variable in lldb. By default, every 'expr' command runs in its own scope, which means identifiers defined in one command are not visible from another. Example: (LLDB) expr let x = 1 + 2

Re: [swift-evolution] Smart KeyPaths

> Date: Fri, 31 Mar 2017 04:33:43 -0700 > From: Brent Royal-Gordon <br...@architechies.com> > To: Haravikk <swift-evolut...@haravikk.me> > Cc: Haravikk via swift-evolution <swift-evolution@swift.org> > Subject: Re: [swift-evolution] Smart KeyPaths > Message-ID

Re: [swift-evolution] Smart KeyPaths

> On 31 Mar 2017, at 12:33, Brent Royal-Gordon wrote: > >> On Mar 31, 2017, at 3:07 AM, Haravikk via swift-evolution >> > wrote: >> >> Is it actually in-use or just reserved? Not sure I've ever needed it in

Re: [swift-evolution] Smart KeyPaths

> On Mar 31, 2017, at 3:07 AM, Haravikk via swift-evolution > wrote: > > Is it actually in-use or just reserved? Not sure I've ever needed it in the > debugger. Pop into the REPL for a minute: $ swift Welcome to Apple Swift version 3.1

Re: [swift-evolution] Smart KeyPaths

> On 30 Mar 2017, at 17:18, Joe Groff wrote: > > >> On Mar 30, 2017, at 6:54 AM, Haravikk via swift-evolution >> wrote: >> >> >>> On 30 Mar 2017, at 14:12, Matthew Johnson via swift-evolution >>> wrote: On 30

Re: [swift-evolution] Smart KeyPaths

> On Mar 30, 2017, at 6:54 AM, Haravikk via swift-evolution > wrote: > > >> On 30 Mar 2017, at 14:12, Matthew Johnson via swift-evolution >> wrote: >>> On 30 Mar 2017, at 01:13, Michael J LeHew Jr via swift-evolution >>>

Re: [swift-evolution] Smart KeyPaths

> On Mar 30, 2017, at 9:54 AM, Haravikk via swift-evolution > wrote: > > Personally I'd prefer the use of a leading dollar sign for this, for example: > > $Person.friend.lastName That looks clean. I don't think it could get confused with referencing named

Re: [swift-evolution] Smart KeyPaths

On 30.03.2017 16:12, Matthew Johnson via swift-evolution wrote: Sent from my iPad On Mar 30, 2017, at 12:35 AM, David Hart via swift-evolution > wrote: Sent from my iPhone On 30 Mar 2017, at 01:13, Michael J LeHew Jr via

Re: [swift-evolution] Smart KeyPaths

> On 30 Mar 2017, at 14:12, Matthew Johnson via swift-evolution > wrote: >> On 30 Mar 2017, at 01:13, Michael J LeHew Jr via swift-evolution >> > wrote: >> I'm not a fan of the new syntax for creating key

Re: [swift-evolution] Smart KeyPaths

Sent from my iPad > On Mar 30, 2017, at 12:35 AM, David Hart via swift-evolution > wrote: > > > > > > Sent from my iPhone > On 30 Mar 2017, at 01:13, Michael J LeHew Jr via swift-evolution > wrote: > >> Thanks for the feedback

Re: [swift-evolution] Smart KeyPaths

> On Mar 29, 2017, at 10:21 PM, James Berry via swift-evolution > wrote: > > Or migrate swift 3 #keyPath to #objcKeyPath to preserve that legacy intent > while retaining #keyPath for our bright and unsullied future? ;) I like this suggestion.

Re: [swift-evolution] Smart KeyPaths

> On 30 Mar 2017, at 09:41, Douglas Gregor wrote: > > > > Sent from my iPhone > >> On Mar 29, 2017, at 10:35 PM, David Hart wrote: >> >> >> >> >> >> Sent from my iPhone >> On 30 Mar 2017, at 01:13, Michael J LeHew Jr via swift-evolution >>

Re: [swift-evolution] Smart KeyPaths

Sent from my iPhone > On 30 Mar 2017, at 01:13, Michael J LeHew Jr via swift-evolution > wrote: > > Thanks for the feedback everyone! We have pushed a changed a bit ago to the > proposal reflecting these desires. > >

Re: [swift-evolution] Smart KeyPaths

Sent from my iPhone > On Mar 29, 2017, at 6:32 PM, Brent Royal-Gordon via swift-evolution > wrote: > >>> On Mar 29, 2017, at 6:21 PM, Jonathan Hull via swift-evolution >>> wrote: >>> >>> I would love it if we found a way to retain

Re: [swift-evolution] Smart KeyPaths

> On Mar 29, 2017, at 7:08 PM, Joe Groff wrote: > > >> On Mar 29, 2017, at 7:00 PM, James Berry wrote: >> >>> >>> On Mar 29, 2017, at 5:37 PM, Joe Groff wrote: >>> >>> On Mar 29, 2017, at 5:26 PM, Michael J LeHew Jr via

Re: [swift-evolution] Smart KeyPaths

> On Mar 29, 2017, at 7:05 PM, Joe Groff wrote: > > KeyPath objects themselves have properties, so key1 could be a member of > KeyPath. This doesn't seem workable. Yeah, someone pointed that out to me privately. One solution would be to make it so that an uninterrupted

Re: [swift-evolution] Smart KeyPaths

> On Mar 29, 2017, at 7:00 PM, James Berry wrote: > >> >> On Mar 29, 2017, at 5:37 PM, Joe Groff wrote: >> >> >>> On Mar 29, 2017, at 5:26 PM, Michael J LeHew Jr via swift-evolution >>> wrote: >>> >>> On Mar 29,

Re: [swift-evolution] Smart KeyPaths

> On Mar 29, 2017, at 6:32 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> On Mar 29, 2017, at 6:21 PM, Jonathan Hull via swift-evolution >> wrote: >> >>> I would love it if we found a way to retain something as concise as that

Re: [swift-evolution] Smart KeyPaths

> On Mar 29, 2017, at 6:45 PM, Jonathan Hull via swift-evolution > wrote: > >> >> On Mar 29, 2017, at 6:32 PM, Brent Royal-Gordon >> wrote: >> >>> On Mar 29, 2017, at 6:21 PM, Jonathan Hull via swift-evolution >>>

Re: [swift-evolution] Smart KeyPaths

> On Mar 29, 2017, at 5:37 PM, Joe Groff wrote: > > >> On Mar 29, 2017, at 5:26 PM, Michael J LeHew Jr via swift-evolution >> wrote: >> >> >>> On Mar 29, 2017, at 5:12 PM, James Berry wrote: >>> Referencing Key

Re: [swift-evolution] Smart KeyPaths

> On Mar 29, 2017, at 8:45 PM, Douglas Gregor via swift-evolution > wrote: > > > > Sent from my iPhone > > On Mar 29, 2017, at 4:52 PM, Brent Royal-Gordon > wrote: > >>> On Mar 29, 2017, at 4:13 PM,

Re: [swift-evolution] Smart KeyPaths

> On Mar 29, 2017, at 9:32 PM, Brent Royal-Gordon via swift-evolution > wrote: >> On Mar 29, 2017, at 6:21 PM, Jonathan Hull via swift-evolution >> > wrote: >> >>> I would love it if we found a way to

Re: [swift-evolution] Smart KeyPaths

> On Mar 29, 2017, at 6:32 PM, Brent Royal-Gordon > wrote: > >> On Mar 29, 2017, at 6:21 PM, Jonathan Hull via swift-evolution >> > wrote: >> >>> I would love it if we found a way to retain something as

Re: [swift-evolution] Smart KeyPaths

Sent from my iPhone > On Mar 29, 2017, at 4:52 PM, Brent Royal-Gordon > wrote: > >> On Mar 29, 2017, at 4:13 PM, Michael J LeHew Jr via swift-evolution >> wrote: >> >> Thanks for the feedback everyone! We have pushed a changed a bit ago

Re: [swift-evolution] Smart KeyPaths

> On Mar 29, 2017, at 6:21 PM, Jonathan Hull via swift-evolution > wrote: > >> I would love it if we found a way to retain something as concise as that >> shorthand. I'm working on a library where users will specify a collection >> of key paths pairs. This

Re: [swift-evolution] Smart KeyPaths

> On Mar 29, 2017, at 6:08 PM, Matthew Johnson via swift-evolution > wrote: > > The one big loss I see from the original proposal is that the current design > does not allow us to create a type context that provides something as concise > as the original dot

Re: [swift-evolution] Smart KeyPaths

Sent from my iPad > On Mar 29, 2017, at 7:32 PM, Joe Groff via swift-evolution > wrote: > > >> On Mar 29, 2017, at 5:29 PM, Michael J LeHew Jr wrote: >> >> On Mar 29, 2017, at 4:52 PM, Brent Royal-Gordon

Re: [swift-evolution] Smart KeyPaths

> On Mar 29, 2017, at 5:26 PM, Michael J LeHew Jr via swift-evolution > wrote: > > >> On Mar 29, 2017, at 5:12 PM, James Berry wrote: >> >>> Referencing Key Paths >>> >>> Forming a KeyPath borrows from the same syntax added in Swift 3 to

Re: [swift-evolution] Smart KeyPaths

> On Mar 29, 2017, at 5:29 PM, Michael J LeHew Jr wrote: > > >> On Mar 29, 2017, at 4:52 PM, Brent Royal-Gordon >> wrote: >> >>> On Mar 29, 2017, at 4:13 PM, Michael J LeHew Jr via swift-evolution >>> wrote: >>> >>>

Re: [swift-evolution] Smart KeyPaths

> On Mar 29, 2017, at 4:52 PM, Brent Royal-Gordon > wrote: > >> On Mar 29, 2017, at 4:13 PM, Michael J LeHew Jr via swift-evolution >> > wrote: >> >> Thanks for the feedback everyone! We have pushed a

Re: [swift-evolution] Smart KeyPaths

> On Mar 29, 2017, at 5:12 PM, James Berry wrote: > >> Referencing Key Paths >> >> Forming a KeyPath borrows from the same syntax added in Swift 3 to confirm >> the existence of a given key path, only now producing concrete values >> instead of Strings. Optionals are

Re: [swift-evolution] Smart KeyPaths

> On Mar 29, 2017, at 7:12 PM, James Berry via swift-evolution > wrote: > >> Referencing Key Paths >> >> Forming a KeyPath borrows from the same syntax added in Swift 3 to confirm >> the existence of a given key path, only now producing concrete values >> instead

Re: [swift-evolution] Smart KeyPaths

> Referencing Key Paths > > Forming a KeyPath borrows from the same syntax added in Swift 3 to confirm > the existence of a given key path, only now producing concrete values instead > of Strings. Optionals are handled via optional-chaining. Multiply dotted > expressions are allowed as well,

Re: [swift-evolution] Smart KeyPaths

> On Mar 29, 2017, at 4:13 PM, Michael J LeHew Jr via swift-evolution > wrote: > > Thanks for the feedback everyone! We have pushed a changed a bit ago to the > proposal reflecting these desires. > > https://github.com/apple/swift-evolution/pull/644/files >

Re: [swift-evolution] Smart KeyPaths

Thanks for the feedback everyone! We have pushed a changed a bit ago to the proposal reflecting these desires. https://github.com/apple/swift-evolution/pull/644/files -Michael > On Mar 29, 2017, at 2:49 PM, Douglas Gregor wrote: > > >> On Mar 17, 2017, at 10:04 AM,

Re: [swift-evolution] Smart KeyPaths

> On Mar 17, 2017, at 10:04 AM, Michael LeHew via swift-evolution > wrote: > > Hi friendly swift-evolution folks, > > The Foundation and Swift team would like for you to consider the following > proposal: The Swift core team discussed this proposal draft and had

Re: [swift-evolution] Smart KeyPaths

I had the same thoughts, the syntax should differ in some way from that of a static property. I find : very suitable as a symbol. What I do not like -> or $, because it reminds me too much of PHP. The @ signs are somehow also unsuitable. > > Le 19 mars 2017 à 16:41, Ricardo Parada via > >

Re: [swift-evolution] Smart KeyPaths

> I guess I just don't understand why people seem so eager to change this > syntax. The biggest complaint seems to be that it's too lightweight and > natural; they're worried they might not realize they're using this big, scary > new feature. But this feature simply *isn't* big and scary! It's

Re: [swift-evolution] Smart KeyPaths

By the way, I am okay with the syntax in the proposal too. I'm just brainstorming so that we can look at all the options. I am guessing the authors (David Smith, Michael LeHew and Joe Groff) probably went through this process already and settled with the simpler notation. :-) > On Mar 22,

Re: [swift-evolution] Smart KeyPaths

Yes, I was about to ask the same. It seems like all the sigil characters are taken. This is one of the reasons why I did not object to the non-sigil notation originally proposed despite the ambiguity with static properties and instance properties with the same name. But using a sigil seems

Re: [swift-evolution] Smart KeyPaths

> On Mar 22, 2017, at 3:30 PM, Brent Royal-Gordon > wrote: > >> On Mar 22, 2017, at 11:27 AM, Matthew Johnson via swift-evolution >> > wrote: >> >> One option would be to include `get` and `set` methods on

Re: [swift-evolution] Smart KeyPaths

> On Mar 22, 2017, at 11:27 AM, Matthew Johnson via swift-evolution > wrote: > > One option would be to include `get` and `set` methods on the key path types. > That would allow us to write the subscripts in the standard library (if it > is allowed to extend Any)

Re: [swift-evolution] Smart KeyPaths

> One option would be to include `get` and `set` methods on the key path types. > That would allow us to write the subscripts in the standard library (if it > is allowed to extend Any) and keep all of the magic in the key path types > themselves. I think I would like that approach. +1 l8r

Re: [swift-evolution] Smart KeyPaths

> On Mar 22, 2017, at 9:00 AM, Vladimir.S via swift-evolution > wrote: > > bag[#path] What do these do? bag[#file] bag[#line] bag[#function] // etc. -- Brent Royal-Gordon Architechies ___

Re: [swift-evolution] Smart KeyPaths

> On Mar 22, 2017, at 12:34 PM, Vladimir.S wrote: > > On 22.03.2017 19:25, Matthew Johnson wrote: >> >>> On Mar 22, 2017, at 11:00 AM, Vladimir.S >> > wrote: >>> >>> On 22.03.2017 18:47, Matthew Johnson wrote: > On Mar

Re: [swift-evolution] Smart KeyPaths

On 22.03.2017 19:25, Matthew Johnson wrote: On Mar 22, 2017, at 11:00 AM, Vladimir.S > wrote: On 22.03.2017 18:47, Matthew Johnson wrote: On Mar 22, 2017, at 10:36 AM, Vladimir.S via swift-evolution

Re: [swift-evolution] Smart KeyPaths

> On Mar 22, 2017, at 11:41 AM, Ricardo Parada wrote: > > Agree. > > Another question. If `Bag` does have a static thing called `myStaticThingy` > would you refer to it as: > > Bag.Type#myStaticThingy I would expect that to work eventually but I’m not sure if it would be

Re: [swift-evolution] Smart KeyPaths

Agree. Another question. If `Bag` does have a static thing called `myStaticThingy` would you refer to it as: Bag.Type#myStaticThingy ? > On Mar 22, 2017, at 12:37 PM, Matthew Johnson wrote: > >> >> On Mar 22, 2017, at 11:16 AM, Ricardo Parada >

Re: [swift-evolution] Smart KeyPaths

> On Mar 22, 2017, at 11:16 AM, Ricardo Parada wrote: > > I see three possibilities: > > 1) # + «space» +«path» like this: > > let path = # Bag.things[0].name > bag[path] > bag[# Bag.things[0].name] > bag[# .things[0].name] // Root is inferred as Bag > bag.things[0][#

Re: [swift-evolution] Smart KeyPaths

> On Mar 22, 2017, at 11:00 AM, Vladimir.S wrote: > > On 22.03.2017 18:47, Matthew Johnson wrote: >> >>> On Mar 22, 2017, at 10:36 AM, Vladimir.S via swift-evolution >>> > wrote: >>> >>> On 22.03.2017 17:37,

Re: [swift-evolution] Smart KeyPaths

I see three possibilities: 1) # + «space» +«path» like this: let path = # Bag.things[0].name bag[path] bag[# Bag.things[0].name] bag[# .things[0].name] // Root is inferred as Bag bag.things[0][# Thing.name] bag.things[0][# .name] // Root is inferred as Thing 2) # + «path» like this:: let

Re: [swift-evolution] Smart KeyPaths

On 22.03.2017 18:47, Matthew Johnson wrote: On Mar 22, 2017, at 10:36 AM, Vladimir.S via swift-evolution > wrote: On 22.03.2017 17:37, Ricardo Parada wrote: On Mar 22, 2017, at 9:30 AM, Vladimir.S

Re: [swift-evolution] Smart KeyPaths

> On Mar 22, 2017, at 10:36 AM, Vladimir.S via swift-evolution > wrote: > > On 22.03.2017 17:37, Ricardo Parada wrote: >> >> >>> On Mar 22, 2017, at 9:30 AM, Vladimir.S wrote: >>> >>> let path = @Bag.things[0].name >>> >>> bag@path >>>

Re: [swift-evolution] Smart KeyPaths

On 22.03.2017 17:37, Ricardo Parada wrote: On Mar 22, 2017, at 9:30 AM, Vladimir.S wrote: let path = @Bag.things[0].name bag@path bag@.things[0].name bag@Bag.things[0].name bag.things[0]@.name bag.things[0]@Thing.name It sounds like the @ character is serving two

Re: [swift-evolution] Smart KeyPaths

> On Mar 22, 2017, at 9:30 AM, Vladimir.S wrote: > > let path = @Bag.things[0].name > > bag@path > bag@.things[0].name > bag@Bag.things[0].name > bag.things[0]@.name > bag.things[0]@Thing.name It sounds like the @ character is serving two different purposes which confused

Re: [swift-evolution] Smart KeyPaths

On 22.03.2017 6:01, Ricardo Parada via swift-evolution wrote: Sometimes I feel like we need a winning sigil for this, one that would look good, it is not already taken and easy to type in all keyboards. Maybe we'll have to start looking at emojis :-) IMO syntax for method references should

Re: [swift-evolution] Smart KeyPaths

Sometimes I feel like we need a winning sigil for this, one that would look good, it is not already taken and easy to type in all keyboards. Maybe we'll have to start looking at emojis :-) > On Mar 21, 2017, at 9:13 PM, Matthew Johnson via swift-evolution >

Re: [swift-evolution] Smart KeyPaths

Sent from my iPad > On Mar 21, 2017, at 8:00 PM, Ben Rimmington wrote: > > Re: > >> On 21 Mar 2017, at 13:16, Matthew Johnson wrote: >> >> I think the language is best served if all unbound members are accessible

Re: [swift-evolution] Smart KeyPaths

Re: > On 21 Mar 2017, at 13:16, Matthew Johnson wrote: > > I think the language is best served if all unbound members are accessible > using the same syntax. IMO this proposal does the right thing by choosing > consistency with existing

Re: [swift-evolution] Smart KeyPaths

> On 21 Mar 2017, at 20:04, David Smith via swift-evolution > wrote: > > >> On Mar 20, 2017, at 4:12 AM, David Hart via swift-evolution >> wrote: >> >> >> >>> On 20 Mar 2017, at 10:39, Jonathan Hull via swift-evolution >>>

Re: [swift-evolution] Smart KeyPaths

> On Mar 20, 2017, at 4:12 AM, David Hart via swift-evolution > wrote: > > > >> On 20 Mar 2017, at 10:39, Jonathan Hull via swift-evolution >> wrote: >> >> +1. This is my favorite solution so far. >> >> With ‘Person.keypath.name' it

Re: [swift-evolution] Smart KeyPaths

Ah, yes, that would be annoying if editing .xib files caused SourceKitService dialogs to pop up every five seconds, the way editing .swift files does. Charles > On Mar 20, 2017, at 9:39 PM, Kenny Leung via swift-evolution > wrote: > > Wouldn’t this require the

Re: [swift-evolution] Smart KeyPaths

Wouldn’t this require the Swift compiler and the original binary to work properly? -Kenny > On Mar 20, 2017, at 6:52 PM, Ricardo Parada wrote: > > That is very interesting: "formatting templates that are well typed." > > Would that be like a template and keypaths that were

Re: [swift-evolution] Smart KeyPaths

That is very interesting: "formatting templates that are well typed." Would that be like a template and keypaths that were archived to a file, similar to a .nib file? > On Mar 20, 2017, at 7:28 PM, Joe Groff via swift-evolution > wrote: > > >> On Mar 20, 2017, at

Re: [swift-evolution] Smart KeyPaths

> On Mar 20, 2017, at 4:01 PM, Kenny Leung via swift-evolution > wrote: > > Hi All. > > I’m not sure I’m understanding this proposal properly. In (old) Cocoa, two > places where key paths were used extensively was EOF/CoreData, and > WebObjects. I’m wondering how

Re: [swift-evolution] Smart KeyPaths

Hi All. I’m not sure I’m understanding this proposal properly. In (old) Cocoa, two places where key paths were used extensively was EOF/CoreData, and WebObjects. I’m wondering how Smart KeyPaths will solve these two problems: 1. fetching data from a database and stuff it into objects that are

Re: [swift-evolution] Smart KeyPaths

> On Mar 20, 2017, at 9:23 AM, Christopher Kornher via swift-evolution > wrote: > >> On Mar 20, 2017, at 5:12 AM, David Hart via swift-evolution >> > wrote: >> >> >> >>> On 20 Mar 2017, at 10:39,

Re: [swift-evolution] Smart KeyPaths

> On Mar 20, 2017, at 9:23 AM, Christopher Kornher via swift-evolution > wrote: > > > >> On Mar 20, 2017, at 5:12 AM, David Hart via swift-evolution >> wrote: >> >> >> >>> On 20 Mar 2017, at 10:39, Jonathan Hull via swift-evolution

Re: [swift-evolution] Smart KeyPaths

> On Mar 20, 2017, at 5:12 AM, David Hart via swift-evolution > wrote: > > > >> On 20 Mar 2017, at 10:39, Jonathan Hull via swift-evolution >> wrote: >> >> +1. This is my favorite solution so far. >> >> With ‘Person.keypath.name'

Re: [swift-evolution] Smart KeyPaths

I like it the way they have it in the proposal because it is consistent with referencing methods and initializers. And as mentioned previously it can be disambiguated on the edge cases. > On Mar 20, 2017, at 9:11 AM, Matthew Johnson via swift-evolution > wrote:

Re: [swift-evolution] Smart KeyPaths

Sent from my iPad On Mar 20, 2017, at 6:18 AM, Rien via swift-evolution wrote: >> >> On 20 Mar 2017, at 12:12, David Hart via swift-evolution >> wrote: >> >> >> >>> On 20 Mar 2017, at 10:39, Jonathan Hull via swift-evolution >>>

Re: [swift-evolution] Smart KeyPaths

Sent from my iPad > On Mar 19, 2017, at 11:02 PM, jaden.gel...@gmail.com wrote: > > You mean overloaded, not shadowed, right? No. What I mean by shadowed is this: struct Foo { // you write this: let bar: Int // compiler automatically synthesizes a static keypath: static let

Re: [swift-evolution] Smart KeyPaths

> > On 20 Mar 2017, at 12:12, David Hart via swift-evolution > wrote: > > > >> On 20 Mar 2017, at 10:39, Jonathan Hull via swift-evolution >> wrote: >> >> +1. This is my favorite solution so far. >> >> With ‘Person.keypath.name' it

Re: [swift-evolution] Smart KeyPaths

> On 20 Mar 2017, at 10:39, Jonathan Hull via swift-evolution > wrote: > > +1. This is my favorite solution so far. > > With ‘Person.keypath.name' it is obvious that we are creating a key path. > There is no ambiguity for the reader. With autocomplete it will

Re: [swift-evolution] Smart KeyPaths

+1. This is my favorite solution so far. With ‘Person.keypath.name' it is obvious that we are creating a key path. There is no ambiguity for the reader. With autocomplete it will be very little extra typing anyway… Thanks, Jon > On Mar 19, 2017, at 9:20 PM, Dietmar Planitzer via

Re: [swift-evolution] Smart KeyPaths

Key paths of this form: Person.name will always make it harder than necessary to: * search for all places where we are using key paths * do efficient code completion. Eg you’ll get a mix of static properties and key paths We’ve been using this kind of setup in our projects for some time

Re: [swift-evolution] Smart KeyPaths

You mean overloaded, not shadowed, right? > On Mar 19, 2017, at 8:49 PM, Matthew Johnson wrote: > > > > Sent from my iPad > >> On Mar 19, 2017, at 10:31 PM, Jaden Geller via swift-evolution >> wrote: >> >> I think the clarity desired is

Re: [swift-evolution] Smart KeyPaths

Sent from my iPad > On Mar 19, 2017, at 10:31 PM, Jaden Geller via swift-evolution > wrote: > > I think the clarity desired is more similar to that obtained by the `try` > keyword. Ya, the compiler knows that this function throws already, but Swift > aims for

Re: [swift-evolution] Smart KeyPaths

I think the clarity desired is more similar to that obtained by the `try` keyword. Ya, the compiler knows that this function throws already, but Swift aims for clarity in the source code. Clarity is often achieved by providing potentially redundant information for the programmer. As proposed,

Re: [swift-evolution] Smart KeyPaths

> On Mar 19, 2017, at 4:47 PM, Charles Srstka wrote: > >> This is true of many things. It is why IDEs make type information readily >> available. > > Is clarity not a thing to be desired? Clarity is in the eye of the beholder. Here's one notion of clarity:

Re: [swift-evolution] Smart KeyPaths

> On Mar 19, 2017, at 4:15 PM, Matthew Johnson wrote: > > On Mar 19, 2017, at 4:02 PM, Charles Srstka via swift-evolution > > wrote: > >>> On Mar 19, 2017, at 3:45 PM, Brent Royal-Gordon

Re: [swift-evolution] Smart KeyPaths

Thanks to both of you for pointing how to disambiguate and how generic types can be inferred. I now think that this is the way to go. It looks to me like it is the simplest and the most elegant solution. > On Mar 17, 2017, at 6:05 PM, Joe Groff via swift-evolution >

Re: [swift-evolution] Smart KeyPaths

Sent from my iPhone > On Mar 19, 2017, at 4:02 PM, Charles Srstka via swift-evolution > wrote: > >>> On Mar 19, 2017, at 3:45 PM, Brent Royal-Gordon >>> wrote: >>> On Mar 19, 2017, at 12:57 PM, Charles Srstka via swift-evolution

Re: [swift-evolution] Smart KeyPaths

Sent from my iPhone > On Mar 19, 2017, at 4:53 PM, Matthew Johnson via swift-evolution > wrote: > > > > Sent from my iPhone > >> On Mar 19, 2017, at 3:45 PM, Brent Royal-Gordon via swift-evolution >> wrote: >> On Mar 19, 2017,

Re: [swift-evolution] Smart KeyPaths

> On Mar 19, 2017, at 3:45 PM, Brent Royal-Gordon > wrote: > >> On Mar 19, 2017, at 12:57 PM, Charles Srstka via swift-evolution >> > wrote: >> >>> I disagree. How the reader is supposed to now there is a

Re: [swift-evolution] Smart KeyPaths

I was thinking that maybe it could be an error or warning to have a static property with the same name as a normal property. But I'm simply thinking out loud a possible solution to this ambiguity problem without introducing a symbol for key paths. Just trying to see if we can keep it simple.

Re: [swift-evolution] Smart KeyPaths

Sent from my iPhone > On Mar 19, 2017, at 3:45 PM, Brent Royal-Gordon via swift-evolution > wrote: > >>> On Mar 19, 2017, at 12:57 PM, Charles Srstka via swift-evolution >>> wrote: >>> >>> I disagree. How the reader is supposed to now

Re: [swift-evolution] Smart KeyPaths

> On Mar 19, 2017, at 12:57 PM, Charles Srstka via swift-evolution > wrote: > >> I disagree. How the reader is supposed to now there is a static property or >> not ? Having readable code is more important than having easy to write code. > > I’ve got to agree with

Re: [swift-evolution] Smart KeyPaths

> On Mar 19, 2017, at 2:51 PM, Jean-Daniel via swift-evolution > wrote: > >> Le 19 mars 2017 à 16:41, Ricardo Parada via swift-evolution >> > a écrit : >> >> I agree that they can get mixed up with static

Re: [swift-evolution] Smart KeyPaths

> Le 19 mars 2017 à 16:41, Ricardo Parada via swift-evolution > a écrit : > > I agree that they can get mixed up with static properties. However, I think I > would not mind because it would only cause an ambiguity when having a static > property with the same name

Re: [swift-evolution] Smart KeyPaths

I might point out that this form of bikeshedding was already explicitly called out in the text of the proposal. ("Alternatives Considered") Your personal preferences as to what sigils are "lightweight" or "easy" are not absolute ones without some form of evidence or objective rationale provided.

Re: [swift-evolution] Smart KeyPaths

I agree that they can get mixed up with static properties. However, I think I would not mind because it would only cause an ambiguity when having a static property with the same name as the property which would be an odd practice I think. I was defining static properties with the same name

Re: [swift-evolution] Smart KeyPaths

It looks awesome. I don’t understand the details yet but I always felt it would be super cool if swift allowed you to express key paths elegantly which seems what this is. I would love to be able to create what used to be called EOQualifier in WebObjects/Enterprise Objects Framework (i.e.

Re: [swift-evolution] Smart KeyPaths

Would it be possible to create operators? let total = manager[@sum.reports.salary] > On Mar 18, 2017, at 22:00 , Muse M via swift-evolution > wrote: > > I would suggest a keypath using ~ which is concise and clearer to identify. > > let myPath =

Re: [swift-evolution] Smart KeyPaths

I would suggest a keypath using ~ which is concise and clearer to identify. let myPath = Person~friends[0].name On Sunday, March 19, 2017, Jonathan Hull via swift-evolution < swift-evolution@swift.org> wrote: > This looks fantastic! > > The one worry I would have, as others have brought up,

Re: [swift-evolution] Smart KeyPaths

This looks fantastic! The one worry I would have, as others have brought up, is confusion when there are static properties with the same name. Maybe we could have a special static property called ‘keyPath’ or ‘path’ that would be reserved, and anything that followed would be a key path. So

Re: [swift-evolution] Smart KeyPaths

I love the proposal and it is great to see this feature being considered. This provides a great foundation for future functionality. I too find the syntax confusing. The syntax is elegant and does not introduce any extra keywords, but accessing key paths is an advanced “meta” feature and does

Re: [swift-evolution] Smart KeyPaths

It's so nice that this is finally seeing the light of day :) Great work everyone! Re: subscripts, it's definitely a great solution for "the Swift we have now", but I'm not sure in "the Swift we'll have in a few years." If, for instance, someday we're able to return inouts (or really just lvalues

Re: [swift-evolution] Smart KeyPaths

> On Mar 17, 2017, at 6:38 PM, Joe Groff via swift-evolution > wrote: > > >> On Mar 17, 2017, at 12:34 PM, David Hart via swift-evolution >> > wrote: >> >> Sent off-list by mistake: >> >> Nice proposal.

Re: [swift-evolution] Smart KeyPaths

> Smart KeyPaths: Better Key-Value Coding for Swift > Proposal: SE- > Authors: David Smith , Michael LeHew > , Joe Groff > Review Manager: TBD > Status: Awaiting Review > Associated PRs: > #644

  1   2   >