Re: [swift-evolution] [Accepted] SE-0168: Multi-Line String Literals

From Joe's email: "[...] Discussion on the list raised the idea of allowing a line to end with \ to "escape" the newline and elide it from the value of the literal; the core team had concerns about only allowing that inside multi-line literals and felt that that could also be considered later a

Re: [swift-evolution] [Accepted] SE-0168: Multi-Line String Literals

If I understood Joe correctly he said it gets stripped: "a single newline is always stripped after the opening delimiter and before the closing one, and the closing delimiter's position always determines the indentation level of the entire literal." So I think it would be "foo\nbar". > On Apr

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

> On Apr 15, 2017, at 3:28 PM, Thorsten Seitz wrote: > >> Here is another example: >> >> case .isExprSameType(let from, let to): >> return """checking a value with optional type \(from) \ >>against dynamic type \(to) \ >>succeeds

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

Reply inline. On Apr 15, 2017, at 8:48 AM, Thorsten Seitz via swift-evolution mailto:swift-evolution@swift.org>> wrote: > >> Am 15.04.2017 um 09:24 schrieb Adrian Zubarev via swift-evolution >> mailto:swift-evolution@swift.org>>: >> >> I disagree, the examples you have provided are more comp

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

> On Multiline String collection > > 6) If we are importing many sources from 3rd parties API, we won't know if > their code is properly indent, some use tab and some use 2 or 4-space. This > would look better on Swift Playground app. > > var stories = { > "&quo

Re: [swift-evolution] [swift-evolution-announce] SE-0171: Reduce with inout

> On Apr 14, 2017, at 2:37 PM, Ben Cohen wrote: > > Hello Swift community, > > The review of “SE-0171: Reduce with inout" begins now and runs through the > Friday after next, April 14th. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0171-reduce

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

I agree that it is not obvious. At one point I argued that the trailing newline on the last line should be stripped. But for this reason and others I am now in the camp that thinks we should leave the trailing newline alone. If we don't want to include the trailing newline we can always do th

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

What do you love about that? > On Apr 14, 2017, at 8:40 AM, Muse M via swift-evolution > wrote: > > 3) > var code = { > """ > Hello World > """ > } ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

That would be good, I think because it would force everyone to be precise in regards to trailing whitespace. And I don't see that as a bad thing. > On Apr 13, 2017, at 9:54 AM, Adrian Zubarev via swift-evolution > wrote: > > I was really confused by your last reply. Actually I’ve got a bette

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

I don't care much for trailing whitespace but I thought we should respect the trailing whitespace in the event that it is significant. If I'm worried about precision in a string, I turn on the display of whitespace characters and make sure everything is as expected. I also think it would su

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

Hi Adrian, My conclusion that we should leave it alone is based on the assumption that someone may consider the trailing whitespace significant and correct. > On Apr 13, 2017, at 9:05 AM, Adrian Zubarev > wrote: > > That would be so wrong, because it’s not obvious to anyone how long your >

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

I think it's solid and thorough. I think it's winner. > On Apr 13, 2017, at 8:41 AM, Brent Royal-Gordon > wrote: > >> On Apr 13, 2017, at 5:35 AM, Ricardo Parada via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> Take a l

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

Oops, my apologies for misspelling your name. It was a typo. > On Apr 13, 2017, at 8:35 AM, Ricardo Parada via swift-evolution > wrote: > > Adriam > > Take a look at Brent's revised proposal.I personally thin it is perfect. > Take a look: > > https://github

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

Adriam Take a look at Brent's revised proposal.I personally thin it is perfect. Take a look: https://github.com/johnno1962a/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md Regarding what you are proposing: Trailing newline We need consensus on whether the trailing

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

On Apr 12, 2017, at 6:20 PM, Brent Royal-Gordon via swift-evolution mailto:swift-evolution@swift.org>> wrote: > Wow, maybe I shouldn't have slept. LOL. My thoughts so far: • If and only if the opening """ is followed by a newline then strip it. • Don't strip the trailing newline. Example:

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

Yes, you are right. I tested using the IBM Swift Sandbox . In Xcode the output is as expected with the empty line in between the two lines. > On Apr 12, 2017, at 2:33 PM, Adrian Zubarev > wrote: > > You’re wrong there, Xcode does print this for me:

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

gt; foo > bar\ > """ > > // v2: > """ > \n\ > foo > bar\ > """ > > // v3: > """ > \nfoo > bar\ > """ > > > > -- > Adrian Zubarev > Sent with Airmail >

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

Hi all, I agree as well, I think we should make optimize for the most common case of multi-line strings. A rule that says strip the first leading newline as well as the trailing newline. So it's almost back to where Brent started with the addition of removing the trailing newline. Borrowing

Re: [swift-evolution] Enhancing access levels without breaking changes

> On Apr 12, 2017, at 1:42 AM, Chris Lattner via swift-evolution > wrote: > > On Apr 11, 2017, at 10:30 PM, David Hart wrote: >>> To me, the reason for limiting it to a file is about predictability, the >>> ability to locally reason about a type, and the need to define some >>> boundary (for

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

I don't think I would use that. I don't find the aesthetics pleasant. I would rather comment above the string literal. Would the escape character cause the newline for the line to be ignored thereby continuing the string on the next line? > On Apr 12, 2017, at 6:59 AM, Adrian Zubarev via swi

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

I agree. That would be very useful. > On Apr 12, 2017, at 6:16 AM, Thorsten Seitz via swift-evolution > wrote: > >> Am 12.04.2017 um 10:11 schrieb Adrian Zubarev via swift-evolution >> : >> >> Great explanation thank you Brent. I’m convinced about the closing delimiter >> now. =) >> >> If

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

If Xcode or code editors displayed a vertical line at the indentation boundary then it would be like having the continuation character without actually being there. The best of both worlds. That would be really nice. > On Apr 11, 2017, at 8:48 PM, Ricardo Parada via swift-evolut

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

> On Apr 11, 2017, at 8:32 PM, Brent Royal-Gordon via swift-evolution > wrote: > ... > But I'd love to see a faint reddish background behind tripled string literal > content or a vertical line at the indentation boundary. That would be very nice. :-) _

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

Sure. Let me quote the proposal: "We propose that, when the opening delimiter ends its line and the closing delimiter starts its line, tripled string literals should automatically remove whatever indentation is present before the closing delimiter from each line above it, as well as removing th

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

Hi Adrian, I think having the closing """ on a line by itself activates the indentation stripping feature. So if it was to change as you suggest then how would you turn off indentation stripping? > On Apr 11, 2017, at 11:08 AM, Adrian Zubarev via swift-evolution > wrote: > > This would b

Re: [swift-evolution] Enhancing access levels without breaking changes

I have not voted in favor or against the proposal. I have been reading a lot of responses but I agree with Tony. When I started reading the proposal everything was more or less fine half way through the proposal because it was reverting private to fileprivate between the type and its extension

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

Type inference is one of my favorite features of Seift. I don't think anything would make me change my mind. I read the proposal and couldn't quite figure out why such a request. I still have to read the links that explain why though. Regards > On Apr 9, 2017, at 10:05 PM, Daniel Duan via s

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

On Apr 9, 2017, at 12:29 PM, John Holdsworth via swift-evolution mailto:swift-evolution@swift.org>> wrote: > Hi, John here, the submitter of the proposal. > > First up, I must apologise for putting Brent on the spot when I resubmitted > this altered proposal from last year. That was my mistake

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

At one point I was leaning towards a trailing backslash. Now I prefer parenthesis. If parentheses are used should the escape character be outside the parenthesis or inside? For example: let x = (\Person.mother.age).valueType let y = (\Person.mother.age.valueType) vs.

Re: [swift-evolution] SE-165: Dictionary & Set Enhancements

hat have a > need to throw if they want without forcing it on everyone. > >> On Thu, Apr 6, 2017 at 6:53 PM Ricardo Parada via swift-evolution >> wrote: >> >> How important is it that the closure be allowed to throw when resolving >> collisions?

Re: [swift-evolution] SE-165: Dictionary & Set Enhancements

How important is it that the closure be allowed to throw when resolving collisions? In my use cases merging dictionaries he resolving of the collisions is always relatively simple. Shouldn’t they be as below maybe? /// Creates a new dictionary using the key/value pairs in the given seque

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

Hi, I am trying to follow the emails. Would that be same as KeyPath ? Or what is that shorthand? Thanks Ricardo > On Apr 6, 2017, at 8:32 PM, Michael J LeHew Jr via swift-evolution > wrote: > > \Vector -> Int seems like a more appropriate spelling there no? The : is > usually for is-a/c

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

> On Apr 6, 2017, at 3:35 PM, Joe Groff via swift-evolution > wrote: > > Hello Swift community, > > The review of SE-0168 "Multi-Line String Literals" begins now and runs > through April 12, 2017. The proposal is available here: > > https://github.com/apple/swift-evolution/blob/master/propos

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

Ben Rimmington wrote: > > >> On 6 Apr 2017, at 16:29, Ricardo Parada via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> Another thought on the use of single quotes (an possibly the proposed escape >> character). Do you think th

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

;> >> On Apr 6, 2017, at 9:31 AM, Sean Heber wrote: >> >> >>> On Apr 6, 2017, at 11:19 AM, Douglas Gregor wrote: >>> >>>> >>>> On Apr 6, 2017, at 8:13 AM, Ricardo Parada via swift-evolution >>>> wrote: >>>>

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

The escape character is already being used in String interpolation, i.e. \(foo). Also, escaping special characters in string literals, i.e. \t is tab, \n is a newline character, etc. The single quote does not appear to be in use. I believe it's not being used for string literals nor character

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

age\ < 12 You would use the closing character normally when wanting to invoke a method on the key path object. Any thoughts? > On Apr 6, 2017, at 11:13 AM, Ricardo Parada via swift-evolution > wrote: > > I agree, there's an analogy between strings and key paths, and in th

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

I agree, there's an analogy between strings and key paths, and in that regards the single quote would make sense. I would not complain. > On Apr 6, 2017, at 11:08 AM, Sean Heber via swift-evolution > wrote: > >>> That's an interesting point. While `\` alone seems acceptable, I think it's

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

I did not mention single quotes because I was assuming those were reserved for string literals. But if they are available for something like this, it would make it obvious where the key path begins and where it ends. I went through my hypothetical code samples, and I don't mind the \ escape ch

Re: [swift-evolution] Pitch: Compound name `foo(:)` for nullary functions

Agree. > On Apr 6, 2017, at 8:02 AM, Xiaodi Wu via swift-evolution > wrote: > > Given that \foo(bar:baz:) will work, and that \foo() will be unambiguously > distinguished from foo(), I think that would be the only logical result. > > > On Thu, Apr 6, 2017 at 00:40 Jacob Bandes-Storch via sw

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

ties work too > let bestFriendsNameKeyPath = \Person.bestFriend?.name) > ^ this > ``` > > If it’s intentional, I’m very much against it. > > Cheers, > Ed > >> On 6 Apr 2017, at 13:14, Ricardo Parada via swift-evol

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

If we were looking for conciseness then my picks would be: every() - every elements meets condition any() - anyone element meets condition none() - none of the elements meets condition Examples: nums.every { isEven } nums.any { isEven } nums.none { isEven } nums.every(matches: { isEven }) num

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

> On Apr 5, 2017, at 11:13 PM, Xiaodi Wu wrote: > > It is also worth mentioning that, with the sigil, the `keyPath` label may not > be so necessary: > > print(luke[\.friends[0].name]) > // or, if the suggestion above is accepted > print(luke[\.friends[0].name\]) I think the

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

at 9:21 PM, Ricardo Parada via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > >> On Apr 5, 2017, at 9:41 PM, Brent Royal-Gordon via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> It's worth noting that, if you write `\

Re: [swift-evolution] SE-165: Dictionary & Set Enhancements

+1 The only comment I have is the mergingValues argument label for the closure passed in to the merge methods. My preference would be resolvingCollisionsWith:, i.e. merge(_:resolvingCollisionsWith:) and merged(with:resolvingCollisionsWith:). > On Apr 5, 2017, at 8:45 PM, Ben Cohen via swift

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

> On Apr 5, 2017, at 9:41 PM, Brent Royal-Gordon via swift-evolution > wrote: > > It's worth noting that, if you write `\Person.name.valueType`, this syntax is > ambiguous—it could mean "make a key path for the `valueType` property on > `name` property of `Person`", or it could mean "make a k

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

+1 This is much better than #keyPath(Root, .path). I think I can get used to using the escape \ character. I'll think of it as escaping execution of the key path. > On Apr 5, 2017, at 7:01 PM, Douglas Gregor wrote: > > Proposal Link: > https://github.com/apple/swift-evolution/blob/master

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

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

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

Yep, I like those too. I think it would be very clear if they were named that. > On Apr 3, 2017, at 3:57 PM, Adam Bridge wrote: > > Perhaps > > allMembersMatch() > > or > > everyMemberMatches() > > This reads well in use. > > On 2017-04-02, 6:18

Re: [swift-evolution] multi-line string literals.

ed at compile time. The >>>> concatenation is however resolved at runtime if I’m not mistaken here (it >>>> might be optimized at compile time but I still would expect a function >>>> executed a couple of times at runtime). >>>> &g

Re: [swift-evolution] multi-line string literals.

t; How is that better than this? >> >> template = "This is the first line.\n" + >> "This is the second line.\n" + >> "This is the third line." >> >>> On Apr 3, 2017, at 10:42 AM, Ricardo Parada via swift-evolut

Re: [swift-evolution] multi-line string literals.

How is that better than this? template = "This is the first line.\n" + "This is the second line.\n" + "This is the third line." > On Apr 3, 2017, at 10:42 AM, Ricardo Parada via swift-evolution > wrote: > > It look prettier wit

Re: [swift-evolution] multi-line string literals.

Hi Adrian, I'm not sure if I am understanding what you are saying. To me a multi-line string literal is not about continuing a "very long string" into the next line. To me a multi-line string literal is about having a string literal that represents multiple lines of text, where each line is

Re: [swift-evolution] multi-line string literals.

It look prettier without the \n It's not laziness. I want my code to look pretty. > On Apr 3, 2017, at 10:40 AM, Adrian Zubarev > wrote: > > What I was trying to say is that by automatically adding a new line character > does not provide any benefit except of being lazy to type \n. > > //

Re: [swift-evolution] multi-line string literals.

Actually, it would be like this: let veryLongString2 = "word word word" + "word word word" + "word word word" > On Apr 3, 2017, at 10:29 AM, Ricardo Parada via swift-evolution > wrote: > > I think we should focus on taking care of 99%

Re: [swift-evolution] multi-line string literals.

I think we should focus on taking care of 99% of the cases. If you have a very long string then you use the good old fashioned string literal concatenation: Let veryLongString2 = "word word word" + "word word word" + "word word word" By the way, the multi-line string should all

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

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

Re: [swift-evolution] multi-line string literals.

What is the purpose of that backslash? It does not feel like an improvement. I think we should focus on: 1. Looking pretty 2. Allow unescaped quote, double quote as well single/double apostrophe characters 3. Allow interpolation 4. No need to add the \n character for each line 5. It should h

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

or perhaps containsOnly() or maybe allMatch() or membersMatch() :-) Sent from my iPhone > On Apr 2, 2017, at 1:57 AM, Rien via swift-evolution > wrote: > > >> On 02 Apr 2017, at 07:51, Karl Wagner via swift-evolution >> wrote: >> >> Given the relationship to contains, why not keep it simp

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

I think the problem would be that if you want to use it with a trailing closure then it becomes misleading: nums.contains { $0 % 2 == 0 } Sent from my iPhone > On Apr 2, 2017, at 9:01 PM, Jonathan Hull via swift-evolution > wrote: > > What about contains(only:)? > > Thanks, > Jon > >> On

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

I associate exception with error. Sent from my iPhone > On Apr 2, 2017, at 9:32 AM, BJ Homer via swift-evolution > wrote: > > 'forAll' is definitely confusing; it sounds like iteration; I would not > expect that the closure would be required to return a Bool. The > implementation would like

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 preva

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! > > https://gist.github.com/na

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: > > https://github.com/apple/swift

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 % 2

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

I agree. > On Mar 31, 2017, at 5:32 PM, Robert Bennett via swift-evolution > wrote: > > I'm don't think we need all(equal:). > 1) For a host of reasons, having a single signature for a function name is > better than having multiple signatures when the single signature is capable > enough. >

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 tuples because the type begin

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] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

After reading the discussions it seems to me that renaming private -> scoped and fileprivate -> private might keep both sides happy. > On Mar 24, 2017, at 9:06 AM, Vladimir.S via swift-evolution > wrote: > >> On 24.03.2017 11:47, Jonathan Hull via swift-evolution wrote: >> Nevin had a fanta

Re: [swift-evolution] Smart KeyPaths

n Mar 22, 2017, at 4:51 PM, Ricardo Parada via swift-evolution > wrote: > > 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 &

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

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 > > wrote: >> >> I se

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 path

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 me at first. If

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 > wrote: > > > > Sent from my iP

Re: [swift-evolution] Fwd: Re: Smart KeyPaths

You are right. I did not think of that. Sent from my iPhone > On Mar 21, 2017, at 5:34 AM, Brent Royal-Gordon > wrote: > >> On Mar 20, 2017, at 9:12 PM, Ricardo Parada via swift-evolution >> wrote: >> >> If a character had to be used to denote key paths

Re: [swift-evolution] Fwd: Re: Smart KeyPaths

If a character had to be used to denote key paths then I would prefer this one: 1. Type:path.to.value and instance:path.to.value I feel like the # screams at me. :-) > On Mar 20, 2017, at 1:52 PM, Matthew Johnson via swift-evolution > wrote: > > >> On Mar 20, 2017, at 12:37 PM, Vladimir.S vi

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

I'm in favor of this pattern. > On Mar 20, 2017, at 4:40 PM, Jonathan Hull via swift-evolution > wrote: > > Huge +1 > > >> On Mar 17, 2017, at 9:26 AM, Riley Testut via swift-evolution >> wrote: >> >> Hi again everyone! >> >> Now that Swift 4 Stage 2 proposals are being considered, I t

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 4:01 PM, Kenny Leung via sw

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: > > > > Sent from my iPad

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 > wrote: > > >> On Mar

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, at 12:57 PM, Charles Srstka via swift-evolution

Re: [swift-evolution] Smart KeyPaths

at the end. I'm excited about this proposal and want it to be the successful. One of the most exciting things happening in swift right now IMHO. > On Mar 19, 2017, at 3:51 PM, Jean-Daniel wrote: > > >> Le 19 mars 2017 à 16:41, Ricardo Parada via swift-evolution >> a

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 as

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. N

Re: [swift-evolution] [pitch] Variadic Arguments should accept Arrays

I read Haravikk's proposal a second time. I think I see the advantage of being able to use it with other types besides array. I also found disambiguating with the trailing comma to be intuitive. On the other hand I did not find it so intuitive to use @variadic and @nonVariadic to disambiguate.

Re: [swift-evolution] [pitch] Variadic Arguments should accept Arrays

In other languages I normally have a method with a variable number of arguments and another one taking an array. Then one typically ends up calling the other. If we had implicit splatting I imagine it would reduce such methods to only one. However if implicit splatting were to cause problems

Re: [swift-evolution] [pitch] Variadic Arguments should accept Arrays

> On Feb 26, 2017, at 10:00 PM, Derrick Ho via swift-evolution > wrote: > > foo(["a", "b", "c"] as String...) I like this ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Three questions about a more "dynamic" Swift for InfoQ

> On Sep 26, 2016, at 5:32 PM, Robert Widmann via swift-evolution > wrote: > > No, and I think moving towards a more dynamic Swift now without > as-of-yet-seen significant justification would be a mistake. Swift should be > as static as possible. We should be making every attempt to pare do

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

WebObjects is one of the frameworks I was referring to without actually naming it. After Apple stopped supporting WebObjects we have been able to fix, extend and enhance it all these years and has served us really well. It is an awesome framework. I really wish that Swift had a framework like

Re: [swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly

I have been following the discussion and reading the arguments in favor and against. I think I understand both sides better now. If this proposal is accepted I hope some more thought is given to the naming. I would like to echo what others have said regarding the names. In particular I am sti

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

> On Jul 5, 2016, at 7:11 PM, Chris Lattner wrote: > > Hello Swift community, > > The review of "SE-0117: Default classes to be non-subclassable publicly" > begins now and runs through July 11. The proposal is available here: > > > https://github.com/apple/swift-evolution/blob/master/prop

Re: [swift-evolution] Ad hoc enums / options

Hi Laurent, Do you have the details of your proposal, I missed it. Thanks > On Jun 2, 2016, at 1:48 AM, L Mihalkovic wrote: > > >>> On Jun 2, 2016, at 5:05 AM, Christopher Kornher via swift-evolution >>> wrote: >>> >>> >> >&

Re: [swift-evolution] Ad hoc enums / options

> On Jun 1, 2016, at 5:38 PM, Tony Allevato via swift-evolution > wrote: > > we could consider allowing this: > > func foo(bar: (.fit | .fill)) { > baz(bar: bar) > } > func baz(bar: (.fit | .fill | .florp) { ... } > > In other words, an ad hoc enum T can be used wherever an

Re: [swift-evolution] Ad hoc enums / options

> On May 31, 2016, at 3:04 PM, Erica Sadun via swift-evolution > wrote: > > let _ = scaleAndCropImage(image: myImage, toSize: size, operation: .fill) > > You would not be able to assign `.fill` to a variable and use that for the > operation value. This is my objection to this idea. It does n

Re: [swift-evolution] [Pitch] Property reflection

Would it let me get a property if it does not correspond to a property, or computed property? For example, would I be able to get the value returned by a fullName() instance method that concatenates the firstName and lastName properties together and returns the result? Or would it only work if

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

Inline > On May 27, 2016, at 2:52 PM, Matthew Johnson wrote: > > >> On May 27, 2016, at 12:48 PM, Ricardo Parada wrote: >> >> >> What if we get the error when trying to use it? For example, if a struct >> uses a value that is not Equatable / Hashable then it would not be Equatable >> / H

Re: [swift-evolution] [Pitch] Property reflection

> On May 26, 2016, at 9:25 PM, Austin Zheng via swift-evolution > wrote: > > ``` > myPerson.typedReadWriteProperty("age")?.set(30) > > try myPerson.allNamedProperties["age"]?.set(30) > ``` > Can you elaborate on what this API would be used for? KVC? For instance, I played with Mirror the o

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

What if we get the error when trying to use it? For example, if a struct uses a value that is not Equatable / Hashable then it would not be Equatable / Hashable and you would not find out until you tried to use it. Would that be bad? > On May 26, 2016, at 11:35 AM, Matthew Johnson via swift

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

fulfils >>> the requirements (all members are also Equatable), then its implementation >>> is automatically created for you. That way you don’t need a new keyword. >>> It’s like Objective-C’s property automatic synthesising that get used >>> unless you implement ones yo

  1   2   >