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

[Ricardo Parada via swift-evolution]

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 as an additive feature.
[...]"

So it sounds that can be considered in a separate proposal to be added to 
normal and multi-line string literals. 



> On Apr 21, 2017, at 2:57 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
>> On Fri, Apr 21, 2017 at 1:46 PM, David Hart  wrote:
>> 
>>> On 21 Apr 2017, at 20:20, Xiaodi Wu  wrote:
>>> 
 On Fri, Apr 21, 2017 at 8:45 AM, David Hart  wrote:
 
> On 21 Apr 2017, at 11:32, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> Dear Xiaodi Wu, why do you always have to be offensive in a way of 
> questioning every single word another person says and not letting others 
> to have their own opinion?! I do not want to have a discussion with you 
> that will and up you asking me why is the banana crooked. I expect a 
> focused and a constructive discussion if not mentioned otherwise.
> 
> My expectation from the model of the multi-lined string literal might be 
> different from yours and you’ll have to bear with that, because I’ve got 
> my own opinion. If you’d like me to see things differently, try to 
> convince me instead of being unfocused and questioning every single word 
> I’m saying. That won’t lead use to anywhere.
> 
 
 Hi Adrian. For what it's worth, I did not detect any offense in Xiaodi’s 
 questions. I think he was just asking questions to point parts of your 
 opinion which he did not understand or was missing some reasoning.
>>> 
>>> Yes, that was my intention.
>>>  
> I expect the model to solve two major problems. The first one is already 
> solved by the accepted version. The second one is the ability to escape 
> new lines when needed (notice, I do not want to escape them all the time, 
> but only where it’s desired). The accepted version adds more 
> possibilities to the language and will definitely fix a lot of pain with 
> string literals some developer had. I’m happy to see that. However from 
> my personal standpoint, I do not write any code generators created from 
> string literals as it was a heavily overused example in the proposal and 
> during the discussion. I often need the ability to wrap very long strings 
> into multiple lines for readability, but keep the result string intact. 
> In my last response I showed a sample on how it might look like and that 
> it’s really painful to read such a string on Git, because it does not 
> provide any soft-wrapping like other tools might do. That is why I keep 
> saying that the multi-line string literal should not rely on editors to 
> solve that problem. Otherwise the bare existence of the such literal 
> could be questioned and we could fully fall back to editor features like 
> soft-wrapping or let the editor also wrap strings when it finds a new 
> line character \n to mimic the proposed behavior. I also do not like the 
> argument of using string concatenation to solve my particular issue, 
> because the strings are very long and it quickly becomes were tedious. 
> Furthermore, the multi-line string literal should not be only reserved 
> for solving the problems you’ve mentioned. A trailing backslash does not 
> add any complexity, and you personally don’t need that feature it does 
> not mean that others won’t need it. It’s an additional feature which is 
> lightweight and which won’t harm the copy-paste phenomenon most of you 
> wanted. If you really think it adds complexity than you should also 
> justify your thoughts to convince your conversation partner. 
> 
> IMHO ‘complexity’ creates ‘flexibility’. If we’d only had one access 
> modifier in Swift the model would be really simple but not flexible. Not 
> that we have a bunch of them the model become complex but on the other 
> hand it also become way more flexible.
> 
 
 But for what its worth, I agree with Adrian. Let me try to expose the 
 use-case the proposal is not addressing:
 
 A group of people (me included) don’t wrap lines in their editor (by 
 choice) but make sure that lines of code don’t extend over a certain limit 
 (80, 100, 120, whatever). This allows us to keep code readable and control 
 the wrapping behaviour by manually applying it.
 
 For those people, writing long prose which extends over our limit (like is 
 the case in some error/assert/precondition messages), we won’t be able to 
 use the multi-line string proposal and we will have to stay with 

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

[Ricardo Parada via swift-evolution]

> 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 whenever the value is non-'nil'; \
>>did you mean to use '!= nil'?\
>>"""
>> 
> 
> This only works because the lines have been indented by hand to match 
> correctly which would not be the case with standard indentation used in a 
> code editor which is a fixed multiple of spaces or tabs: the example had to 
> add 2 spaces to the 2 tabs in this example to fix the indentation (requiring 
> 8-space-tabs). In reality the example would look like follows (assuming 
> 4-space-indentation but the problem is the same for other indentations):
> 
> case .isExprSameType(let from, let to):
> return """checking a value with optional type \(from) \
> against dynamic type \(to) \
> succeeds whenever the value is non-'nil'; \
> did you mean to use '!= nil'?\
> """

That is perfectly fine too. I don't find this style confusing.  The 2nd, 3rd 
and 4th lines are stripped of their indentation according to the closing 
delimiter. And that is it.

>> I personally do not find this style confusing at all. 
> 
> The confusion arises over the leading newline: why does text directly 
> following the opening triple quote have a newline while an empty line after 
> the opening triple quote does not have a newline?

I think it is a good thing to have the option to start the line of text 
immediately after the opening delimiter or on the next line.

Regards,
Ricardo

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ricardo Parada via swift-evolution]

Reply inline. 

On Apr 15, 2017, at 8:48 AM, Thorsten Seitz via swift-evolution 
> wrote:

> 
>> Am 15.04.2017 um 09:24 schrieb Adrian Zubarev via swift-evolution 
>> >:
>> 
>> I disagree, the examples you have provided are more complicated than you 
>> might think they are. Before explaining why, I’m going to make things clear 
>> about the ‘two modes’ of the multi-line string literal.
>> 
>> I’m not sure where this wording has popped out first and I’m not going to 
>> search for it. IIRC Xiaodi Wu has pitched the idea before me to ban text 
>> after the starting delimiter. After Brents reply where I questioned the 
>> stripping algorithm for literals like the following one:
>> 
>> """abc
>> def"""
>> I was convinced that we should not put any text before the closing delimiter 
>> to make the algorithm easier to understand. Combined with the mentioned 
>> pitch by Xiaodi Wu, I suggested to fully ban three options of the 
>> (revisited) proposed literal.
>> 
>> let v1 = """abc
>>def"""
>>  
>> let v2 = """abc
>>def
>>"""
>> 
>> let v3 = """
>>abc
>>def"""
>> This allows us to craft a far simpler model, which would be easy to learn 
>> and teach. Yet we haven’t removed or added new ‘modes’ from/to the model 
>> itself. I don’t think it was ever intended for v1 to add an implicit 
>> trailing new line after "def"?! The first small examples support my 
>> assumption here:
>> 
>> https://github.com/johnno1962a/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md#simple-multi-line-string
>>  
>> 
>> """Hello\↵
>> world!"""
>> 
>> 
>> // Result:
>> "Helloworld!"
>> What we did so far, was only to disallow a few options on how we should not 
>> write multi-line string literals in Swift. We did not add any 
>> differentiation between the option of ‘single-lined’ tripled string literal 
>> and the one that contains more than a single content line in it. Simply as 
>> that v3 was tweaked to have an explicit ↵ at the end of its last content 
>> line to follow the rules, but the resulting string should remain the same.
>> 
>> let from_v3_to_v4 = """
>>abc
>>def
>>"""
>> Unfortunately the revisited proposal does not contain any examples like
>> 
>> let str_1 = """
>>abc"""
>> 
>> let str_2 = """
>>abc
>>"""
>> to strengthen my argumentation even further. str_1 is an example where you 
>> could think that you’ve simply rotated the way how you’d write the literal 
>> from a single line into two lines, which as currently proposed would be 
>> totally valid and produce the "abc" string. str_2 is the same string as 
>> str_1 but with adopted delimiter restrictions.
>> 
>> Long story short, there are no different modes the literal provides for you. 
>> You cannot write (visually) multiple lines in a single content line right 
>> (except with \n, but that’s not what I mean here). Think about it, don’t let 
>> you fool yourself by my wording. But you should be able to write a single 
>> line in a multi line content way and still have the same result as before. 
>> This rule only applies to the last content line, but since a single line is 
>> automatically the last content line the next two literals produces the exact 
>> same string.
>> 
>> let str_3 = """abc"""
>> 
>> let str_4 = """
>>abc
>>"""
>> 
>> str_3 == str_4 // => true
>> str_3 == "abc" // => true
>> Now it’s time to solve the puzzle in your example. The correct result should 
>> be as follows:
>> 
>> (a + b) == """
>> This is line one
>> This is line twoThis is line three
>> This is line four
>> """
>> 
>> // Or more precise
>> (a + b) == "This is line one\nThis is line twoThis is line three\nThis is 
>> line four“
> 
> I disagree and think BJ Homer is right: the multiline variant contains 
> *lines* which all end with a newline. That is a very simple mental model.
> 
> I do agree that the mixed modes (v1, v2, v3) should be banned.

Hi Thorsten, I think v2 would allow you to pick an alternate style to define 
your multiline string literal. For example, take a look at the xml string 
literal defined in two different ways under the Indentation Stripping section 
in Brent's proposal here:

https://github.com/johnno1962a/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md
 


Here is another example:

case .isExprSameType(let from, let to):
return """checking a value with optional type \(from) \
  against dynamic type \(to) \
  succeeds whenever the value is non-'nil'; \
  did you mean to use '!= nil'?\
  

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

[Ricardo Parada via swift-evolution]

This is all runtime processing. I think the indentation stripping is better 
done at compile time. 

You should be able to select the multi-line string constants in your array of 
stories example and indent them to look good in your code. Then just use the 
closing delimiter to tell the compiler how much indentation to strip. 

Here is Brent's excellent proposal in case you have not seen it:

https://github.com/johnno1962a/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md


> On Apr 14, 2017, at 11:12 PM, Muse M <james.le...@gmail.com> wrote:
> 
> This would be prefer to follow Scala multiline string which look
> 
> 1) //Default 
> var code = """header
> paragraph1"""
> 
> Output:
> >header
> >paragraph1
> 
> 2)
> var code = """
> ...header...
> ...paragraph1...
> """.replace("...")
> 
> Output:
> >header
> >paragraph1
> 
> 3)
> var code = """
>  |..header...
>  |..paragraph1...
> """.stripLeadingSpace()
> 
> Output:
> >header...
> >paragraph1...
> 
> 4)
> var code = """
> 
> import Foundation
> print("Hello World!")
> 
> """.code()
> 
> Output:
> >
> >import Foundation
> >print("Hello World!")
> >
> 
> 5)
> //To remove all new lines
> var code = """
> import Foundation
> 
> import Cocoa
> 
> print("Hello World!")
> """.compactLine()
> 
> Output:
> >import Foundation
> >import Cocoa
> >print("Hello World!")
> 
> 
> 
> 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 = {
> """
> Chapter1
> 第1章
> 
> Introduction to A
> """,
> """
> Chapter2
> 第2章
> 
> Introduction to B
> """,
> """
> //Code Example
> import Foundation
> """
> }
> 
> We can loop or apply to certain collection
> stories(3).code()
> 
> 
> 
>> On Saturday, April 15, 2017, Ricardo Parada via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> 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 this:
>> 
>> let str = """
>>Line 1
>>Line 2\
>>"""
>> 
>> This is were it's difficult to get consensus. 
>> 
>> Regards,
>> Ricardo 
>> 
>> 
>>> On Apr 14, 2017, at 5:54 PM, BJ Homer via swift-evolution 
>>> <swift-evolution@swift.org> wrote:
>>> 
>>> I’m not saying that the + operator should automatically add a newline. I’m 
>>> saying that both strings should contain a trailing newline, such that the 
>>> visible result is the same.
>>> 
>>> By contrast, this would feel really strange:
>>> 
>>> let a = """
>>> This is line one
>>> This is line two
>>> 
>>> """
>>> 
>>> let b = """
>>> This is line three
>>> This is line four
>>> """
>>> 
>>> (a + b) == """
>>> This is line one
>>> This is line two
>>> This is line three
>>> This is line four
>>> """
>>> 
>>> On initial intuition, it seems strange that ‘a’ has a blatantly visible 
>>> blank line at the end which seemingly “disappears” when the strings are 
>>> concatenated. If I think about it for a bit, I can understand why that 
>>> would be the case, but I think it’s non-obvious.
>>> 
>>> -BJ
>>> 
>>>> On Apr 14, 2017, at 3:49 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote:
>>>> 
>>>> I disagree. I expect the last result to be from `a + "\n" + b`, for the 
>>>> reasons I outlined earlier.
>>>> 
>>>> The concatenation operator + does not introduce implied separators when 
>>>> joining strings. There is no reason to thi

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

[Ricardo Parada via swift-evolution]

> 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-with-inout.md

>   • 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

>   • How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

Quick read and read some of the responses. 


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ricardo Parada via swift-evolution]

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 this:

let str = """
   Line 1
   Line 2\
   """

This is were it's difficult to get consensus. 

Regards,
Ricardo 


> On Apr 14, 2017, at 5:54 PM, BJ Homer via swift-evolution 
>  wrote:
> 
> I’m not saying that the + operator should automatically add a newline. I’m 
> saying that both strings should contain a trailing newline, such that the 
> visible result is the same.
> 
> By contrast, this would feel really strange:
> 
> let a = """
> This is line one
> This is line two
> 
> """
> 
> let b = """
> This is line three
> This is line four
> """
> 
> (a + b) == """
> This is line one
> This is line two
> This is line three
> This is line four
> """
> 
> On initial intuition, it seems strange that ‘a’ has a blatantly visible blank 
> line at the end which seemingly “disappears” when the strings are 
> concatenated. If I think about it for a bit, I can understand why that would 
> be the case, but I think it’s non-obvious.
> 
> -BJ
> 
>> On Apr 14, 2017, at 3:49 PM, Xiaodi Wu  wrote:
>> 
>> I disagree. I expect the last result to be from `a + "\n" + b`, for the 
>> reasons I outlined earlier.
>> 
>> The concatenation operator + does not introduce implied separators when 
>> joining strings. There is no reason to think that it should for multi-line 
>> strings specifically.
>>> On Fri, Apr 14, 2017 at 16:35 BJ Homer via swift-evolution 
>>>  wrote:
>>> 
 Consider these two examples:
 
 let string_1 = """foo"""
 
 
 let string_2 = """
 foo
 """
 What’s the intuitive result you’d expect without taking all the long talk 
 from the list into account?
 
 Personally, I’d say string_1 == string_2 is true.
 
>>> 
>>> I think it’s reasonable to expect them to be different, actually. I might 
>>> call these “single-line” and “multi-line” mode strings. The single-line 
>>> mode is primarily useful for being able to include unescaped double-quotes 
>>> in the string. If you’re in multi-line mode, though, it’s reasonable to be 
>>> thinking about things in terms of “lines”, and having a trailing newline 
>>> there seems reasonable. For example, I think it’s reasonable to expect this:
>>> 
>>> let a = """
>>> This is line one
>>> This is line two"
>>> """
>>> 
>>> let b = """
>>> This is line three
>>> This is line four
>>> """
>>> 
>>> (a + b) == """
>>> This is line one
>>> This is line two
>>> This is line three
>>> This is line four
>>> """
>>> 
>>> That seems like a reasonable model to work with multi-line strings.
>>> 
>>> -BJ
>>> ___
>>> 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
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ricardo Parada via swift-evolution]

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/swift-evolution

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

[Ricardo Parada via swift-evolution]

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 better idea for 
> a fix-it. :-)
> 
> let str_8 = """↵  
> foo··↵
> """
> warning: line # includes trailing space characters in multi-line string 
> literal
>   foo··
>  ~~  
>   Fix-it: Insert "\n\" (after these space characters)
> The fix-it will inset \n\ after all your space characters, so the developer 
> is kinda forced to strip them manually to foo or let the IDE add \n\ if 
> he really needs that precision.
> 
> That would work. :)
> 
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 13. April 2017 um 15:46:52, John Holdsworth (m...@johnholdsworth.com 
> ) schrieb:
> 
>> \n\
>> would work
>> 
>>> On 13 Apr 2017, at 14:44, John Holdsworth >> > wrote:
>>> 
>>> 
>>> I’ve never understood how you mean "explicit backslash". backslash has 
>>> specific roles
>>> and at the moment it is assigned to meaning standard escapes or "don’t 
>>> include this next
>>> newline in the literal". I can’t see how it could be reassigned to mean 
>>> “include whitespace”
>>> without loosing the option to concatenate lines.
>>> 
>>> fix-its are beyond my pay grade so that’ll have to wait until Apple looks 
>>> at the implementation!
>>> 
>>> 
 On 13 Apr 2017, at 14:32, Adrian Zubarev > wrote:
 
 A warning that will popup when you included any trailing spaces in a 
 ‘content line’ without the explicit backslash could also provide a fix-it 
 to the user to remove these spaces. However if you can emit that warning 
 and calculate the spaces to remove, than the compiler should be able to 
 swallow these characters by default right?
 
 
>>> 
>> 
> 
> 
> ___
> 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] [Review] SE-0168: Multi-Line String Literals

[Ricardo Parada via swift-evolution]

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 surprise me if I put a space there and then the compiler 
removes it.

Also, what would this mean?

"""
Line 1\
Line 2
"""

Is that backslash escaping the newline? or is it there to include the trailing 
whitespace on Line 1?  


> On Apr 13, 2017, at 9:20 AM, Adrian Zubarev  
> wrote:
> 
> This is not an assumptions but a fact that the trailing spaces cannot and 
> should not exist without an explicit annotation for precision, otherwise the 
> backslash looses one of its main and significant functionality.
> 
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 13. April 2017 um 15:13:50, Ricardo Parada (rpar...@mac.com 
> ) schrieb:
> 
>> 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 
>>> string will be.
>>> 
>>> """
>>> foo
>>> """
>>> I could tell you, that the string from above could have 10k characters, 
>>> even if you wouldn’t believe me, as it was proposed (and included in 
>>> yesterday’s toolchain) my claim can be true.
>>> 
>>> The trailing spaces needs to be stripped by the algorithm unless there is 
>>> an explicit precision annotation with a backslash!
>>> 
>>> """
>>> foo   \
>>> """
>>> That example definitely won’t have 10k characters.
>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> Adrian Zubarev
>>> Sent with Airmail
>>> 
>>> Am 13. April 2017 um 14:35:59, Ricardo Parada (rpar...@mac.com 
>>> ) schrieb:
>>> 
 Trailing whitespace 
 
 You also propose to remove trailing white space in each line unless the 
 whitespace is followed by a backslash.   For example:
 let str_2 = """↵
 foo··↵
 """
 The two trailing whitespaces after foo would get removed according to what 
 you are proposing. I don't like this rule. I think we are better off with 
 leaving it alone and to the tools as Brent suggested. 
>>> 
>> 
> 
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ricardo Parada via swift-evolution]

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 
> string will be.
> 
> """
> foo
> """
> I could tell you, that the string from above could have 10k characters, even 
> if you wouldn’t believe me, as it was proposed (and included in yesterday’s 
> toolchain) my claim can be true.
> 
> The trailing spaces needs to be stripped by the algorithm unless there is an 
> explicit precision annotation with a backslash!
> 
> """
> foo   \
> """
> That example definitely won’t have 10k characters.
> 
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 13. April 2017 um 14:35:59, Ricardo Parada (rpar...@mac.com 
> ) schrieb:
> 
>> Trailing whitespace 
>> 
>> You also propose to remove trailing white space in each line unless the 
>> whitespace is followed by a backslash.   For example:
>> let str_2 = """↵   
>> foo··↵
>> """
>> The two trailing whitespaces after foo would get removed according to what 
>> you are proposing. I don't like this rule. I think we are better off with 
>> leaving it alone and to the tools as Brent suggested. 
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ricardo Parada via swift-evolution]

I think it's solid and thorough.  I think it's winner.


> On Apr 13, 2017, at 8:41 AM, Brent Royal-Gordon <br...@architechies.com> 
> wrote:
> 
>> On Apr 13, 2017, at 5:35 AM, Ricardo Parada via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> 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
>>  
>> <https://github.com/johnno1962a/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md>
> Well, um, looks like we got scooped. (I was playing with some non-essential 
> wording and trying to test all the examples before I pointed the list at the 
> new version.)
> 
> Since requiring a leading backslash went over like a lead balloon, we've 
> revised the proposal one more time. The leading newline is now optional: If 
> indentation stripping is enabled, you can either start typing content on the 
> same line as the delimiter, or you can start on the next line. I resisted 
> this solution for a while because it seems ad-hoc, but ultimately it's the 
> design that preserves the most formatting flexibility for the user, so I 
> think it's the right way to go.
> 
> Other than that, there are no changes to the design in this revision, though 
> I've rephrased a few things and added a section about why we strip a leading 
> newline but not a trailing one.
> 
> John has also built a new version of the toolchain which matches this 
> behavior. Download it here: 
> http://johnholdsworth.com/swift-LOCAL-2017-04-13-a-osx.tar.gz 
> <http://johnholdsworth.com/swift-LOCAL-2017-04-13-a-osx.tar.gz>
> 
> Thanks for your feedback!
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ricardo Parada via swift-evolution]

Oops, my apologies for misspelling your name.  It was a typo.

> On Apr 13, 2017, at 8:35 AM, Ricardo Parada via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> 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
>  
> <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 newline on the last line should be 
> included.  You are proposing it should not be included which will add an 
> empty line to Brent's xml concatenation example. The example looks better 
> when the trailing newline is included. 
> 
> In the more rare case where the newline is not desired on the last line then 
> you can just include the backslash at the end. See Brent's revised proposal: 
> https://github.com/johnno1962a/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md
>  
> <https://github.com/johnno1962a/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md>
> 
> Trailing whitespace 
> 
> You also propose to remove trailing white space in each line unless the 
> whitespace is followed by a backslash.   For example:
> let str_2 = """↵  
> foo··↵
> """
> The two trailing whitespaces after foo would get removed according to what 
> you are proposing. I don't like this rule. I think we are better off with 
> leaving it alone and to the tools as Brent suggested. 
> 
> Regards,
> Ricardo Parada
> 
> 
> 
> 
> On Apr 13, 2017, at 5:28 AM, Adrian Zubarev via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> 
>> Now that I had some sleep I actually revise my opinion about the last line. 
>> I took a few hours to sum my thoughts together in a gist, here is a 
>> formatted version of it: 
>> https://gist.github.com/DevAndArtist/dae76d4e3d4e49b1fab22ef7e86a87a9 
>> <https://gist.github.com/DevAndArtist/dae76d4e3d4e49b1fab22ef7e86a87a9>
>> Simple ‘multi-line string literal’ model
>> 
>> Core features:
>> 
>> Omitting of (most) backslashes for ".
>> Altering the string with implicit new line injection at the end of the line.
>> Consequences of #1:
>> 
>> To omit escaping the quote character, the delimiter characters for the 
>> multi-line string literal will be tripled quotes """, also similar to other 
>> programming languages.
>> 
>> When a standard string literal contains at least 5 quotes, then the usage of 
>> a multi-line string literal will be shorter.
>> 
>> ""// With escapes
>> """"""  // With tripled 
>> literals
>> Consequences of #2:
>> 
>> To fully support this feature, we need to compromise the design for 
>> simplicity and intuitivity.
>> 
>> This feature needs precision for leading and trailing spaces.
>> Alternatively one would need a way to disable new line injection to also 
>> support code formatting.
>> Two ways of writing a multi-line string literal:
>> 
>> Single line version """abc""" is trivial and already was shown above.
>> 
>> The multi-line version comes with a few compromises for simplicity of rules:
>> 
>> """   // DS (delimiter start)
>> foo   // s0
>> foo   // s1
>> foo   // s2
>> """   // DE (delimiter end)
>> The string content is always written between the lines DS and DE (delimiter 
>> lines). 
>> 
>> To not to go the continuation quotes path, the left (or leading) precision 
>> is handled by the closing delimiter (1. compromise). The closing delimiter 
>> is also responsible for the indent algorithm, which will calculate the 
>> stripping prefix in line DE and apply stripping to lines s0 to sn.
>> 
>> Right (or trailing) precision of each line from s0 to sn (notice n equals 2 
>> in the example above) is handled by a backslash character (2. compromise).
>> 
>> The right precision comes at a price of losing the implicit new line 
>> injection, however this was also a requested feature (3. compromise). That 
>> means that the backslash serves two jobs simultaneously.
>> 
>> New line injection happens only on lines s0 to s(n - 1) (4. and last 
>> compromise of the design). The last line sn (or s2 above

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

[Ricardo Parada via swift-evolution]

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 newline on the last line should be 
included.  You are proposing it should not be included which will add an empty 
line to Brent's xml concatenation example. The example looks better when the 
trailing newline is included. 

In the more rare case where the newline is not desired on the last line then 
you can just include the backslash at the end. See Brent's revised proposal: 
https://github.com/johnno1962a/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md

Trailing whitespace 

You also propose to remove trailing white space in each line unless the 
whitespace is followed by a backslash.   For example:
let str_2 = """↵  
foo··↵
"""
The two trailing whitespaces after foo would get removed according to what you 
are proposing. I don't like this rule. I think we are better off with leaving 
it alone and to the tools as Brent suggested. 

Regards,
Ricardo Parada




On Apr 13, 2017, at 5:28 AM, Adrian Zubarev via swift-evolution 
> wrote:

> Now that I had some sleep I actually revise my opinion about the last line. I 
> took a few hours to sum my thoughts together in a gist, here is a formatted 
> version of it: 
> https://gist.github.com/DevAndArtist/dae76d4e3d4e49b1fab22ef7e86a87a9 
> 
> Simple ‘multi-line string literal’ model
> 
> Core features:
> 
> Omitting of (most) backslashes for ".
> Altering the string with implicit new line injection at the end of the line.
> Consequences of #1:
> 
> To omit escaping the quote character, the delimiter characters for the 
> multi-line string literal will be tripled quotes """, also similar to other 
> programming languages.
> 
> When a standard string literal contains at least 5 quotes, then the usage of 
> a multi-line string literal will be shorter.
> 
> ""// With escapes
> ""  // With tripled 
> literals
> Consequences of #2:
> 
> To fully support this feature, we need to compromise the design for 
> simplicity and intuitivity.
> 
> This feature needs precision for leading and trailing spaces.
> Alternatively one would need a way to disable new line injection to also 
> support code formatting.
> Two ways of writing a multi-line string literal:
> 
> Single line version """abc""" is trivial and already was shown above.
> 
> The multi-line version comes with a few compromises for simplicity of rules:
> 
> """   // DS (delimiter start)
> foo   // s0
> foo   // s1
> foo   // s2
> """   // DE (delimiter end)
> The string content is always written between the lines DS and DE (delimiter 
> lines).
> 
> To not to go the continuation quotes path, the left (or leading) precision is 
> handled by the closing delimiter (1. compromise). The closing delimiter is 
> also responsible for the indent algorithm, which will calculate the stripping 
> prefix in line DE and apply stripping to lines s0 to sn.
> 
> Right (or trailing) precision of each line from s0 to sn (notice n equals 2 
> in the example above) is handled by a backslash character (2. compromise).
> 
> The right precision comes at a price of losing the implicit new line 
> injection, however this was also a requested feature (3. compromise). That 
> means that the backslash serves two jobs simultaneously.
> 
> New line injection happens only on lines s0 to s(n - 1) (4. and last 
> compromise of the design). The last line sn (or s2 above) does not inject a 
> new line into the final string. This implies that in this line a backslash 
> character handles only right precision, or one could say it’s reduced to one 
> functionality.
> 
> Important:
> 
> Because whitespace is important to these examples, it is explicitly 
> indicated: · is a space, ⇥ is a tab, and ↵ is a newline.
> 
> Leading/trailing precision and indent (1. and 2. compromise):
> 
> // Nothing to strip in this example (no ident).
> let str_1 = """↵  
> foo↵
> """
> 
> // No right precision (no backslash) -> whitespaces will be stripped.
> let str_2 = """↵  
> foo··↵
> """
> 
> // Same as `str_2`
> let str_3 = """↵  
> foo↵
> """
> 
> // Line `DE` of the closing delimiter calculates the indent prefix  
> // `··` and strips it from `s0` (left precision).
> let str_4 = """↵  
> ··foo↵
> ··"""
> 
> // Line `DE` of the closing delimiter calculates the indent prefix  
> // `` and strips it from `s0` (left precision).
> // No right precision (no backslash) -> whitespaces will be stripped.
> let str_5 = """↵  
> foo··↵
> """
> 
> // Line `DE` of the closing delimiter calculates the indent prefix  
> // `⇥ ⇥ ` and strips it from `s0` (left precision).
> // Right precision is applied 

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

[Ricardo Parada via swift-evolution]

On Apr 12, 2017, at 6:20 PM, Brent Royal-Gordon via swift-evolution 
> 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:

print( """
Usage: myapp 

Run myapp to do mything

Options:
-myoption - an option
""" )

Additionally, allow the string to start immediately after the opening """.  In 
this scenario the indentation stripping is performed starting with the second 
line:

case .isExprSameType(let from, let to):
return """checking a value with optional type \(from) \
  against dynamic type \(to) \
  succeeds whenever the value is non-'nil'; \
  did you mean to use '!= nil'?\
  """

And definitely something like this too:

let html = ""

Again, the string literal is allowed to start immediately after the opening 
""".  And No newline stripping is required here because the closing """ is not 
on a line by itself.


> Okay, let's deal with trailing newline first. I'm *very* confident that 
> trailing newlines should be kept by default. This opinion comes from lots of 
> practical experience with multiline string features in other languages. In 
> practice, if you're generating files in a line-oriented way, you're usually 
> generating them a line at a time. It's pretty rare that you want to generate 
> half a line and then add more to it in another statement; it's more likely 
> you'll interpolate the data. I'm not saying it doesn't happen, of course, but 
> it happens a lot less often than you would think just sitting by the fire, 
> drinking whiskey and musing over strings.
> 
> I know that, if you're pushing for this feature, it's not satisfying to have 
> the answer be "trust me, it's not what you want". But trust me, it's not what 
> you want.
> 
> Moving to the other end, I think we could do a leading newline strip *if* 
> we're willing to create multiline and non-multiline modes—that is, newlines 
> are _not allowed at all_ unless the opening delimiter ends its line and the 
> closing delimiter starts its line (modulo indentation). But I'm reluctant to 
> do that because, well, it's weird and complicated. I also get the feeling 
> that, if there's a single-line mode and a multi-line mode, we ought to treat 
> them as truly orthogonal features and allow `"`-delimited strings to use 
> multi-line mode, but I'm really not convinced that's a good idea.
> 
> (Note, by the way, that heredocs—a *really* common multiline string 
> design—always strip the leading newline but not the trailing one.)
> 
> Adrian cited this example, where I agree that you really don't want the 
> string to be on the same line as the leading delimiter:
> 
>   let myReallyLongXMLConstantName = """
>
>   
>  John Doe
>  XML Developer's 
> Guide
>  Computer
>  44.95
>   
>\
>"""
> 
> But there are lots of places where it works fine. Is there a good reason to 
> force an additional newline in this?
> 
>   case .isExprSameType(let from, let to):
>   return """checking a value with optional type 
> \(from) against dynamic type \(to) \
> succeeds whenever the value is 
> non-'nil'; did you mean to use '!= nil'?\
> """
> 
> I mean, we certainly could, but I'm not convinced we should. At least, not 
> yet.
> 
> In any case, trailing newline definitely stays. Leading newline, I'm still 
> thinking about.
> 
> As for other things:
> 
> * I see zero reason to fiddle with trailing whitespace. If it's there, it 
> might be significant or it might not be. If we strip it by default and we 
> shouldn't, the developer has no way to protect it. Let's trust the developer. 
> (And their tooling—Xcode, I believe Git, and most linters already have 
> trailing whitespace features. We don't need them too.)
> 
> * Somebody asked about `"""`-delimited heredocs. I think it's a pretty 
> syntax, but it's not compatible with single-line use of `"""`, and I think 
> that's probably more important. We can always add heredocs in another way if 
> we decide we want them. (I think `#to(END)` is another very Swifty syntax we 
> could use for heredocs--less lightweight, but it gives us a Google-able 
> 

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

[Ricardo Parada via swift-evolution]

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:
> 
> Line1
> 
> Line 2
> The new line is there as expected.
> 
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 12. April 2017 um 20:30:00, Ricardo Parada (rpar...@mac.com 
> ) schrieb:
> 
>> print("Line1\n")
>> print("Line 2")
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ricardo Parada via swift-evolution]

Okay, so maybe we should not strip the trailing newline.

The xml concatenation example in Brent's revised proposal assumes the literal 
includes a trailing newline.

Also, if you do this in Swift:

print("Line1\n")
print("Line 2")

It seems to strip trailing newlines.  So the above actually outputs this with 
no empty line in between them:

Line 1
Line 2

Conclusion: I think it is best to include the trailing newline.  :-)



> On Apr 12, 2017, at 1:52 PM, Adrian Zubarev <adrian.zuba...@devandartist.com> 
> wrote:
> 
> Actually this would be inconsistent. The lines in between the delimiters 
> should always add an implicit new line if not told otherwise with a 
> backslash. If that wouldn’t be the case than you won’t have any precision in 
> the last line you have there.
> 
> Assume you want to concatenate this string:
> 
> foo
> bar   baz
> To do so you’d need extra spaces in your " baz" string, because of the 
> inconsistency. However the constant version I’m suggesting is more precise.
> 
> let myString = """
> foo
> bar   \
> """
>  
> print(myString + "baz")
> The last implicit new line which one would need to escape is a model 
> artifact, but it’s consistent that way.
> 
> The extra new line one would ever need to add manually would be only at the 
> top of a multi-line string.
> 
> // v1:
> 
> """
> 
> foo
> bar\
> """
> 
> // v2:
> """
> \n\
> foo
> bar\
> """
> 
> // v3:
> """
> \nfoo
> bar\
> """
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 12. April 2017 um 19:41:14, Ricardo Parada via swift-evolution 
> (swift-evolution@swift.org <mailto:swift-evolution@swift.org>) schrieb:
> 
>> 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 Adrian's example, I could just have this:
>> 
>> let myReallyLongXMLConstantName = """
>> 
>> 
>> 
>> John Doe
>> XML Developer's Guide
>> Computer
>> 44.95
>> 
>> 
>> """
>> If somebody wants the last line to include a newline at the end, they can 
>> just add a \n at the end or an empty line.
>> 
>> So if I do this:
>> print(myReallyLongXMLConstantName)
>> print("Text right below")
>> It would output this:
>> 
>>  
>>  
>>  
>>  John Doe
>>  XML Developer's Guide
>>  Computer
>>  44.95
>>  
>>  
>> Test right below
>> 
>> Without removing the trailing newline then it would print like this:
>> 
>>  
>>  
>>  
>>  John Doe
>>  XML Developer's Guide
>>  Computer
>>  44.95
>>  
>>  
>> 
>> Test right below
>> 
>> 
>> 
>> 
>>> On Apr 12, 2017, at 12:48 PM, Xiaodi Wu via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> Agree. I prefer the new rules over the old, but considering common use 
>>> cases, stripping the leading and trailing newline makes for a more pleasant 
>>> experience than not stripping either of them.
>>> 
>>> I think that is generally worth prioritizing over a simpler algorithm or 
>>> even accommodating more styles. Moreover, a user who wants a trailing or 
>>> leading newline merely types an extra one if there is newline stripping, so 
>>> no use cases are made difficult, only a very common one is made more 
>>> ergonomic.
>>> On Wed, Apr 12, 2017 at 09:52 Thorsten Seitz via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> > Am 12.04.2017 um 15:40 schrieb Brent Royal-Gordon via swift-evolution 
>>> > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>:
>>> >
>>> > Hey folks,
>>> >
>>> >
>>> > We've revised the proposal again. The main difference: You no longer need 
>>> > an initial newline to enable indentation stri

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

[Ricardo Parada via swift-evolution]

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 Adrian's example, I could just have this:

let myReallyLongXMLConstantName = """



John Doe
XML Developer's Guide
Computer
44.95


"""
If somebody wants the last line to include a newline at the end, they can just 
add a \n at the end or an empty line.

So if I do this:
print(myReallyLongXMLConstantName)
print("Text right below")
It would output this:

 
 
 
 John Doe
 XML Developer's Guide
 Computer
 44.95
 
 
Test right below

Without removing the trailing newline then it would print like this:

 
 
 
 John Doe
 XML Developer's Guide
 Computer
 44.95
 
 

Test right below




> On Apr 12, 2017, at 12:48 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> Agree. I prefer the new rules over the old, but considering common use cases, 
> stripping the leading and trailing newline makes for a more pleasant 
> experience than not stripping either of them.
> 
> I think that is generally worth prioritizing over a simpler algorithm or even 
> accommodating more styles. Moreover, a user who wants a trailing or leading 
> newline merely types an extra one if there is newline stripping, so no use 
> cases are made difficult, only a very common one is made more ergonomic.
> On Wed, Apr 12, 2017 at 09:52 Thorsten Seitz via swift-evolution 
> > wrote:
> > Am 12.04.2017 um 15:40 schrieb Brent Royal-Gordon via swift-evolution 
> > >:
> >
> > Hey folks,
> >
> >
> > We've revised the proposal again. The main difference: You no longer need 
> > an initial newline to enable indentation stripping, and stripping no longer 
> > removes that newline even if it is present. (Adrian Zubarev and I believe 
> > some others argued for this.) We
> 
> Hmm, not sure if I like these changes. I expect that almost all strings won't 
> begin with a newline and a majority won’t end with a newline. The new design 
> would require a leading backslash almost all the time and a trailing 
> backslash often, which is ugly:
> 
> let mystring = "““\
> text text
> text text\
> "““
> 
> -Thorsten
> 
> 
> > disagreed with this at first, but it made more sense as we thought about it 
> > more. There are a few things we like about it:
> >
> >   1. The rules and algorithm are simpler.
> >   2. It accommodates more coding styles.
> >   3. Every non-escaped newline in the literal now creates a 
> > corresponding newline in the resulting string.
> >   4. it's easy to get the old behavior back by backslashing the leading 
> > newline.
> >
> > Unfortunately, I think this precludes stripping the trailing newline by 
> > default, but I think this is ultimately a simpler and better approach than 
> > the previous draft.
> >
> > Other changes:
> >
> >   * We realized we needed to make closing delimiter matching a little 
> > more complicated if we wanted to allow one or two adjacent double-quote 
> > characters that were part of the literal's contents. Oops.
> >   * Tabs aren't actually allowed in ordinary string literals, so we now 
> > explicitly mention that as a difference between the two types.
> >   * We wrote some tests for the prototype (though they haven't been 
> > updated for this new version yet).
> >   * There were some other wording changes, particularly in the 
> > indentation stripping rationale, but nothing that affects the actual design.
> >
> > I understand John is working on a new version of his toolchain so people 
> > can play with the prototype. We hope to have that ready for you all soon.
> >
> > Let us know what you think of the revisions!
> >
> > --
> > Brent Royal-Gordon
> > Architechies
> >
> > ___
> > 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 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org

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

[Ricardo Parada via swift-evolution]

> 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 symbol visibility reasons).  Saying that extensions to a type 
>>> have access to private members if they are in the same module is just as 
>>> arbitrary as limiting it to a single file, and a whole lot less useful from 
>>> the “reasoning about a type” perspective.
>> 
>> I think you misunderstand. We were talking about two extensions of a type, 
>> in a different file from the type, to share private members between 
>> themselves.
>> 
>> Doug Gregor mentioned it during the PR process and we added an example to 
>> disallow it, but in hindsight, I think it should be allowed.
> 
> Ah, you’re saying:
> 
> a.swift:
> struct X {}
> 
> b.swift:
> extension X {
>   private func f() {}
> }
> 
> extension X {
>   func g() { f() }
> }
> 
> If so, then yes, I agree we should accept that.
> 
> -Chris

That would remove the objection I had. It would make the first half and the 
second half of the proposal consistent. ___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ricardo Parada via swift-evolution]

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 swift-evolution 
>  wrote:
> 
> One last pitch, can we allow comments in multi-line strings if the string is 
> broken up by a backslash?
> 
> 
> let myString = """
> text text  
> text text text \ // Comment allowed in the current line here, but not in 
> the line above it
> text text text \ /* this type of comment is fine too */
> text text\// notice whitespace can be ignored
> """
> You might have some interpolation and want to comment around it.
> 
> let foo = """
> bar bar bar
> bar \(x) bar\ // `x` does some magic
> """
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 12. April 2017 um 12:48:57, Adrian Zubarev 
> (adrian.zuba...@devandartist.com) schrieb:
> 
>> Actually I’m fine with such a compromise. Such a model has everything we’ve 
>> asked for, it’s easy, it has both leading and trailing precision and 
>> implicit new lines where needed.
>> 
>> 
>> 
>> -- 
>> Adrian Zubarev
>> Sent with Airmail
>> 
>> Am 12. April 2017 um 12:42:17, Vladimir.S via swift-evolution 
>> (swift-evolution@swift.org) schrieb:
>> 
>>> On 12.04.2017 13:16, 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 I understood correctly what Xiaodi Wu meant in his reply, then we 
>>> >> could simplify
>>> >> the whole multi-line string literal and also remove the need of 
>>> >> disabling the
>>> >> stripping algorithm.
>>> >>
>>> >> We should ban these examples completely:
>>> >>
>>> >> |"""Hello·world!"""|
>>> >>
>>> >
>>> > Being able to use ""“ for single line strings containing lots of " is 
>>> > useful in
>>> > itself and explained in the motivational section of the proposal:
>>> > "Tripled string literals can also do double duty as a syntax for handling 
>>> > short
>>> > string literals with many internal quotation marks“
>>> >
>>> > -Thorsten
>>> 
>>> Yes, I also think the single line string can be very useful and we should 
>>> not
>>> disallow it.
>>> 
>>> But I agree that we should disallow multi-line cases when we have text on 
>>> the same
>>> line with leading or trailing """ because this complicates the mental modal 
>>> and adds
>>> confusion points.
>>> 
>>> I.e. I suggest to allow only two forms:
>>> 1. Single line: """this is "just" text""" (no line end will be inserted)
>>> 2. Multiline, where leading and trailing """ has no text after/before them 
>>> and *all*
>>> the text is in lines *between* triple quotes:
>>> """
>>> first line
>>> second line
>>> """
>>> 
>>> One can use backslash at the line end to emulate all other needed cases. 
>>> Like:
>>> 
>>> """
>>> first line \
>>> second line\
>>> """
>>> 
>>> will produce "first line second line"
>>> 
>>> >
>>> >> |"""Hello↵ world!""" |
>>> >> |"""Hello↵ world!↵ """ |
>>> >> |"""↵ Hello↵ world!""" |
>>> >>
>>> >> Instead an empty multi-line string literal would look like this:
>>> >>
>>> >> |"""↵ """ |
>>> >>
>>> >> To fix the above example you’d need to write it like this:
>>> >>
>>> >> |"""↵ Hello·world!\↵ """ |
>>> >> |"""↵ Hello↵ world!\↵ """ |
>>> >>
>>> >> * Each line in between the delimiters would add implicit new lines if not
>>> >> disabled by a backslash.
>>> >> * The trailing precision is also handled by the backslash.
>>> >> * The indent is handled by the closing delimiter.
>>> >> * It’s easier to learn/teach.
>>> >> * It’s easier to read, because most of the time the line where the 
>>> >> starting
>>> >> delimiter is, is filled with some other code.
>>> >>
>>> >> |let myString = """↵ ⇥ ⇥ Hello↵ ⇥ ⇥ world!\↵ ⇥ ⇥ """ |
>>> >>
>>> >> Now that would be a true multi-line string literal which needs at least 
>>> >> two lines
>>> >> of code. If you’d need a single line literal,|""|is the obvious pick.
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Adrian Zubarev
>>> >> Sent with Airmail
>>> >>
>>> >> Am 12. April 2017 um 02:32:33, Brent Royal-Gordon (br...@architechies.com
>>> >> ) schrieb:
>>> >>
>>> >>>
>>>  On Apr 11, 2017, at 8:08 AM, Adrian Zubarev via swift-evolution
>>>  > wrote:
>>> 
>>>  That’s also the example that kept me thinking for a while.
>>> 
>>>  -
>>> 
>>>  Overall the proposal is a great compromise to some issues I 

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

[Ricardo Parada via swift-evolution]

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 I understood correctly what Xiaodi Wu meant in his reply, then we could 
>> simplify the whole multi-line string literal and also remove the need of 
>> disabling the stripping algorithm.
>> 
>> We should ban these examples completely:
>> 
>> """Hello·world!"""
>> 
> 
> Being able to use ""“ for single line strings containing lots of " is useful 
> in itself and explained in the motivational section of the proposal:
> 
> "Tripled string literals can also do double duty as a syntax for handling 
> short string literals with many internal quotation marks“
> 
> -Thorsten
> 
>> """Hello↵
>> world!"""
>> """Hello↵
>> world!↵
>> """
>> """↵
>> Hello↵
>> world!"""
>> Instead an empty multi-line string literal would look like this:
>> 
>> """↵
>> """
>> To fix the above example you’d need to write it like this:
>> 
>> """↵
>> Hello·world!\↵
>> """
>> """↵
>> Hello↵
>> world!\↵
>> """
>> Each line in between the delimiters would add implicit new lines if not 
>> disabled by a backslash.
>> The trailing precision is also handled by the backslash.
>> The indent is handled by the closing delimiter.
>> It’s easier to learn/teach.
>> It’s easier to read, because most of the time the line where the starting 
>> delimiter is, is filled with some other code.
>> let myString = """↵
>> ⇥  ⇥  Hello↵
>> ⇥  ⇥  world!\↵
>> ⇥  ⇥  """
>> Now that would be a true multi-line string literal which needs at least two 
>> lines of code. If you’d need a single line literal, "" is the obvious pick.
>> 
>> 
>> 
>> 
>> -- 
>> Adrian Zubarev
>> Sent with Airmail
>> 
>> Am 12. April 2017 um 02:32:33, Brent Royal-Gordon (br...@architechies.com) 
>> schrieb:
>> 
>>> 
 On Apr 11, 2017, at 8:08 AM, Adrian Zubarev via swift-evolution 
  wrote:
 
 That’s also the example that kept me thinking for a while.
 
 Overall the proposal is a great compromise to some issues I had with the 
 first version. However I have a few more questions:
 
 Why can’t we make it consistent and let the compiler add a new line after 
 the starting delimiter.
 
 let string = """↵
 Swift↵
 """
 
 // result
 ↵Swift↵
 If one would would the behavior from the proposal it’s really easy to add 
 a backslash after the starting delimiter.
 
 
 let string = """\↵
 Swift\↵
 """
 
 // result
 Swift
 This would be consistent and less confusing to learn.
 
>>> That would mean that code like this:
>>> 
>>> print("""
>>> A whole bunch of 
>>> multiline text
>>> """)
>>> print("""
>>> A whole bunch more 
>>> multiline text
>>> """)
>>> 
>>> Will print (with - to indicate blank lines):
>>> 
>>> -
>>> A whole bunch of
>>> multiline text
>>> -
>>> -
>>> A whole bunch more
>>> multiline text
>>> -
>>> 
>>> This is, to a first approximation, never what you actually want the 
>>> computer to do.
 Can’t we make the indent algorithm work like this instead?
 let string = """\↵
 ↵
 ··content text↵
 """ // Indent starts with the first non space character
 
 // result
 
 ↵
 ··content text↵
 
 The line where the closing delimiter is trims all space chapters and the 
 indent for the whole multi-line string is starting at the point where the 
 first non-space chapters is in that line.
 
>>> We could; I discuss that briefly in the very last section, on alternatives 
>>> to the indentation stripping we specify:
>>> 
>>> • Stripping indentation to match the depth of the least indented line: 
>>> Instead of removing indentation to match the end delimiter, you remove 
>>> indentation to match the least indented line of the string itself. The 
>>> issue here is that, if all lines in a string should be indented, you can't 
>>> use indentation stripping. Ruby 2.3 does this with its heredocs, and 
>>> Python's dedent function also implements this behavior.
>>> 
>>> That doesn't quite capture the entire breadth of the problem with this 
>>> algorithm, though. What you'd like to do is say, "all of these lines are 
>>> indented four columns, so we should remove four columns of indentation from 
>>> each line". But you don't have columns; you have tabs and spaces, and 
>>> they're incomparable because the compiler can't know what tab stops you 
>>> set. So we'd end up calculating a common prefix of whitespace for all lines 
>>> and removing that. But that means, when someone mixes tabs and spaces 
>>> accidentally, you end up stripping an amount of indentation that is 
>>> unrelated to anything visible in your code. We could perhaps emit a 

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

[Ricardo Parada via swift-evolution]

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-evolution 
> <swift-evolution@swift.org> wrote:
> 
> 
> 
> 
>> On Apr 11, 2017, at 8:32 PM, Brent Royal-Gordon via swift-evolution 
>> <swift-evolution@swift.org> 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. :-)
> ___
> 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] [Review] SE-0168: Multi-Line String Literals

[Ricardo Parada via swift-evolution]

> 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. :-)
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ricardo Parada via swift-evolution]

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 the leading newline. "

let str = """My favorite things in life don't cost any money.↵
It's really clear that the most precious resource we all have is time. - 
Steve Jobs"""


If I understand correctly, in this example, the opening delimiter does not end 
its line and the closing delimiter does not begin its line.  Therefore, the 
indentation stripping is not enabled and would yield this:

My favorite things in life don't cost any money.↵
It's really clear that the most precious resource we all have is time. - 
Steve Jobs


I personally do not care if indentation stripping is always enabled.  But after 
having seen all kinds of responses I would not be surprised if someone will ask 
for the ability to turn indentation stripping on/off.   :-)

I think the enabling of the indentation stripping could be relaxed a little bit 
and not require the opening delimiter to end its line.  So for example, it 
would be possible to do this:


let xml = """
 
 
 \(author)
 XML Developer's Guide
 Computer
 44.95
 2000-10-01
 An in-depth look at creating applications with 
XML.
 
 
 """

Notice that here, the opening delimiter does not end its line but the closing 
delimiter does begin its line.  This could produce the following:




John Doe
XML Developer's Guide
Computer
44.95
2000-10-01
An in-depth look at creating applications with XML.




I think Brent did a super awesome job.  The proposal is very detailed with a 
ton of examples. I think it covers just about everything that people have asked 
for.  

Regards,
Ricardo



On Apr 11, 2017, at 1:06 PM, Adrian Zubarev > wrote:

> Can you elaborate a small example please, so I can better understand what you 
> asked for?
> 
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 11. April 2017 um 18:51:45, Ricardo Parada (rpar...@mac.com 
> ) schrieb:
> 
>> 
>> 
>> 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 be consistent and less confusing to learn.
>>> 
>>> Can’t we make the indent algorithm work like this instead?
>>> let string = """\↵
>>> ↵
>>> ··content text↵
>>> """ // Indent starts with the first non space character
>>> 
>>> // result
>>> 
>>> ↵
>>> ··content text↵
>>> 
>>> The line where the closing delimiter is trims all space chapters and the 
>>> indent for the whole multi-line string is starting at the point where the 
>>> first non-space chapters is in that line.
>>> 
>>> What do you think?
>>> 
> 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ricardo Parada via swift-evolution]

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 be consistent and less confusing to learn.
> 
> Can’t we make the indent algorithm work like this instead?
> let string = """\↵
> ↵
> ··content text↵
> """ // Indent starts with the first non space character
> 
> // result
> 
> ↵
> ··content text↵
> 
> The line where the closing delimiter is trims all space chapters and the 
> indent for the whole multi-line string is starting at the point where the 
> first non-space chapters is in that line.
> 
> What do you think?
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ricardo Parada via swift-evolution]

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 extensions within the same file. I said, if you think of the 
type and its extensions as a unit then it makes sense. I can explain that. 

Then it started describing a different behavior among the extensions located in 
a file separate from the file containing the definition of the type. That just 
started a whole debate inside my head and I understand the passionate responses 
on both sides. 

But then I imagined myself explaining this to someone new to Swift and it just 
doesn't seem right. If it becomes convoluted then that's a red flag that it 
does not belong in Swift. 

I agree fileprivate may be ugly to some and it may be more popular than 
private. But I think fileprivate is very clear. I know what it does from its 
name without having to ask. And private behaves the way private works in other 
languages. 

Regards


> On Apr 10, 2017, at 1:35 PM, Tony Allevato via swift-evolution 
>  wrote:
> 
> 
> 
> On Mon, Apr 10, 2017 at 9:49 AM Tino Heth <2...@gmx.de> wrote:
>>> But even outside the generated code use cases, it's nice to just be able to 
>>> implement helpers or additional "convenience" conformances in separate 
>>> files named appropriately (like "Type+Protocol.swift" or 
>>> "Type+Helpers.swift"). I find it makes my codebase easier to navigate.
>> 
>> No doubt about the usefulness of having separate files with extensions here
>> 
>>> If nothing else, nested extensions could save those who actually don't care 
>>> much about such issues from another breaking change in Swift — and imho it 
>>> adds consistency:
>>> We can nest types, so why can't we nest extensions?
>>> 
>>> Because types and extensions are quite different beasts, so something that 
>>> applies to one doesn't necessarily apply to the other.
>> 
>> I don't buy this argument at all without an objective explanation why the 
>> curly braces of extensions should be treated different than the curly braces 
>> of types...
> 
> They shouldn't be. That's why I don't support SE-0169 either, because it 
> would allow extensions to extend the *scope* rather than the *type*, but only 
> within the same file. I think that's fundamentally broken.
> 
> But my comment wasn't about curly braces—it was about types vs. extensions. 
> For example, you can declare local types within a function, but you can't 
> extend a type within a function (nor do I think it would be a good idea).
> 
>  
>> 
>>> I don't think that holds its weight. This feels like another case of "let's 
>>> try to satisfy everyone who's unhappy with some part of Swift visibility by 
>>> changing a completely different feature to make things fall into place", 
>>> which I don't think is a sound motivation or design principle. The example 
>>> you posted in your initial message weaves multiple types/nesting levels 
>>> together in a way that looks *incredibly* difficult to follow/parse to even 
>>> an experienced user of the language.
>> 
>> Did you noticed that I started this example as mockery? In real life, I 
>> would hopefully never nest more than once… and do you think sprinkling parts 
>> of class over the project is easier to follow?
> 
> Depending on the type, yes. I wouldn't sprinkle the *fundamental/core* parts 
> of a type across the project, but if there's some kind of "aside" 
> functionality that doesn't depend on private knowledge of the type, then I 
> find it to be a nice feature to have. It requires me to have reasonable names 
> to my source files, but that's not a significant burden.
> 
>  
>> 
>>> Everyone seems to be striving for a "perfect" level of access control that 
>>> lets individual types/members dictate precisely what other types/members 
>>> can access them. I'm not sure if that perfection is attainable or not, but 
>>> even if it is, I don't think it's something we should strive for. I'd 
>>> rather have a simple visibility model that leaks a little than an air-tight 
>>> model that allows people to write overly complicated code for the sake of 
>>> fine-tuning access.
>> 
>> I had no desire to change the model of Swift 2 — but apparently, others 
>> thought it wasn't sufficient, and I'd rather prefer a conceptually simple 
>> model like nesting over a complicated one with less power.
>> 
>>> Let's remember that the core team has limited resources to implement the 
>>> things we propose, and if I have to choose between, say, serialization, 
>>> reflection, asynchronous constructs, and rehashing visibility levels yet 
>>> again, it's clear to me which one I would want dropped on the floor. I 
>>> don't want perfect to be the enemy of good.
>> 
>> Well, right now, there are several (at least one ;-) proposals that aim for 
>> a 

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

[Ricardo Parada via swift-evolution]

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 swift-evolution 
>  wrote:
> 
> I’m still not sure whether *I* want this. But here’s a proposal anyways: 
> https://gist.github.com/dduan/5017a0b0f0880d014f4ce14c4ca7fb55
> 
>> On Apr 7, 2017, at 12:21 AM, Daniel Duan via swift-evolution 
>>  wrote:
>> 
>> Hi all,
>> 
>> In a discussion about inferring parameter types from default value, Slava 
>> brought up some performance problems caused by type inference for stored 
>> properties in side types:
>> 
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170313/033882.html
>> 
>> Towards the end, the post mentioned that some Swift team members 
>> contemplated requiring types for stored properties in type declarations. I 
>> think this idea deserves some more attention. Hence this last minute 
>> idea-floating.
>> 
>> In addition to solving a performance headache in implementation, there're 
>> always the general benefit of making type declartion more explicit and 
>> readable (clarity for reader should out-weigh pleasure of the author). 
>> Making the
>> language slightly more consistent (we are not inferring types for default 
>> parameter values in function anyways).
>> 
>> The cons for doing this are obvious too: the inference makes the language 
>> feels more friendly and is, undoubtedly, a beloved feature for many. This 
>> would be a source breaking change.
>> 
>> Just thought I'd float the idea to gather some quick reaction. What do y'all 
>> think?
>> 
>> Daniel Duan
>> ___
>> 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
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ricardo Parada via swift-evolution]

On Apr 9, 2017, at 12:29 PM, John Holdsworth via swift-evolution 
> 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.
> 
> Second up, apologies if the proposal is rather vague on details. In some 
> sense this was intentional as I didn’t want to get too bogged down in 
> specifics (and not at all to do with my limitations as a technical writer!)
> 
> I guess we need to build up consensus more slowly by asking the following 
> questions separately so it can be resubmitted rather than giving a binary 
> +/-1 on the proposal as it stands.
> 
> 1) Does Swift need multi-line string literals?

Hi John, I think it is a "nice to have" feature. This feature would enhance 
multi-line string literals by removing some of the hassles such as specifying 
\n in each line, escaping quote characters and the concatenation character for 
each line of text.  But best of all, the string literal would look much better 
in our code.

> 2 ) Is “””long strings””” the way to go subject to a discussion about the 
> precise delimiter

IMHO, I think the use of triple quote has the best feel and look.

I am one of the ones who had proposed several options that included a 
continuation character. I still like the aesthetics of having a continuation 
character, in particular, the quote character. For example:

let xml = """
"
"
"\(author)
"XML Developer's Guide
"Computer
"44.95
"2000-10-01
"An in-depth look at creating applications 
with XML.
"
"

I had proposed that the multi-line string literal would end automatically when 
a line was found without the continuation character. This way when you start 
typing it, the editor would include one line at most.  But I don't know if such 
an algorithm would be challenging for syntax highlighters.  

I liked this option because it provided a visual guide of where each line 
started and found the indent of each line more predictable. But most 
importantly to me, this made the string literal look beautiful within my code.

One criticism of having a continuation character is the effort required adding 
the continuation character to each line. But that was okay with me because 90% 
of the time I typed in my string literal from scratch and indented it properly 
to fit with my other code. 

I rarely ever copied / pasted a multi-line string literal directly into my 
code. Therefore, my goal was never to save typing, but rather to make my 
multi-line string literal look beautiful when surrounded by code.  

I had also proposed to make the continuation character optional and turn off 
the automatic indentation stripping.

It is important not having to escape quotes in the the string literal. Mostly 
because the escaping can make the literal look ugly and a bit harder to read. 

I also considered string interpolation a feature that would be nice to have. We 
already have it in normal string literals and I think It would be a mistake to 
not include it here. 

The only downside to not having a closing """ is that the last line always 
included a newline.  However, we could allow a backslash at the line to escape 
the newline character.  As an alternative, the closing """ could be optionally 
specified in the last line when continuation characters are used.  However, if 
no continuation character was used then the closing """ would be mandatory.

> 3) Is the “magic" leading whitespace removal a good idea to support 
> indentation.

I think that is reasonable. I do consider leading white space removal a highly 
desirable feature. 

> 4) Does the proposal contain sufficient detail to be discussed/implemented

I think the proposal should include more examples and some edge cases that 
illustrate how this feature will work. 

For example, if the last line does not have a newline character then I would 
end my string like this:

let xml = """
 
 
 \(author)
 XML Developer's Guide
 Computer
 44.95
 2000-10-01
 An in-depth look at creating applications 
with XML.
 
 """

What would be the amount of indentation stripped here?  I would expect the 
white space preceding the last line containing the  would be the 
amount of indentation stripped from each line.


> My answer to 1) is obviously yes and I think the discussion has come out 
> about 50/50 so far so lets persevere...
> 
> Trying to fie down 2), a “””long string””” or @“long string”@ or _”long 
> string”_ or #”long string”# is a string literal inside a new delimiter. It 
> would be processed exactly as it 

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

[Ricardo Parada via swift-evolution]

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.

let x = \(Person.mother.age).valueType
let y = \(Person.mother.age.valueType)


It is a subtle difference. 




> On Apr 8, 2017, at 5:47 PM, Haravikk via swift-evolution 
>  wrote:
> 
> 
>> On 8 Apr 2017, at 22:18, BJ Homer via swift-evolution 
>> > wrote:
>> 
>> I love the idea of a leading and trailing backslash. It makes it much easier 
>> to read, and handles the "but what if I want to access a property of a 
>> KeyPath?" case really well.
>> 
>> For example, these two are clearly distinct:
>> 
>>   let x = \Person.mother.age\.valueType
>> 
>>   let y = \Person.mother.age.valueType\
>> 
>> I'm not sure why an 'age' object would have a 'valueType' property, but this 
>> variant makes it easy to handle. Even in cases where no disambiguation is 
>> required, having the trailing backslash makes it much easier to read as I'm 
>> scanning through code.
>> 
>> -BJ
> 
> I think I'd prefer brackets for that case; in your first example that reads 
> to me like an escape of the period character, rather than "this is the end of 
> the key path". Brackets would make this consistent with escaping within 
> strings, like so:
> 
>   let x = \(Person.mother.age).valueType
>   let y = \(Person.mother.age.valueType)
> 
> Which makes sense to me if you consider the backslash in this case being an 
> escape from normal type/variable access. Put another way, normally when you 
> type Person. you're telling Swift "access this type and look for static 
> methods/properties etc.", whereas when you "escape" it you're telling Swift 
> to not to do that, resulting in a key-path instead.
> 
> Maybe it's a stretch, it that makes sense logically to me, plus I think the 
> use of brackets just looks cleaner than another backslash.
> ___
> 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] SE-165: Dictionary & Set Enhancements

[Ricardo Parada via swift-evolution]

Thanks Shawn. 

I understand that part. I asked mostly because Nate mentioned that we cannot 
have a default closure because it would force the use of try even when the 
default closure does not throw. I do t know if that is a current bug or feature 
to allow changing the default in the future to a closure that throws:

>>> https://bugs.swift.org/browse/SR-2979

Thanks. 

> On Apr 6, 2017, at 10:12 PM, Shawn Erickson <shaw...@gmail.com> wrote:
> 
> They rethrow which is IMHO perfect for this. If the closure throws then the 
> outer functions throws (e.g. requires try). This allows folks that 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 
>> <swift-evolution@swift.org> wrote:
>> 
>> 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 
>> sequence,
>> /// using a combining closure to determine the value for any duplicate 
>> keys.
>> init(
>> merging keysAndValues: S,
>> resolvingCollisionsWith combine: (Value, Value) -> Value
>> ) where S.Iterator.Element == Element
>> 
>> /// Merges the key/value pairs in the given sequence into the dictionary,
>> /// using a combining closure to determine the value for any duplicate 
>> keys.
>> mutating func merge(
>> _ other: S,
>> resolvingCollisionsWith combine: (Value, Value) -> Value
>> ) where S.Iterator.Element == Element
>> /// Returns a new dictionary created by merging the key/value pairs in 
>> the
>> /// given sequence into the dictionary, using a combining closure to 
>> determine
>> /// the value for any duplicate keys.
>> func merged(
>> with other: S,
>> resolvingCollisionsWith combine: (Value, Value) -> Value
>> ) -> [Key: Value] where S.Iterator.Element == Element
>> 
>> 
>> 
>>>> On Apr 6, 2017, at 12:51 PM, Nate Cook via swift-evolution 
>>>> <swift-evolution@swift.org> wrote:
>>>> 
>>>>> On Apr 5, 2017, at 9:43 PM, Brent Royal-Gordon via swift-evolution 
>>>>> <swift-evolution@swift.org> wrote:
>>>>> 
>>>>> On Apr 5, 2017, at 5:45 PM, Ben Cohen via swift-evolution 
>>>>> <swift-evolution@swift.org> wrote:
>>>>> 
>>>>>   • What is your evaluation of the proposal?
>>>> 
>>>> (As a meta issue, I'm not sure I like the grab-bag review style; I'm 
>>>> finding this proposal a little bit difficult to navigate.)
>>>> 
>>>> Sequence-based initializer and merging initializer
>>>> 
>>>> Good idea, but I think these two are redundant with each other, and I 
>>>> don't think "merging" is an accurate way to describe what the second one 
>>>> does. (`merging` would suggest to me that it was combining several 
>>>> dictionaries or lists, not combining conflicting elements.) I'd suggest a 
>>>> single initializer along the lines of:
>>>> 
>>>>init(_ keysAndValues: S, correctingConflictsBy 
>>>> resolveConflict: (Value, Value) throws -> Value = { fatalError("Duplicate 
>>>> values \($0) and \($1)") }) rethrows
>>>>where S.Iterator.Element == (key: Key, value: Value)
>>> 
>>> Thanks for all your feedback, Brent! One note on this item in particular—if 
>>> you specify a default argument for a throws/rethrows closure, you have to 
>>> use "try" at the call site even if the default closure argument doesn't 
>>> throw. Modules currently don't promise that default closure arguments don't 
>>> throw, and a default argument could change from non-throwing to throwing in 
>>> a later version of a library.
>>> 
>>> There's a bug tracking the issue here: https://bugs.swift.org/browse/SR-2979
>>> 
>>>> Merging methods
>>>> 
>>>> Good idea, but I'm not a fan of the `mergingValues:` label. I would 
>>>> suggest the same `correctingConflictsBy resolveConflict:` label I 
>>>> suggested for the previous method—possibly including the default value. I 
>>>> also think `merge(_:correctingConflictsBy:)`'s first parameter should be 
>>>&g

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

[Ricardo Parada via swift-evolution]

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 
sequence,
/// using a combining closure to determine the value for any duplicate keys.
init(
merging keysAndValues: S,
resolvingCollisionsWith combine: (Value, Value) -> Value
) where S.Iterator.Element == Element

/// Merges the key/value pairs in the given sequence into the dictionary,
/// using a combining closure to determine the value for any duplicate keys.
mutating func merge(
_ other: S,
resolvingCollisionsWith combine: (Value, Value) -> Value
) where S.Iterator.Element == Element
/// Returns a new dictionary created by merging the key/value pairs in the
/// given sequence into the dictionary, using a combining closure to 
determine
/// the value for any duplicate keys.
func merged(
with other: S,
resolvingCollisionsWith combine: (Value, Value) -> Value
) -> [Key: Value] where S.Iterator.Element == Element



> On Apr 6, 2017, at 12:51 PM, Nate Cook via swift-evolution 
>  wrote:
> 
>> On Apr 5, 2017, at 9:43 PM, Brent Royal-Gordon via swift-evolution 
>> > wrote:
>> 
>>> On Apr 5, 2017, at 5:45 PM, Ben Cohen via swift-evolution 
>>> > wrote:
>>> 
>>> • What is your evaluation of the proposal?
>> 
>> (As a meta issue, I'm not sure I like the grab-bag review style; I'm finding 
>> this proposal a little bit difficult to navigate.)
>> 
>> Sequence-based initializer and merging initializer
>> 
>> Good idea, but I think these two are redundant with each other, and I don't 
>> think "merging" is an accurate way to describe what the second one does. 
>> (`merging` would suggest to me that it was combining several dictionaries or 
>> lists, not combining conflicting elements.) I'd suggest a single initializer 
>> along the lines of:
>> 
>>  init(_ keysAndValues: S, correctingConflictsBy 
>> resolveConflict: (Value, Value) throws -> Value = { fatalError("Duplicate 
>> values \($0) and \($1)") }) rethrows
>>  where S.Iterator.Element == (key: Key, value: Value)
> 
> Thanks for all your feedback, Brent! One note on this item in particular—if 
> you specify a default argument for a throws/rethrows closure, you have to use 
> "try" at the call site even if the default closure argument doesn't throw. 
> Modules currently don't promise that default closure arguments don't throw, 
> and a default argument could change from non-throwing to throwing in a later 
> version of a library.
> 
> There's a bug tracking the issue here: https://bugs.swift.org/browse/SR-2979 
> 
>> Merging methods
>> 
>> Good idea, but I'm not a fan of the `mergingValues:` label. I would suggest 
>> the same `correctingConflictsBy resolveConflict:` label I suggested for the 
>> previous method—possibly including the default value. I also think 
>> `merge(_:correctingConflictsBy:)`'s first parameter should be labeled 
>> `with`, just as the `merged` variant is.
>> 
>> I wonder if we might also want a method that copies the Dictionary, but with 
>> a single key added/removed/changed:
>> 
>>  func withValue(_ value: Value?, forKey key: Key) -> [Key: Value]
>> 
>> Key-based subscript with default value
>> 
>> I like the functionality, but not way this proposal does it. I don't like 
>> having the default value be a labeled parameter to the subscript, because it 
>> isn't used to locate the value. However, I can't come up with a better 
>> syntax without adding language features. What I'd like to do is make it 
>> possible to assign through `??`:
>> 
>>  frequencies[c] ?? 0 += 1
>> 
>> But that would require either that we support `inout` functions, or that 
>> `??` become magic syntax instead of a standard library feature. The former 
>> is not coming in Swift 4 and the latter is less than ideal.
>> 
>> Still, if we would rather have that syntax and we think we'll soon have the 
>> language improvements needed to pull it off, I'd suggest rejecting this 
>> portion of the proposal.
>> 
>> Dictionary-specific map and filter
>> 
>> I am +114 on this. I say that because I have received 114 upvotes on my 
>> Stack Overflow answer explaining how to write a `Dictionary.map` method: 
>> >  
>> >
>> 
>> I agree with the decision not to pass keys to the closures in these methods; 
>> that keeps them simple and 

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

[Ricardo Parada via swift-evolution]

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/conforms-to relationships, no?
> 
> And I agree that such a thing could be considered later and would make the 
> world a better place.
> 
> -Michael
> 
>> On Apr 6, 2017, at 4:21 PM, Brent Royal-Gordon via swift-evolution 
>> > wrote:
>> 
>>> On Apr 6, 2017, at 2:39 PM, Joe Groff via swift-evolution 
>>> > wrote:
>>> 
>>> for key in [\Vector.x, \.y, \.z, \.w] {
>>> a[key] += b[key]
>>> }
>> 
>> Sorry to derail slightly, but I'd love to see a key path type 
>> shorthand—perhaps something like:
>> 
>>  for key: \Vector: Int in [\.x, \.y, \.z, \.w] {
>>  …
>>  }
>> 
>> It's probably something we should defer until we know more about how 
>> frequently people use key paths, though.
>> 
>> -- 
>> Brent Royal-Gordon
>> Architechies
>> 
>> ___
>> 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

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ricardo Parada via swift-evolution]

> 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/proposals/0168-multi-line-string-literals.md
>  
> 
> 
>   • What is your evaluation of the proposal?

+1

>   • Is the problem being addressed significant enough to warrant a change 
> to Swift?

As I had said before, it has to be simple and take care of most cases.  I 
wanted a continuation character but some people expressed being able to 
copy/paste right into the editor without much formatting.  And not having a 
continuation character will make this possible.

I think that using the closing triple quote to control how much indentation to 
remove from the previous lines is good enough.

String interpolation will be supported and I assume escaping of characters too. 
 So if someone wanted to embed a triple quote then they would have to escape 
the first one I'm guessing, ie. \""".  Although I am not that concerned because 
triple quotes is super rare in my use cases.

Being able to include quotes without having to escape them is also good as that 
was one of my main concerns.

>   • Does this proposal fit well with the feel and direction of Swift?

I think it does.

>   • If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?

Well java uses the concatenation.  This would be superior.  Other languages use 
"line 1" then on the next line you start with "line 2", and so on.  This would 
be superior as well because you can copy / paste right into the editor and be 
productive with minor formatting.  It will also allow quotes in the string.

>   • How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
> 

Participated in the discussion and shared my ideas and goals for this feature.


> More information about the Swift evolution process is available at:
> 
> https://github.com/apple/swift-evolution/blob/master/process.md 
> 
> 
> Thank you,
> 
> -Joe
> 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] [Review #2] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[Ricardo Parada via swift-evolution]

Yes but that is a bit different.  Spaces can be used for clarity or breaking up 
a chain into multiple lines maybe.  But, the space is not really part of the 
key path.  I would expect the key path to be typed in without spaces when using 
the special syntax.


> On Apr 6, 2017, at 12:45 PM, Ben Rimmington <m...@benrimmington.com> wrote:
> 
> 
>> On 6 Apr 2017, at 16:29, Ricardo Parada via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> Another thought on the use of single quotes (an possibly the proposed escape 
>> character).  Do you think the closing single quote could be made optional 
>> since key paths cannot have spaces? Or would that be confusing for beginners?
> 
> Key paths can (probably) have spaces:
> 
>   Welcome to Apple Swift version 3.1 (swiftlang-802.0.48 clang-802.0.48).
> 1> Double.nan.isNaN
>   $R0: Bool = true
> 2> Double . nan . isNaN
>   $R1: Bool = true
> 3> Double .nan .isNaN
>   $R2: Bool = true
> 4> Double. nan. isNaN
>   error: extraneous whitespace after '.' is not permitted
>   Double. nan. isNaN
> ^~
> 
>> For example, these two would be equivalent:
>> 
>>let isPuppyPredicate = 'Pet.type == .dog && 'Pet.age < 12
>>let isPuppyPredicate = 'Pet.type' == .dog && 'Pet.age' < 12
>> 
>> Or this:
>> 
>>let isPuppyPredicate = \Pet.type == .dog && \Pet.age < 12
>>let isPuppyPredicate = \Pet.type\ == .dog && \Pet.age\ < 12
>> 
>> You would use the closing character normally when wanting to invoke a method 
>> on the key path object.
>> 
>> Any thoughts?
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ricardo Parada via swift-evolution]

Do you think in the future it might be possible to convert to strings?  

For example, I am imagining a CoreData-like framework on the server (where 
there is no Objective-C), where I would like to get the type of the root object 
and keys forming the path.  That way I can go to an object model, get the 
corresponding entity, and traversed relationships, and destination attribute.  
All that information (table name, table joins for the relationships traversed, 
column names, etc.) would then be used to construct the SQL.



> On Apr 6, 2017, at 12:37 PM, Douglas Gregor <dgre...@apple.com> wrote:
> 
>> 
>> On Apr 6, 2017, at 9:31 AM, Sean Heber <s...@fifthace.com> wrote:
>> 
>> 
>>> On Apr 6, 2017, at 11:19 AM, Douglas Gregor <dgre...@apple.com> wrote:
>>> 
>>>> 
>>>> On Apr 6, 2017, at 8:13 AM, Ricardo Parada via swift-evolution 
>>>> <swift-evolution@swift.org> wrote:
>>>> 
>>>> 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.  
>>> 
>>> The only analogy between strings and key-paths is that the existing Cocoa 
>>> APIs for key-paths use strings. That’s not an analogy to hang language 
>>> syntax on, because it’s relevance will fade quickly. 
>> 
>> Why would it fade quickly? Do we expect the concept of keypaths to go away 
>> over time? If so, why are we even designing a syntax for keypaths?
> 
> The link between key-paths and strings will go away over time. The *only* 
> reason anyone associates strings with keypaths is because Cocoa’s current 
> key-paths are string-based. This proposal makes any string representation of 
> key-paths an implementation detail that could be used for interoperability 
> with Cocoa’s current system. There is no reason for a type-unsafe string 
> representation to ever be in the user model.
> 
> 
>>> The core team discussed single quotes, and decided that we want to save 
>>> them for something in the string/character realm.
>> 
>> Are they to be saved for something specific or is this just because a lot of 
>> languages use single quotes for character literals? Why is this association 
>> any more sacred than an association with Cocoa string keypaths?
> 
> 
> Lots of languages use single quotes for character literals; we may want to 
> bring them back for it.
> 
>   - Doug

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ricardo Parada via swift-evolution]

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 literals:

ERROR at line 6, col 21: single-quoted string literal found, use '"'
let someCharacter = 'a'
^~~
"a"

Based on this, I don't think the use of single quote is a bad idea for Swift's 
smart key paths, IMHO.

But if the core team decides is reserved for something else, the escape 
character would be fine with me.  But I do think the single quote would be 
slightly superior to the escape character.





> On Apr 6, 2017, at 11:35 AM, James Berry via swift-evolution 
>  wrote:
> 
> +1 to this revised proposal.
> 
> I think the backslash is good. Even if it looks a little funny on first 
> blush, I think it’s the best choice. I don’t like other’s suggestion of 
> ‘keypath’, which I think is confusingly string-like: single quotes should be 
> saved for possible string expansions.
> 
> 
>> On Apr 5, 2017, at 4:56 PM, Douglas Gregor via swift-evolution 
>> > wrote:
>> 
>> Hello Swift community,
>> 
>> The second review of SE-0161 "Smart KeyPaths: Better Key-Value Coding for 
>> Swift" begins now and runs through April 9, 2017. The revised proposal is 
>> available here:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md
>>  
>> 
>> 
> 
> 
>> What is your evaluation of the proposal?
> Strong +1. Let’s get this done.
> 
>> 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 feel that this proposal compares to those?
> This is great.
> 
>> How much effort did you put into your review? A glance, a quick reading, or 
>> an in-depth study?
> In-depth.
> 
> ___
> 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] [Review #2] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[Ricardo Parada via swift-evolution]

Another thought on the use of single quotes (an possibly the proposed escape 
character).  Do you think the closing single quote could be made optional since 
key paths cannot have spaces? Or would that be confusing for beginners?

For example, these two would be equivalent:

   let isPuppyPredicate = 'Pet.type == .dog && 'Pet.age < 12
   let isPuppyPredicate = 'Pet.type' == .dog && 'Pet.age' < 12

Or this:

   let isPuppyPredicate = \Pet.type == .dog && \Pet.age < 12
   let isPuppyPredicate = \Pet.type\ == .dog && \Pet.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 
> <swift-evolution@swift.org> wrote:
> 
> 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 
>> <swift-evolution@swift.org> wrote:
>> 
>>>> That's an interesting point. While `\` alone seems acceptable, I think 
>>>> it's unfortunate that we'll have `(\...)` and `\(...)` both in the 
>>>> language.
>>>> Can we maybe consider instead:
>>>> 
>>>>let firstFriendsNameKeyPath = \Person.friends[0].name\
>>> 
>>> 'Single quotes' (i.e. U+0027 APOSTROPHE) are available AFAIK:
>>> 
>>> // Create a key path and use it
>>> let firstFriendsNameKeyPath = 'Person.friends[0].name'
>>> luke[keyPath: firstFriendsNameKeyPath] // "Han Solo"
>>> 
>>> // or equivalently, with type inferred from context
>>> luke[keyPath: '.friends[0].name'] // "Han Solo"
>>> 
>>> // [SE-0042][SR-3550] Unapplied method references
>>> 'String.lowercased()'  // (String) -> String
>>> 'String.lowercased(with:)' // (String, Locale?) -> String
>>> 
>>> Unlike the Lisp-style backtick, an apostrophe would appear on *both* ends 
>>> of the key path (or method reference).
>> 
>> For what it’s worth, I much rather prefer this approach and was going to 
>> suggest it today. In Objective-C, keypaths were just strings so by using a 
>> single tick, they still look *almost* like strings, but now they’re safe and 
>> checked by the compiler - magical.
>> 
>> l8r
>> Sean
>> 
>> ___
>> 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

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ricardo Parada via swift-evolution]

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 
>>> unfortunate that we'll have `(\...)` and `\(...)` both in the language.
>>> Can we maybe consider instead:
>>> 
>>> let firstFriendsNameKeyPath = \Person.friends[0].name\
>> 
>> 'Single quotes' (i.e. U+0027 APOSTROPHE) are available AFAIK:
>> 
>>  // Create a key path and use it
>>  let firstFriendsNameKeyPath = 'Person.friends[0].name'
>>  luke[keyPath: firstFriendsNameKeyPath] // "Han Solo"
>> 
>>  // or equivalently, with type inferred from context
>>  luke[keyPath: '.friends[0].name'] // "Han Solo"
>> 
>>  // [SE-0042][SR-3550] Unapplied method references
>>  'String.lowercased()'  // (String) -> String
>>  'String.lowercased(with:)' // (String, Locale?) -> String
>> 
>> Unlike the Lisp-style backtick, an apostrophe would appear on *both* ends of 
>> the key path (or method reference).
> 
> For what it’s worth, I much rather prefer this approach and was going to 
> suggest it today. In Objective-C, keypaths were just strings so by using a 
> single tick, they still look *almost* like strings, but now they’re safe and 
> checked by the compiler - magical.
> 
> l8r
> Sean
> 
> ___
> 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] [Review #2] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[Ricardo Parada via swift-evolution]

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 character.  For instance:

   let isPuppyPredicate = \Pet.type == .dog && \Pet.age < 12
   let hasPuppiesPredicate = (\Family.pets).any(isPuppyPredicate)
   let familiesWithPuppies = Family.fetch(editingContext, hasPuppiesPredicate)

I don't mind having to use parenthesis sometimes when invoking a method on key 
path for example.

With single quotes it would look like this:

   let isPuppyPredicate = 'Pet.type' == .dog && 'Pet.age' < 12
   let hasPuppiesPredicate = 'Family.pets'.any(isPuppyPredicate)
   let familiesWithPuppies = Family.fetch(editingContext, hasPuppiesPredicate)

And creating orderings for example:

   let orderings = [ 'Order.totalAmount'.desc,  'Order.address.zip'.asc ]



> On Apr 6, 2017, at 9:55 AM, Ben Rimmington via swift-evolution 
>  wrote:
> 
> Re: 
> 
> 
>> On 6 Apr 2017, at 04:13, Xiaodi Wu wrote:
>> 
>>> On Wed, Apr 5, 2017 at 9:21 PM, Ricardo Parada wrote:
>>> 
 On Apr 5, 2017, at 9:41 PM, Brent Royal-Gordon 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 key path for the 
 `name` property of `Person`, then access the key path's `valueType` 
 property". We can solve this by always interpreting it as the former and 
 requiring parentheses for the latter—that is, 
 `(\Person.name).valueType`—but I thought it was worth calling out 
 explicitly.
>>> 
>>> Good point. 
>>> 
>>> I'm thinking about the hypothetical code examples from previous emails:
>>> 
>>>   let isPuppyQualifier = \Pet.type == .dog && \Pet.age < 12
>>>   let familyQualifier = (\Family.pets).contains(where: isPuppyQualifier)
>>>   let familiesWithPuppies = Family.fetch(editingContext, familyQualifier)
>> 
>> That's an interesting point. While `\` alone seems acceptable, I think it's 
>> unfortunate that we'll have `(\...)` and `\(...)` both in the language.
>> Can we maybe consider instead:
>> 
>>  let firstFriendsNameKeyPath = \Person.friends[0].name\
> 
> 'Single quotes' (i.e. U+0027 APOSTROPHE) are available AFAIK:
> 
>   // Create a key path and use it
>   let firstFriendsNameKeyPath = 'Person.friends[0].name'
>   luke[keyPath: firstFriendsNameKeyPath] // "Han Solo"
> 
>   // or equivalently, with type inferred from context
>   luke[keyPath: '.friends[0].name'] // "Han Solo"
> 
>   // [SE-0042][SR-3550] Unapplied method references
>   'String.lowercased()'  // (String) -> String
>   'String.lowercased(with:)' // (String, Locale?) -> String
> 
> Unlike the Lisp-style backtick, an apostrophe would appear on *both* ends of 
> the key path (or method reference).
> 
> -- Ben
> 
> ___
> 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] Pitch: Compound name `foo(:)` for nullary functions

[Ricardo Parada via swift-evolution]

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 swift-evolution 
> > wrote:
> Now that escaping with \ has been proposed for KeyPaths, this makes me wonder 
> whether it would be appropriate to use "\foo()" rather than "foo(_)"/"foo(:)" 
> ?  It still feels a bit strange, as \foo() looks like escaping the result of 
> a call.
> 
> 
> On Sat, Feb 25, 2017 at 1:43 PM, David Hart  > wrote:
> 
>> On 25 Feb 2017, at 00:56, Jordan Rose via swift-evolution 
>> > wrote:
>> 
>> I don't have a good answer for this, but I'll vote against 'foo(:)' because 
>> that's what a lot of people think the name of 'foo(_:)' should be. I'd 
>> rather be able to offer fix-its for that even when you have both 'foo()' and 
>> 'foo(_:)' defined. I'd rather go with 'foo(_)' despite the tiny ambiguity in 
>> pattern contexts.
>> 
>> (I'm personally in favor of killing unapplied function references altogether 
>> in favor of closures, on the grounds that they are overly terse, make 
>> type-checking more complicated, and often lead to retain cycles. Then we'd 
>> only need this for #selector, and it's perfectly unambiguous to use 'foo()' 
>> there. But I wasn't planning to fight that particular battle now, and it is 
>> rather annoying to require the 'as' in the meantime.)
> 
> It is potentially going to be hard to fight that battle. I think a lot of 
> functional/Haskell people love them and would be sad to see them go away (I 
> plead guilty). But it isn’t a well known part of the language so I don’t 
> think the general community would miss it.
> 
>> Jordan
>> 
>> 
>>> On Feb 21, 2017, at 23:05, Jacob Bandes-Storch >> > wrote:
>>> 
>>> Evolutioniers,
>>> 
>>> Compound name syntax — foo(_:), foo(bar:), foo(bar:baz:) — is used to 
>>> disambiguate references to functions. (You might've used it inside a 
>>> #selector expression.) But there's currently no compound name for a 
>>> function with no arguments.
>>> 
>>> func foo() {}  // no compound syntax for this one :(
>>> func foo(_ bar: Int) {}  // foo(_:)
>>> func foo(bar: Int) {}  // foo(bar:)
>>> func foo(bar: String, baz: Double) {}  // foo(bar:baz:)
>>> 
>>> Given these four functions, only the first one has no compound name syntax. 
>>> And the simple reference "let myfn = foo" is ambiguous because it could 
>>> refer to any of the four. A workaround is to specify a contextual type, 
>>> e.g. "let myfn = foo as () -> Void".
>>> 
>>> I filed SR-3550  for this a while 
>>> ago, and there was some discussion in JIRA about it. I'd like to continue 
>>> exploring solutions here and then write up a formal proposal.
>>> 
>>> To kick off the discussion, I'd like to propose foo(:) for nullary 
>>> functions.
>>> 
>>> Advantages:
>>> - the colon marks a clear similarity to the foo(bar:) form when argument 
>>> labels are present.
>>> - cutely parallels the empty dictionary literal, [:].
>>> 
>>> Disadvantages:
>>> - violates intuition about one-colon-per-argument.
>>> - the parallel between #selector(foo(:)) and @selector(foo) is not quite as 
>>> obvious as between #selector(foo(_:)) and @selector(foo:).
>>> 
>>> 
>>> For the sake of discussion, another option would be foo(_). This was my 
>>> original choice, and I like that the number of colons matches the number of 
>>> parameters. However, it's a little less obvious as a function reference. It 
>>> would preclude _ from acting as an actual identifier, and might conflict 
>>> with pattern-matching syntax (although it appears functions can't be 
>>> compared with ~= anyway).
>>> 
>>> 
>>> Looking forward to everyone's bikeshed color ideas,
>>> Jacob
>> 
>> ___
>> 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 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org

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

[Ricardo Parada via swift-evolution]

I saw those too and forgot to point those out. I assumed they were typos. 



> On Apr 6, 2017, at 9:03 AM, Ed Wellbrook <edwellbr...@gmail.com> wrote:
> 
> Apologies if I’ve simply just missed something, but are the trailing right 
> parentheses in the proposed solution intentional? Reading through the code, 
> having loosely followed this discussion, I’m really confused.
> 
> Examples:
> 
> ```
> // create a key path and use it
> let firstFriendsNameKeyPath = \Person.friends[0].name)
> ^ this
> 
> // optional properties 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-evolution 
>> <swift-evolution@swift.org> wrote:
>> 
>> 
>>> On Apr 5, 2017, at 11:13 PM, Xiaodi Wu <xiaodi...@gmail.com> 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 label makes it more obvious, specially when using it with a key 
>> path variable:
>> 
>> let someKeyPath = ...
>> 
>> person[
>> keyPath: someKeyPath]
>> 
>> ___
>> 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] [Pitch] Add an all algorithm to Sequence

[Ricardo Parada via swift-evolution]

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 })
nums.any(matches:  { isEven })
nums.none(matches:  { isEven })

I rarely ever have a need for checking to see if all the elements equal a 
value. It's normally all the elements match a given condition   However if you 
wanted to see if every element is the number nine then:

nums.every { $0 == 9 }
nums.every(matches: { $0 == 9 })

func every(matches condition: (Element) -> Bool) -> Bool
func any(matches condition: (Element) -> Bool) -> Bool
func none(matches condition: (Element) -> Bool) -> Bool



> On Apr 6, 2017, at 8:07 AM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> In JavaScipt they are known as "every" and "includes".
> 
> In C# they are "TrueForAll" and "Exists".
> 
> Not sure why "all" and "contains" is any less consistent.
>> On Thu, Apr 6, 2017 at 05:50 Víctor Pimentel Rodríguez via swift-evolution 
>>  wrote:
>> On Thu, Apr 6, 2017 at 12:44 AM, Jonathan Hull via swift-evolution 
>>  wrote:
>> On that note: ‘containsOnly' is still my favorite by a wide margin.  I know 
>> it is longer than ‘all’, but it’s behavior is much clearer (especially for 
>> those of us who have never used or heard of ‘all’ in other languages), and 
>> it’s relationship with ‘contains’ is also very clear.
>> 
>> Also +1 to containsOnly for this very reason.
>> 
>> In other languages (Python, Ruby, etc) that have an `all` method, they also 
>> have an `any` method, thus maintaining certain consistency.
>> 
>> In the Swift standard library that `any` method is called `contains`, so 
>> `containsOnly` matches nicely that consistency.
>> 
>> -- 
>> Víctor Pimentel
>> ___
>> 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
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ricardo Parada via swift-evolution]

> 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 label makes it more obvious, specially when using it with a key 
path variable:

let someKeyPath = ... 
person[keyPath: someKeyPath]

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ricardo Parada via swift-evolution]

Here's some hypothetical code example.  Let suppose an extension on key paths 
allows us to invoke desc and asc to help create sort orderings.  This is what 
it would look using the two different notations:

// Order by totalAmount descending, then by address.zip ascending
let orderings = [ (\Order.totalAmount).desc,  (\Order.address.zip).asc ]
let orderings = [ \Order.totalAmount\.desc,  \Order.address.zip\.asc ]

The second one saves one character every time you want to invoke a method on 
the key path but I would have to go back and add the left parenthesis, which 
could be a bit annoying as I'm typing these things in, unless the editor were 
to come to the rescue add the left parenthesis automatically somehow.  But 
anyways, I can go with either one.

Still +1 on the proposal.  :-)


> On Apr 5, 2017, at 11:13 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote:
> 
> On Wed, Apr 5, 2017 at 9:21 PM, Ricardo Parada via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> 
>> On Apr 5, 2017, at 9:41 PM, Brent Royal-Gordon via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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 key path for the 
>> `name` property of `Person`, then access the key path's `valueType` 
>> property". We can solve this by always interpreting it as the former and 
>> requiring parentheses for the latter—that is, `(\Person.name).valueType`—but 
>> I thought it was worth calling out explicitly.
> 
> Good point. 
> 
>  I'm thinking about the hypothetical code examples from previous emails:
> 
> 
>let isPuppyQualifier = \Pet.type == .dog && \Pet.age < 12
>let familyQualifier = (\Family.pets).contains(where: isPuppyQualifier)
>let familiesWithPuppies = Family.fetch(editingContext, familyQualifier)
> 
> 
> That's an interesting point. While `\` alone seems acceptable, I think it's 
> unfortunate that we'll have `(\...)` and `\(...)` both in the language.
> Can we maybe consider instead:
> 
>   let firstFriendsNameKeyPath = \Person.friends[0].name\
> 
> 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\])

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ricardo Parada via swift-evolution]

+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-evolution 
>  wrote:
> 
> Hello, Swift community!
> 
> The review of "SE-165: Dictionary & Set Enhancements" begins now and runs 
> through next Tuesday, April 11th. The proposal is available here:
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0165-dict.md 
> 
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> 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/0165-dict.md 
> 
> 
>   Reply text
> 
>   Other replies
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. When writing your review, here are some questions you might want to 
> answer in your review:
> 
>   • 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?
> 
> More information about the Swift evolution process is available at 
> https://github.com/apple/swift-evolution/blob/master/process.md 
> 
> 
> Thank you,
> 
> Ben Cohen
> 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] [Review #2] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[Ricardo Parada via swift-evolution]

> 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 key path for the 
> `name` property of `Person`, then access the key path's `valueType` 
> property". We can solve this by always interpreting it as the former and 
> requiring parentheses for the latter—that is, `(\Person.name).valueType`—but 
> I thought it was worth calling out explicitly.

Good point. 

 I'm thinking about the hypothetical code examples from previous emails:


   let isPuppyQualifier = \Pet.type == .dog && \Pet.age < 12
   let familyQualifier = (\Family.pets).contains(where: isPuppyQualifier)
   let familiesWithPuppies = Family.fetch(editingContext, familyQualifier)

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ricardo Parada via swift-evolution]

+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/proposals/0161-key-paths.md
>  
> 
> 
> Hello Swift community,
> 
> The review of SE-0161 “Smart KeyPaths: Better Key-Value Coding for Swift” ran 
> from March 30...April 5, 2017. The proposal was very well-received *except* 
> that reviewers felt that the #keyPath syntax was far too heavy for this new 
> language construct, and preferred the lighter-weight syntax of the pre-review 
> drafts. This proposal is returned for revision to address the syntax.
> 
> The heavyweight #keyPath syntax was requested by the core team after 
> reviewing earlier drafts, which used a far lighter syntax:
> 
>   // (Rejected) syntax from pre-review drafts
>   let firstFriendsNameKeyPath = Person.friends[0].name
>   print(luke[keyPath: .friends[0].name])
> 
> The core team’s specific concern was that these key path expressions (e.g., 
> Person.friends[0].name) don’t make it sufficiently clear that the actual 
> property accesses are being delayed, and that the contextual cues (“Person." 
> vs. “luke.”) are insufficient to disambiguate for the human reader. Hence, 
> the request for a different (more explicit) syntax.
> 
> Reviewers rightly point out that it is natural for key-paths to use the same 
> syntax as unapplied instance method references, e.g., 
> Person.someInstanceMethod produces a value of some function type with the 
> “Self” type curried, e.g., (Person) -> (param-types) -> result-type. The core 
> team agrees with this sentiment. The core team also felt that Swift’s 
> existing unapplied method references suffer from the same clarity problems as 
> the initial key-path syntax, i.e., that it isn’t sufficiently clear that the 
> actual application of “self” is being delayed.
> 
> The core team has a specific proposal: use the backslash (‘\’) to as a 
> leading indicator for key paths. Specifically,
> 
>   // Proposed syntax for second revision
>   let firstFriendsNameKeyPath = \Person.friends[0].name
>   print(luke[keyPath: \.friends[0].name])
> 
> The backslash is a visual cue that the actual application of this chain of 
> property references is delayed, eliminating ambiguities, yet is still quite 
> lightweight and feels “first-class” in the language.
> 
> The core team felt that, in the future, the backslash should also be used for 
> unapplied instance method references, to match the proposed syntax for key 
> paths and improve clarity for this non obvious feature. This change could be 
> staged in as a revision to the accepted-but-never-implemented SE-0042: 
> Flattening the function type of unapplied method references 
> ,
>  e.g.,
> 
>   // Proposed future syntax for unapplied instance method references
> class Person {
> func instanceMethod(_: String) -> Int { … }
>   }
> 
>   let f1 = Person.instanceMethod   // to-be-deprecated; produces a value 
> of type (Person) -> (String) -> Int
>   let f2 = \Person.instanceMethod  // to-be-introduced via a revised 
> SE-0042: produces a value of type (Person, String) -> Int
> 
> Such an approach gives us a way to stage in SE-0042 and get to eventual 
> consistency between key paths and unapplied instance method references.
> 
>   - Doug
>   Review Manager
> 
> 
> 
> 
> 
> 
> ___
> swift-evolution-announce mailing list
> swift-evolution-annou...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution-announce

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ricardo Parada via swift-evolution]

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 for example. 

// Order by lastName asc, firstName asc
let orderings = Person.lastName.asc().then(.firstName.asc())

Don't know if it would be possible but I think it would be nice to be able to 
do it. The asc() method would create an ascending sort ordering and would 
establish Root as Person.  I wonder if it would be possible to have the then() 
know that Root is person so that its argument can be a key path relative to 
Person.  Or maybe this can be expressed differently if this is not the right 
way. 

Anyways, the sugary syntax looks very attractive IMHO. 

This is what my Java code looks like for something like that:

NSArray orderings = 
Person.LAST_NAME.asc().then(Person.FIRST_NAME.asc());

or this:

NSArray orderings = 
new NSArray<>(
Person.LAST_NAME.asc(),
Person.FIRST_NAME.asc()
);


> On Apr 1, 2017, at 10:24 PM, Brent Royal-Gordon  
> wrote:
> 
> 
>>> 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, familyQualifier)
>>> 
>>> For those unfamiliar with EOF, the editingContext in the code above is an 
>>> EOEditingContext which is analogous to NSManagedObjectContext. 
>> 
>> Theoretically, you could do something like that with this proposal...
>> 
>> struct UnaryPredicate {
>> let evaluate: (Parameter) -> Result
>> }
>> struct BinaryPredicate {
>> let evaluate: (Left, Right) -> Result
>> }
>> 
>> extension KeyPath where Value: Equatable {
>> func equals(_ value: Value) -> UnaryPredicate {
>> return UnaryPredicate { $0[keyPath: self] == value }
>> }
>> func equals(_ other: KP) -> BinaryPredicate> Bool> where KP.Value == Value {
>> return BinaryPredicate { $0[keyPath: self] == $1[keyPath: other] }
>> }
>> }
>> 
>> let isDog = #keypath(Pet, .type).equals(.dog) // UnaryPredicate
>> if isDog.evaluate(somePet) {
>> print(“It’s a dog”)
>> }
>> 
>> let areSameLength = #keypath(Array, 
>> .count).equals(#keypath(Array, .count))
>> // BinaryPredicate
>> if areSameLength.evaluate([1,2,3], [“a”, “b”, “c”]) {
>> print(“same lengths”)
>> }
> 
> 
> You guys aren't thinking big enough.
> 
>   // This implementation is closure-based because it's too complex for an 
> email even *with* 
>   // generics system upgrades. Without type system upgrades, things get 
> *really* complicated, 
>   // though probably still tractable.
>   typealias Predicate = (Element) -> Bool
>   
>   func ==  (lhs: KeyPath, rhs: 
> Value) -> Predicate {
>   return { $0[keyPath: lhs] == rhs }
>   }
>   
>   func <  (lhs: KeyPath, rhs: 
> Value) -> Predicate {
>   return { $0[keyPath: lhs] < rhs }
>   }
> 
>   func && (lhs: Predicate, rhs: Predicate) -> 
> Predicate {
>   return { lhs($0) && rhs($0) }
>   }
> 
>   extension KeyPath where Value: Collection {
>   func contains(where predicate: Predicate) -> 
> Predicate {
>   return { $0.contains(where: predicate) }
>   }
>   }
> 
> That gives you:
> 
>   let isPuppyQualifier = #keyPath(Pet, .type) == .dog && #keyPath(Pet, 
> .age) < 12
>   let familyQualifier = #keyPath(Family, .pets).contains(where: 
> isPuppyQualifier)
>   let familiesWithPuppies = Family.fetch(editingContext, familyQualifier)
> 
> Or, in one line with a more sugary syntax:
> 
>   let familiesWithPuppies = Family.fetch(editingContext, 
> (.pets).contains(where: .type == .dog && .age < 12))
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ricardo Parada via swift-evolution]

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 <abri...@mac.com> wrote:
> 
> Perhaps
> 
> allMembersMatch()
> 
> or
> 
> everyMemberMatches()
> 
> This reads well in use.
> 
> On 2017-04-02, 6:18 PM, "Ricardo Parada via swift-evolution" 
> <swift-evolution-boun...@swift.org on behalf of swift-evolution@swift.org> 
> wrote:
> 
>or perhaps containsOnly()
>or maybe allMatch()
>or membersMatch()
> 
>:-)
> 
>Sent from my iPhone
> 
>> On Apr 2, 2017, at 1:57 AM, Rien via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> 
>> 
>>> On 02 Apr 2017, at 07:51, Karl Wagner via swift-evolution 
>>> <swift-evolution@swift.org> 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, 3].onlyContains { $0 < 3 } // false
>>> 
>>> - Karl
>> 
>> IMO, we have a winner!
>> 
>> Rien.
>> 
>>> 
>>>> On 1 Apr 2017, at 10:47, Xiaodi Wu via swift-evolution 
>>>> <swift-evolution@swift.org> wrote:
>>>> 
>>>> 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 <brandon...@gmail.com> 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: )
>>>> 
>>>> Well, if we're going to go full stdlib naming guidelines, shouldn't they 
>>>> be--
>>>> 
>>>> ```
>>>> areAll(equalTo:)
>>>> areAll(matching:)
>>>> ```
>>>> 
>>>>> 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 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 should be question-like?
>>>>>> 
>>>>>> Suggesting: `membersSatisfy(condition:)` or `allSatisfy(condition:)` or 
>>>>>> maybe even just `satisfies(condition:)`
>>>>>> The question-like modifier/verb is necessary to suggest a Bool and IMO 
>>>>>> not a needless word.
>>>>>> 
>>>>>> Regards,
>>>>>> Will Stanton
>>>>>> 
>>>>>>> On Mar 31, 2017, at 11:28, Ben Cohen via swift-evolution 
>>>>>>> <swift-evolution@swift.org> wrote:
>>>>>>> 
>>>>>>> Hopefully non-controversial, aside from the naming of the method and 
>>>>>>> arguments, about which controversy abounds
>>>>>> 
>>>>>> ___
>>>>>> 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
>>>>> 
>>>>> 
>>>>> 
>>>>> -- 
>>>>> Brandon
>>>> 
>>>> ___
>>>> 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
>>> 
>>> ___
>>> 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
>___
>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] multi-line string literals.

[Ricardo Parada via swift-evolution]

Why would backslashes at the end of each line be a nice idea?

Sent from my iPhone

> On Apr 3, 2017, at 2:44 PM, Paweł Wojtkowiak via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> I think that there's nothing wrong with two "tools" for the same task in this 
> case. Multiline strings look better in the code and are easier to read and 
> can serve many purposes. By reading different texts from swift dev team I 
> feel like this is something the language was designed with in mind. They're 
> also easier to type and it needn't neccessarily be a string presented to the 
> user. 
> 
> Lets say I want a simple json literal for testing purposes - reading from a 
> file takes much more effort comparing to inserting it directly in the code. 
> Taking out every new line character makes it hard to read, and inserting 
> quotes and pluses every line both needs extra effort and also decreases 
> readability. Adding it as a multiline string would make a perfect solution 
> for this to me.
> 
> There are so many other cases where this could be useful too. I like how 
> python has the """ and I think this would be a good direction to go, although 
> this is true that python uses indentation in a different way, so I think 
> backslashes at the end of each line would be a nice idea - this is still 
> better than concatenating each line with " and +, and would have the least 
> readability impact. Also, it could be treated as a literal and be evaluated 
> at compile time.
> 
>> I just checked with -O and without and was surprised to find that `let x = 
>> "abc" + "def" + "ghi"` wasn't collapsed into a single string literal 
>> "abcdefghi" in the generated assembly code. Maybe it's more difficult than 
>> it is in some other languages because of operator overloads and different 
>> kinds of text literals (strings, extended grapheme clusters, Unicode 
>> scalars)?
>> 
>> Regardless of the reasons, a separate syntax isn't the right way to achieve 
>> this optimization—the compiler should just do it automatically. Like 
>> Ricardo, "multi-line string literals" should be reserved for string literals 
>> that include the newline characters that are used to break them up in 
>> source. The idea of supporting something like the Python example above just 
>> provides two ways to do the same thing, which I don't think we really need.
>> 
>> 
>>> On Mon, Apr 3, 2017 at 8:18 AM Ricardo Parada via swift-evolution 
>>> <swift-evolution@swift.org> wrote:
>>> 
>>> I would think that the concatenation would get resolved at runtime, unless 
>>> the compiler gets smart about it.  But either way I do not see it as a 
>>> problem.  The reason is that I don't remember ever worrying about the 
>>> performance of concatenating a few lines of text.  :-)
>>> 
>>> Thanks
>>> 
>>> 
>>>> On Apr 3, 2017, at 11:13 AM, Adrian Zubarev 
>>>> <adrian.zuba...@devandartist.com> wrote:
>>>> 
>>>> To me a literal a single entity which is solved 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).
>>>> 
>>>> Please correct me if I’m wrong here.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> -- 
>>>> Adrian Zubarev
>>>> Sent with Airmail
>>>> 
>>>> Am 3. April 2017 um 17:10:36, Ricardo Parada (rpar...@mac.com) schrieb:
>>>> 
>>>>> 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 
>>>>>> <swift-evolution@swift.org> wrote:
>>>>>> 
>>>>>> 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 
>>>>>>> <adrian.zuba...@devandartist.com> wrote:
>>>>>>> 
>>>>>>> What I was trying to say is that by automatically

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

[Ricardo Parada via swift-evolution]

I would think that the concatenation would get resolved at runtime, unless the 
compiler gets smart about it.  But either way I do not see it as a problem.  
The reason is that I don't remember ever worrying about the performance of 
concatenating a few lines of text.  :-)

Thanks


> On Apr 3, 2017, at 11:13 AM, Adrian Zubarev <adrian.zuba...@devandartist.com> 
> wrote:
> 
> To me a literal a single entity which is solved 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).
> 
> Please correct me if I’m wrong here.
> 
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 3. April 2017 um 17:10:36, Ricardo Parada (rpar...@mac.com 
> <mailto:rpar...@mac.com>) schrieb:
> 
>> 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 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> 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 
>>>> <adrian.zuba...@devandartist.com <mailto:adrian.zuba...@devandartist.com>> 
>>>> 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.
>>>> 
>>>> // In your model this would be equivalent
>>>> let s1 = "\n\n\n"
>>>> let s2 = """
>>>> " // However in my model this is an empty string and should be banned
>>>> "
>>>> """ // That's also an empty string, but it that case it indicates the 
>>>> end of the multi lined string
>>>> I dislike the tradeoff of precision for laziness.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> -- 
>>>> Adrian Zubarev
>>>> Sent with Airmail
>>>> 
>>>> Am 3. April 2017 um 16:29:44, Ricardo Parada (rpar...@mac.com 
>>>> <mailto:rpar...@mac.com>) schrieb:
>>>> 
>>>>> By the way, the multi-line string should allow \n\n, or as many as you 
>>>>> may want to throw in there.  I don't see a problem with that.
>>>>> 
>>>> 
>>>> 
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org <mailto: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] multi-line string literals.

[Ricardo Parada via swift-evolution]

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 
> <swift-evolution@swift.org> wrote:
> 
> 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 <adrian.zuba...@devandartist.com 
>> <mailto:adrian.zuba...@devandartist.com>> 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.
>> 
>> // In your model this would be equivalent
>> let s1 = "\n\n\n"
>> let s2 = """
>> " // However in my model this is an empty string and should be banned
>> "
>> """ // That's also an empty string, but it that case it indicates the 
>> end of the multi lined string
>> I dislike the tradeoff of precision for laziness.
>> 
>> 
>> 
>> 
>> -- 
>> Adrian Zubarev
>> Sent with Airmail
>> 
>> Am 3. April 2017 um 16:29:44, Ricardo Parada (rpar...@mac.com 
>> <mailto:rpar...@mac.com>) schrieb:
>> 
>>> By the way, the multi-line string should allow \n\n, or as many as you may 
>>> want to throw in there.  I don't see a problem with that.
>>> 
>> 
>> 
> 
> ___
> 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] multi-line string literals.

[Ricardo Parada via swift-evolution]

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 separated by a new line 
character.  It's just like when you look at a text file in the editor and you 
don't see the \n at the end of each line.  You just see multiple lines of text. 
 Same philosophy applies here, but with some useful features such as being able 
to use escape \, interpolation and quotes mainly.

The continuation character serves as a visual guide of the beginning of each 
line and to help you align/indent the multiple lines of text.

I was proposing that the multi-line string literal automatically ends when 
there is no continuation character on the next line.  But it could also use the 
same one that was used to start it, either """ or "M.

I am sure we'll find a hole in every proposed solution, but I think the one 
that takes care of 99% of the cases should be the one.

Regards


> On Apr 3, 2017, at 10:44 AM, Adrian Zubarev  
> wrote:
> 
> IMHO this is what multi-lined strings are meant for in first place, for 
> better code readability without precision tradeoffs. You’re not expecting 
> multi-lined chained methods to do something else as they’re meant for. We’re 
> allowing multi lines there for readability not for more functionality.
> 
> That’s why I disagree that multi-line strings should add new lines 
> automatically to the string.
> 
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 3. April 2017 um 16:33:05, Ricardo Parada (rpar...@mac.com 
> ) schrieb:
> 
>> let veryLongString2 = "word word word" +
>> "word word word" +
>>   "word word word"
>> 
> 
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ricardo Parada via swift-evolution]

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.
> 
> // In your model this would be equivalent
> let s1 = "\n\n\n"
> let s2 = """
> " // However in my model this is an empty string and should be banned
> "
> """ // That's also an empty string, but it that case it indicates the end 
> of the multi lined string
> I dislike the tradeoff of precision for laziness.
> 
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 3. April 2017 um 16:29:44, Ricardo Parada (rpar...@mac.com 
> ) schrieb:
> 
>> By the way, the multi-line string should allow \n\n, or as many as you may 
>> want to throw in there.  I don't see a problem with that.
>> 
> 
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ricardo Parada via swift-evolution]

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 
> <swift-evolution@swift.org> wrote:
> 
> 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 allow \n\n, or as many as you may 
> want to throw in there.  I don't see a problem with that.
> 
> 
> 
>> On Apr 3, 2017, at 10:23 AM, Adrian Zubarev <adrian.zuba...@devandartist.com 
>> <mailto:adrian.zuba...@devandartist.com>> wrote:
>> 
>> At quick glance I disagree with (4). If your current string would contain 
>> something like "\n\n" would you really use another empty line with a single 
>> unescaped quote? If you’re not, you’ll end up adding a single \n, but that 
>> on the other than would be strange if you add it at the end of the line.
>> 
>> Multi-lined strings should not be abused for adding new lines to the string 
>> itself, however I’m fine with allowing single quotes without escaping them. 
>> 
>> If we’d really go that path then I still could not format some really long 
>> hardcoded text for code readability in a multi lined string, just because of 
>> the fact that it will alter my original string by automatically adding new 
>> line characters.
>> 
>> let veryLongString1 = "word word word … word word word"
>> 
>> let veryLongString2 = """word word word  
>> word word word
>> …
>> word word word
>> word word word"""
>>  
>> // Logically that string should be the same, however during the  
>> // automatic new lines we'll get this
>> 
>> veryLongString1 == veryLongString2 // => false
>> What has the multi lined string solved here? Nothing.
>> 
>> 
>> 
>> 
>> -- 
>> Adrian Zubarev
>> Sent with Airmail
>> 
>> Am 3. April 2017 um 16:00:53, Ricardo Parada (rpar...@mac.com 
>> <mailto:rpar...@mac.com>) schrieb:
>> 
>>> 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 have a continuation character
>>> 6. Keep it simple
>>> 
>>> Something like this:
>>> 
>>> let xml = M"
>>>"
>>>" 
>>>" \(author)
>>>" 
>>>"
>>> Or maybe this:
>>> 
>>> let xml = """
>>> "
>>> " 
>>> " \(author)
>>> " 
>>> "
>>> In the first example the multiline literal is started with M".  In the 
>>> second example it starts with three double quotes """.  I really have no 
>>> preference.  In both examples there is no need to have a \ or \n at the end 
>>> of the line.
>>> 
>>> You can have quote characters in the string, including double quotes as 
>>> shown by empty="".  You can have interpolation, i.e. \(author). 
>>> 
>>> You have a continuation character which helps as a visual guide and as a 
>>> marker for the beginning of each line.
>>> 
>>> The multi string literal ends when there are no more continuation 
>>> characters.
>>> 
>>> 
>>> 
>>>> On Apr 3, 2017, at 3:01 AM, Adrian Zubarev via swift-evolution 
>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>> 
>>>> Hello Swift community,
>>>> 
>>>> on Github there is a PR for this proposal, but I couldn’t find any up to 
>>>> date thread, so I’m going to start by replying to the last message I 
>>>> found, without the last content.
>>>> 
>>>> I really like where this proposal is going, and my personal preference are 
>>>

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

[Ricardo Parada via swift-evolution]

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 allow \n\n, or as many as you may want 
to throw in there.  I don't see a problem with that.



> On Apr 3, 2017, at 10:23 AM, Adrian Zubarev  
> wrote:
> 
> At quick glance I disagree with (4). If your current string would contain 
> something like "\n\n" would you really use another empty line with a single 
> unescaped quote? If you’re not, you’ll end up adding a single \n, but that on 
> the other than would be strange if you add it at the end of the line.
> 
> Multi-lined strings should not be abused for adding new lines to the string 
> itself, however I’m fine with allowing single quotes without escaping them. 
> 
> If we’d really go that path then I still could not format some really long 
> hardcoded text for code readability in a multi lined string, just because of 
> the fact that it will alter my original string by automatically adding new 
> line characters.
> 
> let veryLongString1 = "word word word … word word word"
> 
> let veryLongString2 = """word word word  
> word word word
> …
> word word word
> word word word"""
>  
> // Logically that string should be the same, however during the  
> // automatic new lines we'll get this
> 
> veryLongString1 == veryLongString2 // => false
> What has the multi lined string solved here? Nothing.
> 
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 3. April 2017 um 16:00:53, Ricardo Parada (rpar...@mac.com 
> ) schrieb:
> 
>> 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 have a continuation character
>> 6. Keep it simple
>> 
>> Something like this:
>> 
>> let xml = M"
>>"
>>" 
>>" \(author)
>>" 
>>"
>> Or maybe this:
>> 
>> let xml = """
>> "
>> " 
>> " \(author)
>> " 
>> "
>> In the first example the multiline literal is started with M".  In the 
>> second example it starts with three double quotes """.  I really have no 
>> preference.  In both examples there is no need to have a \ or \n at the end 
>> of the line.
>> 
>> You can have quote characters in the string, including double quotes as 
>> shown by empty="".  You can have interpolation, i.e. \(author). 
>> 
>> You have a continuation character which helps as a visual guide and as a 
>> marker for the beginning of each line.
>> 
>> The multi string literal ends when there are no more continuation characters.
>> 
>> 
>> 
>>> On Apr 3, 2017, at 3:01 AM, Adrian Zubarev via swift-evolution 
>>> > wrote:
>>> 
>>> Hello Swift community,
>>> 
>>> on Github there is a PR for this proposal, but I couldn’t find any up to 
>>> date thread, so I’m going to start by replying to the last message I found, 
>>> without the last content.
>>> 
>>> I really like where this proposal is going, and my personal preference are 
>>> *continuation quotes*. However the proposed solution is still not perfect 
>>> enough for me, because it still lacks of precise control about the trailing 
>>> space characters in each line of a multi-line string.
>>> 
>>> Proposed version looks like this:
>>> 
>>> let xml = "
>>> "
>>> "
>>> "\(author)
>>> "XML Developer's Guide
>>> "Computer
>>> "44.95
>>> "2000-10-01
>>> "An in-depth look at creating applications with 
>>> XML.
>>> "
>>> "
>>> ""
>>> I would like to pitch an enhancement to fix the last tiny part by adding 
>>> the escaping character ‘' to the end of each line from 1 to (n - 1) of the 
>>> n-lined string. This is similar to what Javascript allows us to do, except 
>>> that we also have precise control about the leading space character through 
>>> ’"’.
>>> 
>>> The proposed version will become this:
>>> 
>>> let xml = "\   
>>> "\ // If you need you can comment here
>>> "\
>>> "\(author)\
>>> "XML Developer's Guide\
>>> "Computer\
>>> "44.95\
>>> "2000-10-01\
>>> "An in-depth look at creating applications with 
>>> XML.\
>>> "\
>>> "\
>>> ""
>>> Here is another example:
>>> 
>>> let multilineString: String = "123__456__\ // indicates there is another 
>>> part of the string on the next line
>>>   "__789_\ 

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

[Ricardo Parada via swift-evolution]

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 swift-evolution 
>  wrote:
> 
>> 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 never 
> "accidentally" use the feature, and that we could do a lot better.
> 
> But let's not throw the baby out with the bathwater. This is an *excellent* 
> proposal which addresses a real pain point for Swift users in a way that's 
> far better than not only the status quo, but any design Objective-C could 
> have offered. The only problem is that the syntax is ugly, and we can always 
> sugar it up later, once the community and core team are more comfortable with 
> the feature.
> 
> (However, I will make one last-ditch syntax suggestion: 
> `#keyPath(.pets.first)`, where the generic parameter list can be 
> omitted when it can be inferred from context. I think juxtaposing `<>` and 
> `()` is clearer than a comma followed by a dot.)
> 
>>  • Is the problem being addressed significant enough to warrant a change 
>> to Swift?
> 
> How many "Swift isn't dynamic" blog posts have we all seen? This begins to 
> address their concerns.
> 
> How many code generation solutions have people come up with for lenses? This 
> lets us get rid of them *and* it's more efficient.
> 
> How many classes inherit from `NSObject` solely for introspection? This will 
> let some of those convert to native Swift classes.
> 
> Yes, it's a very significant problem.
> 
>>  • Does this proposal fit well with the feel and direction of Swift?
> 
> Yes; the lack of a property equivalent to unbound methods has always been a 
> gaping hole in the language, the clever type design is particularly Swifty. I 
> don't like the `#keyPath` part of the syntax, but the property/subscript 
> chain with optional chaining is super-Swifty as well. 
> 
>>  • If you have used other languages or libraries with a similar feature, 
>> how do you feel that this proposal compares to those?
> 
> In most respects, this is vastly superior to Objective-C KVC. I've never used 
> another language's lenses in anger, but I'm familiar with the theory of them, 
> and this proposal seems like a better solution than those too.
> 
>>  • How much effort did you put into your review? A glance, a quick 
>> reading, or an in-depth study?
> 
> Does talking about it on the list a lot count?
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> 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] multi-line string literals.

[Ricardo Parada via swift-evolution]

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 have a continuation character
6. Keep it simple

Something like this:

let xml = M"
   "
   " 
   " \(author)
   " 
   "
Or maybe this:

let xml = """
"
" 
" \(author)
" 
"
In the first example the multiline literal is started with M".  In the second 
example it starts with three double quotes """.  I really have no preference.  
In both examples there is no need to have a \ or \n at the end of the line.

You can have quote characters in the string, including double quotes as shown 
by empty="".  You can have interpolation, i.e. \(author). 

You have a continuation character which helps as a visual guide and as a marker 
for the beginning of each line.

The multi string literal ends when there are no more continuation characters.



> On Apr 3, 2017, at 3:01 AM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> on Github there is a PR for this proposal, but I couldn’t find any up to date 
> thread, so I’m going to start by replying to the last message I found, 
> without the last content.
> 
> I really like where this proposal is going, and my personal preference are 
> *continuation quotes*. However the proposed solution is still not perfect 
> enough for me, because it still lacks of precise control about the trailing 
> space characters in each line of a multi-line string.
> 
> Proposed version looks like this:
> 
> let xml = "
> "
> "
> "\(author)
> "XML Developer's Guide
> "Computer
> "44.95
> "2000-10-01
> "An in-depth look at creating applications with 
> XML.
> "
> "
> ""
> I would like to pitch an enhancement to fix the last tiny part by adding the 
> escaping character ‘' to the end of each line from 1 to (n - 1) of the 
> n-lined string. This is similar to what Javascript allows us to do, except 
> that we also have precise control about the leading space character through 
> ’"’.
> 
> The proposed version will become this:
> 
> let xml = "\  
> "\ // If you need you can comment here
> "\
> "\(author)\
> "XML Developer's Guide\
> "Computer\
> "44.95\
> "2000-10-01\
> "An in-depth look at creating applications with 
> XML.\
> "\
> "\
> ""
> Here is another example:
> 
> let multilineString: String = "123__456__\ // indicates there is another part 
> of the string on the next line
>   "__789_\ // aways starts with `"` and ends 
> with either `\` or `"`
>   "_0_" // precise control about pre- and 
> post-space-characters
> 
> let otherString = "\(someInstance)\ /* only comments are allowed in between 
> */ "text \(someOtherInstance) text"
> This is simply continuation quotes combined with backslash concatenation.
> 
> 
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> 
> ___
> 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] [Pitch] Add an all algorithm to Sequence

[Ricardo Parada via swift-evolution]

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 simple and go with:
>> 
>> onlyContains(_ element:)
>> onlyContains(_ matching:)
>> 
>> [9, 9, 9, 9, 9].onlyContains(9) // true
>> [1, 2, 3, 2, 3].onlyContains { $0 < 3 } // false
>> 
>> - Karl
> 
> IMO, we have a winner!
> 
> Rien.
> 
>> 
>>> On 1 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 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: )
>>> 
>>> Well, if we're going to go full stdlib naming guidelines, shouldn't they 
>>> be--
>>> 
>>> ```
>>> areAll(equalTo:)
>>> areAll(matching:)
>>> ```
>>> 
 On Sat, Apr 1, 2017 at 12:36 AM, David Hart via swift-evolution 
  wrote:
 
 
> 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 should be question-like?
> 
> Suggesting: `membersSatisfy(condition:)` or `allSatisfy(condition:)` or 
> maybe even just `satisfies(condition:)`
> The question-like modifier/verb is necessary to suggest a Bool and IMO 
> not a needless word.
> 
> Regards,
> Will Stanton
> 
>> On Mar 31, 2017, at 11:28, Ben Cohen via swift-evolution 
>>  wrote:
>> 
>> Hopefully non-controversial, aside from the naming of the method and 
>> arguments, about which controversy abounds
> 
> ___
> 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
 
 
 
 -- 
 Brandon
>>> 
>>> ___
>>> 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
>> 
>> ___
>> 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
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ricardo Parada via swift-evolution]

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 Apr 2, 2017, at 6: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 likely bail out as soon as a single item failed the 
>> test; there is no guarantee that each item would be visited, so iteration is 
>> an incorrect mental model.
>> 
>> In Python, this is just called 'all()'. (There is a corresponding 'any()'.) 
>> We could follow the example of 'filter(_ isIncluded:)', which has a in 
>> internal parameter name for documentation, but takes no parameter at the 
>> call site; this might look like 'all(_ predicate:)'. Or we could follow the 
>> example of 'drop(while:)' and do 'all(test:)'. (And with trailing closure 
>> syntax, this would simply become 'all' (e.g.  'let readyToGo = 
>> collection.all { $0.isReady }'.
>> 
>> If a more explicit base name is desired, I suggest 'allPass(test:)'.
>> 
>> -BJ
>> 
>>> On Apr 2, 2017, at 3:17 AM, Richard Wei via swift-evolution 
>>>  wrote:
>>> 
>>> `withoutException` sounds confusing to me. And it’ll potentially make a 
>>> Swift newcomer think it has something to do with runtime exceptions.
>>> 
>>> IMO `forAll(_:)` is the best name. It looks logically, quantificationally 
>>> clear. With regard to the possible confusion w/ `forEach`, the “each" in 
>>> `forEach` conveys the sense of iteration, while the “all” in `forAll` 
>>> conveys both iteration and conjunction.
>>> 
>>> -Richard
>>> 
 On Apr 2, 2017, at 00:05, Robert Bennett via swift-evolution 
  wrote:
 
 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 their purpose clear, and even make clear what happens for an empty 
 Collection.
 
 Other options that come to mind that I am less enthusiastic about:
 
 nums.every(satisfies: isEven) / nums.every { isEven($0) }
 nums.entirely(isEven) / nums.entirely { isEven($0) }
 ___
 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
>> ___
>> 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
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ricardo Parada via swift-evolution]

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 likely bail out as soon as a single item failed the 
> test; there is no guarantee that each item would be visited, so iteration is 
> an incorrect mental model.
> 
> In Python, this is just called 'all()'. (There is a corresponding 'any()'.) 
> We could follow the example of 'filter(_ isIncluded:)', which has a in 
> internal parameter name for documentation, but takes no parameter at the call 
> site; this might look like 'all(_ predicate:)'. Or we could follow the 
> example of 'drop(while:)' and do 'all(test:)'. (And with trailing closure 
> syntax, this would simply become 'all' (e.g.  'let readyToGo = collection.all 
> { $0.isReady }'.
> 
> If a more explicit base name is desired, I suggest 'allPass(test:)'.
> 
> -BJ
> 
>> On Apr 2, 2017, at 3:17 AM, Richard Wei via swift-evolution 
>>  wrote:
>> 
>> `withoutException` sounds confusing to me. And it’ll potentially make a 
>> Swift newcomer think it has something to do with runtime exceptions.
>> 
>> IMO `forAll(_:)` is the best name. It looks logically, quantificationally 
>> clear. With regard to the possible confusion w/ `forEach`, the “each" in 
>> `forEach` conveys the sense of iteration, while the “all” in `forAll` 
>> conveys both iteration and conjunction.
>> 
>> -Richard
>> 
>>> On Apr 2, 2017, at 00:05, Robert Bennett via swift-evolution 
>>>  wrote:
>>> 
>>> 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 their purpose clear, and even 
>>> make clear what happens for an empty Collection.
>>> 
>>> Other options that come to mind that I am less enthusiastic about:
>>> 
>>> nums.every(satisfies: isEven) / nums.every { isEven($0) }
>>> nums.entirely(isEven) / nums.entirely { isEven($0) }
>>> ___
>>> 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
> ___
> 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] [Draft] Dictionary & Set Enhancements

[Ricardo Parada via swift-evolution]

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

// These two would be equivalent to passing last(_:_:) function
let newDict = dict1.merged(with: dict2) 
let newDict = dict1.merged(with: dict2) { $1 }  

If someone wanted to do what first(_:_:) would do, or some other algorithm then 
it would be quite simple, wouldn't it?  For example:

// This would be equivalent to passing in the first(_:_) function
let newDict = dict1.merged(with: dict2) { $0 }  

// Combine values of common keys by adding them
let newDict = dict1.merged(with: dict2) { $0 + $1 } 





> 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/natecook1000/4bd8f20736eb99ed3c5a4cdcc41e9a5f 
> 
> 
> Nate
> 
>> On Apr 1, 2017, at 12:01 PM, Jason Gregori via swift-evolution 
>> > wrote:
>> 
>> 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 11:52 AM Zach Waldowski via swift-evolution 
>> > wrote:
>> Snipped quoted proposal so as to not break the mailing list… By and large, 
>> I'm in favor. I like the potential for bringing up Dictionary and Set up to 
>> the implementation quality of Array and String.
>> 
>> I don't think `init(merging:resolvingCollisionsWith:)` et al hold their 
>> weight for inclusion in the language, unless some notable optimization 
>> opportunity can be surfaced out of it. Users frustrated at the lack of a 
>> `merge` in Swift want it to be opinionated and "just do the right thing," 
>> i.e., the same way as whatever other language they most recently used. A 
>> properly annotated and indented-to-be-beautiful use of the closure-based 
>> version will take up the same amount of code as doing the merge by hand with 
>> your custom condition. 
>> 
>> Sincerely,
>>   Zachary Waldowski
>>   z...@waldowski.me 
>> 
>> ___
>> 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
> 
> ___
> 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] [Draft] Dictionary & Set Enhancements

[Ricardo Parada via swift-evolution]

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/natecook1000/4bd8f20736eb99ed3c5a4cdcc41e9a5f 
> 
> 
> Nate
> 
>> On Apr 1, 2017, at 12:01 PM, Jason Gregori via swift-evolution 
>> > wrote:
>> 
>> 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 11:52 AM Zach Waldowski via swift-evolution 
>> > wrote:
>> Snipped quoted proposal so as to not break the mailing list… By and large, 
>> I'm in favor. I like the potential for bringing up Dictionary and Set up to 
>> the implementation quality of Array and String.
>> 
>> I don't think `init(merging:resolvingCollisionsWith:)` et al hold their 
>> weight for inclusion in the language, unless some notable optimization 
>> opportunity can be surfaced out of it. Users frustrated at the lack of a 
>> `merge` in Swift want it to be opinionated and "just do the right thing," 
>> i.e., the same way as whatever other language they most recently used. A 
>> properly annotated and indented-to-be-beautiful use of the closure-based 
>> version will take up the same amount of code as doing the merge by hand with 
>> your custom condition. 
>> 
>> Sincerely,
>>   Zachary Waldowski
>>   z...@waldowski.me 
>> 
>> ___
>> 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
> 
> ___
> 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] [Review] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[Ricardo Parada via swift-evolution]

> 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-evolution/blob/master/proposals/0161-key-paths.md
>  
> 
> What is your evaluation of the proposal?

+ 1

> Is the problem being addressed significant enough to warrant a change to 
> Swift?
It's a good start.  Read below.

> Does this proposal fit well with the feel and direction of Swift?
Yes.

I just wished we could come up with a more elegant notation than #keyPath(Root, 
path).  But I understand that just about all the special characters suggested 
are taken or reserved, i.e. $, ::, #, @.  I favored the original syntax before 
the review period.  If you keep reading you'll understand why.

The only other alternative I can think of would be to rename the existing 
#keyPath() to #objcKeyPath() and make #keyPath() exclusive to swift key paths.  
But it's probably not much of an improvement over #keyPath(Root, path).  In 
fact, if we wanted to get the key path of a static member then I think the 
proposed syntax would be better, i.e. #keyPath(Root.Type, staticMember)

My goal would be to be able to extend these smart keys some day and use them 
with a object-to-relational-mapping module in Swift.  I would love to be able 
to construct orderings, qualifiers for my queries with code that looked like 
this:

let isPuppyQualifier = Pet.type.equals(.dog).and(Pet.age.lessThan(12))
let familiesQualifier = Family.pets.hasAtLeastOne(satisfying: isPuppyQualifier)
let familiesWithPuppies = Family.fetch(ec, familiesQualifier)

I believe that in order to be able to use them like this, they would have to be 
extensible and use this notation.  They would also have to be converted to 
strings.  The reason is that the string can be used in combination with an 
object model to figure out the columns to use when building SQL.

I don't know if Swift will evolve smart key paths in this direction, but it's 
an area that I think is begging for improvement compared to other languages 
that I use.  I think Swift could make a difference.  It would certainly attract 
a large number of developers working on the server side writing this type of 
code on a day to day basis.  

Having a very elegant object-to-relational-mapping module is very important.  I 
really hope that Apple enables it and someone whether Apple or a third party is 
able to create something as nice as WebObjects and the Enterprise Objects 
Framework.

> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
I have used key paths in java / WebObjects.  WebObjects is a really nice 
java-based library from Apple that originated in Objective-C during the NeXT 
era.  It has key-value-coding and an Enterprise Objects Framework (which Craig 
Federighi helped design while at NeXT).  It is similar to CoreData but it can 
connect to just about every database out there.  Project Wonder has enhanced 
the experience and added source code generation from object models.  

The code generated from the object models has keys and key paths that contain 
string information as well as some type information similar to these smart key 
paths being proposed by SE-0161.  The java code for these keys looks similar to 
this: 

``` java

public static final KeyPath FIRST_NAME = new 
KeyPath("firstName");
public static final KeyPath LAST_NAME = new 
KeyPath("lastName");
public static final KeyPath BIRTH_DATE = new 
KeyPath("birthDate");
```

For example, the above declarations are at the top of _Person.java class which 
is automatically generated from an object model.  Person then extends _Person 
to get all the code automatically generated which includes getters and setters, 
i.e. lastName() and setLastName(value).  

I then use key path objects to build sort orderings:

``` java
NSArray sortOrderings = 
Person.FIRST_NAME.asc().then(Person.LAST_NAME.asc());
```

Or qualifiers to filter elements in an array:

``` java
personsOlderThan35 = 
persons.filtered(Person.BIRTH_DATE.lessThan(thirtyFiveYearsAgo));
```

Or a qualifier for a query:

``` java
EOQualifier qualifier = Person.BIRTH_DATE.lessThan(thirtyFiveYearsAgo);
```
You can also build qualifiers that work across relationships, whether they are 
to-one or to-many:

``` java

EOQualifier isPuppyQualifier = 
Pet.TYPE.equals(PetType.DOG).and(Pet.AGE.lessThan(12))

// This qualifier could be used to fetch all the families that have puppies
EOQualifier qualifier = 
Family.PETS.hasAtLeastOneObjectSatisfying(isPuppyQualifier);
NSArray familiesWithPuppies = Family.fetch(editingContext, 
qualifier);
```

These key paths can be 

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

[Ricardo Parada via swift-evolution]

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 == 0 } // All are even
nums.allMatch { $0 % 2 == 0 }   // All are even
nums.membersSatisfy { $0 % 2 == 0 } // All are even
nums.membersMatch { $0 % 2 == 0 }   // All are even
nums.elementsSatisfy { $0 % 2 == 0 }// All are even
nums.elementsMatch { $0 % 2 == 0 }  // All are even

Personally, I think I like   nums.allMatch { $0 % 2 == 0 }. 



> On Apr 1, 2017, at 1:58 PM, Nevin Brackett-Rozinsky via swift-evolution 
>  wrote:
> 
> 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 )
> nums.all{ $0 == 9 }
> nums.all{ n in n*n < 2 }
> 
> Nevin
> ___
> 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] [Pitch] Add an all algorithm to Sequence

[Ricardo Parada via swift-evolution]

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.
> 2) A list containing a single distinct element is not a special enough case 
> to check for to warrant its own function signature.
> 
> all(equal:) can be replicated easily enough with nums.all { $0 == 9 }. Unlike 
> all(equals:), this is extendible to non-Equatable types with equatable 
> members.
> ___
> 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] Smart KeyPaths

[Ricardo Parada via swift-evolution]

> 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 begins with uppercase.


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Smart KeyPaths

[Ricardo Parada via swift-evolution]

> 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. 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Ricardo Parada via swift-evolution]

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 fantastic proposal for submodules which changed private to mean
>> “private to the submodule”, where each file was implicitly a submodule
>> unless you declared otherwise.  Simple and elegant.
> 
> Currently I don't see how submodules can eliminate the needs of 
> 'scoped'(current 'private') access level. Even in submodule (even if 
> submodule will be a "namespace" line feature like "submodule Name{..}" and we 
> can have number of such declarations in the same file) - 'scoped' access is 
> valuable even for single type declaration. Probably I don't understand 
> something.
> 
> But as for fileprivate - it is really logically to have it named 'private' 
> and it can naturally be used in submodules as "private to submodule" just 
> like "private to file" currently.
> 
> So I do think the right move currently is to rename fileprivate->private, 
> private->scoped and then, when(if!) we have submodules - we can change 
> something.
> Rename will remove the huge confusion users(especially novice) have with 
> 'fileprivate' vs 'private'; experience shows that *actually* programmers use 
> 'fileprivate' a lot and this is some kind of Swift/iOs programming style, and 
> fileprivate is awkward keyword, and many(all? ;-)  just want 'private' means 
> "in this file".
> Also novice programmer can know just about 'public', 'internal' and 'private' 
> - these three logically united access modifiers,all are file-scoped, but more 
> experienced programmer has no problems teach what 'scoped' means and why one 
> want to use it.
> 
>> 
>> 
>>> On Mar 23, 2017, at 6:27 PM, Drew Crawford via swift-evolution
>>> > wrote:
>>> 
>>> 
>>> 
>>> 
>>> Sent from my iPhone
>>> On Mar 23, 2017, at 6:41 PM, David Hart >> > wrote:
>>> 
 I have difficulties imagining a submodule proposal that could allow us
 to eliminate fileprivate. Care to give an example?
>>> 
>>> The obvious example would be Rust.  Rust has exactly two visibilities,
>>> and merely one keyword.  By default, members are "private" which is
>>> visible inside the module (so, like Swift's internal). The "public"
>>> keyword is similar to Swift.
>>> 
>>> The reason this works is that unlike in Swift where a module is something
>>> like a library or framework (Rust calls those "crates"), in Rust modules
>>> in are (explicitly) lexically scoped; a "mod myscope {}" module can be
>>> created for the portion of the file for which the member should be
>>> visible and it won't be visible outside that scope. Likewise,
>>> "fileprivate" can be achieved by enclosing the file in a "mod MyFile {}".
>>> And like all lexical scopes, they can be recursively nested to arbitrary
>>> depth to achieve any number of visibility behaviors (e.g., declare a
>>> module for the first half of two files) that would require complex new
>>> keywords to achieve in Swift. Finally there are some shortcut features
>>> like the ability to infer a module structure from the file system.
>>> 
>>> 
>>> 
>>> In Swift, modules are presently tied to libraries/frameworks in a 1:1
>>> way. Because of this we lack the flexibility of recursively nestable
>>> modules of other languages and this is the underlying problem that
>>> motivates both scoped/private and fileprivate.  If we fixed that, we
>>> would actually not need either keyword.
>>> 
>>> http://rustbyexample.com/mod/visibility.html
>>> https://doc.rust-lang.org/book/crates-and-modules.html
>>> ___
>>> 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
>> 
> ___
> 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] Smart KeyPaths

[Ricardo Parada via swift-evolution]

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, 2017, at 4:51 PM, Ricardo Parada via swift-evolution 
> <swift-evolution@swift.org> 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 
> the ambiguity with static properties and instance properties with the same 
> name.  But using a sigil seems like it can unify method references and key 
> path references.
> 
> Is the single quote taken?  For example:
> 
> let path = 'Bag.things[0].name
> bag[path] 
> bag['Bag.things[0].name]
> bag['.things[0].name]
> bag.things[0]['.name]
> bag.things[0]['Thing.name]
> 
> And the examples on the proposal would become:
> 
> 'Person.friends[0].name
> luke['.friends[0].name]
> luke.friends[0]['.name]
> 
> If we were to put it between root and the path then it would look like this:
> 
> let path = Bag'things[0].name
> bag[path] 
> bag[Bag'things[0].name]
> bag['things[0].name]
> bag.things[0]['name]
> bag.things[0][Thing'name]
> 
> 
> Right now the compiler tells me that it found an "unterminated string 
> literal".  
> 
> When I add the closing single quote then it tells me "single-quoted string 
> literal found, use '"' instead"
> 
> 
> 
> 
>> On Mar 22, 2017, at 3:16 PM, Brent Royal-Gordon via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>>> On Mar 22, 2017, at 9:00 AM, Vladimir.S via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> bag[#path]
>> 
>> What do these do?
>> 
>>  bag[#file]
>>  bag[#line]
>>  bag[#function]
>>  // etc.
>> 
>> -- 
>> Brent Royal-Gordon
>> Architechies
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto: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

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Smart KeyPaths

[Ricardo Parada via swift-evolution]

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 like it can unify method references and key path 
references.

Is the single quote taken?  For example:

let path = 'Bag.things[0].name
bag[path] 
bag['Bag.things[0].name]
bag['.things[0].name]
bag.things[0]['.name]
bag.things[0]['Thing.name]

And the examples on the proposal would become:

'Person.friends[0].name
luke['.friends[0].name]
luke.friends[0]['.name]

If we were to put it between root and the path then it would look like this:

let path = Bag'things[0].name
bag[path] 
bag[Bag'things[0].name]
bag['things[0].name]
bag.things[0]['name]
bag.things[0][Thing'name]


Right now the compiler tells me that it found an "unterminated string literal". 
 

When I add the closing single quote then it tells me "single-quoted string 
literal found, use '"' instead"




> On Mar 22, 2017, at 3:16 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>> 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
> 
> ___
> 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] Smart KeyPaths

[Ricardo Parada via swift-evolution]

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 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 = #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
>> 
>> 3) «Root» + # + «path» like this: 
>> 
>> let path = Bag#things[0].name
>> bag[path] 
>> bag[Bag#things[0].name]
>> bag[#things[0].name]
>> bag.things[0][#name]
>> bag.things[0][Thing#name]
> 
> I prefer the third option.  I don’t think we should go with the first option. 
>  Allowing (or requiring) a space seems likely to be confusing.  Both the 
> first and the second still have potential to be confusing.  If `Bag` has a 
> static property named `things` people could be confused about what 
> `#Bag.things` refers to.  If we’re going to use a special sigil it should be 
> positioned such that it eliminates potential for that kind of confusion.
> 
>> 
>> 
>> 
>>> On Mar 22, 2017, at 11:47 AM, 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 > > 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 I understood correctly, you are using it to get the key path but also 
> to apply the key path to the bag struct and get the corresponding value.
> 
 
 Yes. And the initial proposal suggest the following syntax accordingly:
 
 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]
>>> 
>>> # makes a lot more sense than @ as a sigil.  It follows from #selector and 
>>> #keyPath.  These are the most similar language features right now where the 
>>> compiler produces special values.  I think it’s also worth noticing that 
>>> values produced by #selector and #keyPath are used in normal ways.  There 
>>> is no magic syntax for their use, just a typed value.  If we’re going to 
>>> make a change we should use # instead of `.` for accessing these special 
>>> values but we should stick with subscript for use.
>>> 
 ___
 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] Smart KeyPaths

[Ricardo Parada via swift-evolution]

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 = #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

3) «Root» + # + «path» like this: 

let path = Bag#things[0].name
bag[path] 
bag[Bag#things[0].name]
bag[#things[0].name]
bag.things[0][#name]
bag.things[0][Thing#name]



> On Mar 22, 2017, at 11:47 AM, 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 > 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 I understood correctly, you are using it to get the key path but also to 
>>> apply the key path to the bag struct and get the corresponding value.
>>> 
>> 
>> Yes. And the initial proposal suggest the following syntax accordingly:
>> 
>> 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]
> 
> # makes a lot more sense than @ as a sigil.  It follows from #selector and 
> #keyPath.  These are the most similar language features right now where the 
> compiler produces special values.  I think it’s also worth noticing that 
> values produced by #selector and #keyPath are used in normal ways.  There is 
> no magic syntax for their use, just a typed value.  If we’re going to make a 
> change we should use # instead of `.` for accessing these special values but 
> we should stick with subscript for use.
> 
>> ___
>> 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] Smart KeyPaths

[Ricardo Parada via swift-evolution]

> 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 I understood correctly, you are using it to get the key path but also to 
apply the key path to the bag struct and get the corresponding value. 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Smart KeyPaths

[Ricardo Parada via swift-evolution]

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 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 
>>> using the same syntax.  IMO this proposal does the right thing by choosing 
>>> consistency with existing language features.  The current syntax for 
>>> unbound methods works and hasn't caused any confusions I'm aware of in 
>>> practice.  
>>> 
>>> I don't feel too strongly about what syntax we use as long as it's concise 
>>> and works for accessing all unbound members.  If people want to make the 
>>> case for using `#` instead of `.` to do this I won't object but I won't be 
>>> a vocal advocate either.  However, I think that should be an independent 
>>> proposal if somebody wants to pursue it rather than a bike shed on this 
>>> proposal which would only lead to inconsistency between key paths and 
>>> unbound methods if it succeeds.
>> 
>> A new syntax for key paths and function references could resolve:
>> 
>> * the "compound name syntax for nullary functions" problem;
>> 
>> 
>> * the source-breaking change of SE-0042 (if reconsidered for Swift 4);
>> 
> 
> I would like to see both of these problems resolved.  If somebody put 
> together a solid proposal for this I would probably support it (depending on 
> details of course).  
> 
>> 
>> -- Ben
>> 
> 
> ___
> 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] Fwd: Re: Smart KeyPaths

[Ricardo Parada via swift-evolution]

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 via swift-evolution 
>>  wrote:
>> 
>> On 20.03.2017 17:56, Charles Srstka via swift-evolution wrote:
 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
>> > 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
>> be very little extra typing anyway…
> 
> But that adds a lot of verbosity. They disregarded #keyPath because it
> was too verbose.
 
 The syntax in the original proposal is terse and elegant, and will
 probably be fine when a developer who is experienced with Swift and a
 particular codebase is first writing the code. Using “key path” or
 “keypaths” of perhaps a shorter term or even a single leading character
 (`#` ?) will make this feature more discoverable, tool-friendly and its
 usages more maintainable.
 
 An extra term or character does add verbosity. How much is subjective,
 but I would not call it “a lot”. It does not add any nesting or code
 complexity. KVO code is usually a small fraction of most Objective-C
 projects (in my experience, at least) and it is probably safe to assume
 that the usage of this feature in Swift will be similar.
 
 Verbosity vs clarity is often a tradeoff and I think that on balance, for
 a feature like this a little extra verbosity is worth it. Swift does not
 have the most terse syntax possible. `++` was removed, for example.
 
 Just because an assignment is already implicitly typed in Swift does not
 mean that the ambiguity has to keep increasing without end for
 implementation of all new features, especially for ones that are not used
 very frequently.
>>> 
>>> +1 to all of this.
>>> 
>>> Particularly the point that KVO code typically is a small portion of the
>>> overall code; this not only makes the added verbosity not that
>>> egregious—certainly less so than “try” or “override”—but it also
>>> underscores the fact that as a relatively uncommon feature, it’s not what a
>>> reader of the code is going to be expecting to see. This latter point is
>>> why I feel that without some kind of additional syntax—even if it’s just
>>> one character—key paths will frequently get mistaken for property accesses
>>> if they are implemented this way.
>> 
>> +1 from me. The problem is not that we shouldn't have instance props with 
>> the same name as class/static props. The problem is when you are *reading* 
>> some code(not always in IDE) it is hard to say what 
>> MyType.someprop[atIndex].name means. Is it static/class property or is it 
>> KeyPath? You just don't know - you have to check this in MyType declaration 
>> for any static property you don't know for sure it is static .
>> 
>> The same is for instance:
>> 
>> struct S {
>>var index = 0
>>func foo() {}
>>subscript (at: Int) -> Int {return at*100}
>> }
>> //
>> let s = S()
>> let value = s[index]
>> // is it key path or subscript with `index` as parameter?
>> 
>> The difference with unbound methods(I hope I correctly understand that 
>> unbound method is `T.method` as mentioned by the proposal) is that unbound 
>> method IMO don't have *such* level of confusing. It can't have subscripts, 
>> it can't contains more than one part(the method name itself).
> 
> Yes, this is a difference that matters in some respects.
> 
>> 
>> Also, using the above code,
>> let method = S.foo
>> 
>> this line *has* a marker, that here we have an unbound method : there is 
>> *no* `()` after the foo. Do we have any such 'marker' in proposed key paths? 
>> No.
>> 
>> So I do believe this special feature(I mean it will be used rarely and 
>> reader most likely will not expect it in the code) requires a special syntax 
>> highlighting.
>> 
>> FWIW, currently I do like 3 proposed syntax to highlight what is happening 
>> here and also is not verbose like #keyPath():
>> 
>> 1. Type:path and instance:path
>> 
>> 2. Type@path and instance@path - as it reads nice "type at path" and 
>> "instance at path"
>> 
>> 3. And also I think as soon as we have `#` as marker for 'compiler magic', 
>> IMO it will be logically use 

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

[Ricardo Parada via swift-evolution]

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 thought it might 
>> be time to revisit this proposal and see if it might align with the goals 
>> set forth for Swift 4.
>> 
>> As a quick tl;dr, this proposal describes a new "factory initializer" that 
>> would allow you to return a value from an initializer. This would have 
>> several benefits, as mentioned in the proposal itself as well as throughout 
>> this mailing list. For convenience, here's a link to the proposal on GitHub: 
>> https://github.com/rileytestut/swift-evolution/blob/master/proposals/-factory-initializers.md
>> 
>> Would love to hear any more comments on this proposal, and if we feel this 
>> is appropriate for considering for Swift 4 I'll happily re-open the pull 
>> request!
>> 
>> Riley Testut
>> 
>>> On Nov 19, 2016, at 7:45 AM, arkadi daniyelian  wrote:
>>> 
>>> i would appreciate this feature.
>>> 
>>> For unexperienced developers, its often hard to recognize *when* factory is 
>>> a good fit to do the job, and how exactly approach the implementation. I 
>>> imagine having this feature built into the language may help to choose and 
>>> implement factory when its the right thing to do.
>>> 
 On Nov 18, 2016, at 12:23 AM, Charles Srstka via swift-evolution 
  wrote:
 
 Is there any chance of reviving this? It seems to me that since this would 
 require Swift initializers to be implemented internally in such a way that 
 they can return a value (as Objective-C init methods do), it may affect 
 ABI stability and thus may be germane to the current stage of Swift 4 
 development.
 
 Charles
 
> On Dec 17, 2015, at 3:41 PM, Riley Testut via swift-evolution 
>  wrote:
> 
> Recently, I proposed the idea of adding the ability to implement the 
> "class cluster" pattern from Cocoa (Touch) in Swift. However, as we 
> discussed it and came up with different approaches, it evolved into a 
> functionality that I believe is far more beneficial to Swift, and 
> subsequently should be the focus of its own proposal. So here is the 
> improved (pre-)proposal:
> 
> # Factory Initializers
> 
> The "factory" pattern is common in many languages, including Objective-C. 
> Essentially, instead of initializing a type directly, a method is called 
> that returns an instance of the appropriate type determined by the input 
> parameters. Functionally this works well, but ultimately it forces the 
> client of the API to remember to call the factory method instead, rather 
> than the type's initializer. This might seem like a minor gripe, but 
> given that we want Swift to be as approachable as possible to new 
> developers, I think we can do better in this regard.
> 
> Rather than have a separate factory method, I propose we build the 
> factory pattern right into Swift, by way of specialized “factory 
> initializers”. The exact syntax was proposed by Philippe Hausler from the 
> previous thread, and I think it is an excellent solution:
> 
> class AbstractBase {
>  public factory init(type: InformationToSwitchOn) {
>  return ConcreteImplementation(type)
>  }
> }
> 
> class ConcreteImplementation : AbstractBase {
> 
> }
> 
> Why exactly would this be useful in practice? In my own development, I’ve 
> come across a few places where this would especially be relevant:
> 
> ## Class Cluster/Abstract Classes
> This was the reasoning behind the original proposal, and I still think it 
> would be a very valid use case. The public superclass would declare all 
> the public methods, and could delegate off the specific implementations 
> to the private subclasses. Alternatively, this method could be used as an 
> easy way to handle backwards-compatibility: rather than litter the code 
> with branches depending on the OS version, simply return the 
> OS-appropriate subclass from the factory initializer. Very useful.
> 
> ## Protocol Initializers
> Proposed by Brent Royal-Gordon, we could use factory initializers with 
> protocol extensions to return the appropriate instance conforming to a 
> protocol for the given needs. Similar to the class cluster/abstract class 
> method, but can work with structs too. This would be closer to the 
> factory method pattern, since you don’t need to know exactly what type is 
> returned, just the protocol it conforms to.
> 
> ## Initializing Storyboard-backed View Controller
> This is 

Re: [swift-evolution] Smart KeyPaths

[Ricardo Parada via swift-evolution]

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 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 Smart KeyPaths will solve these two problems:
>> 
>> 1. fetching data from a database and stuff it into objects that are not 
>> known at compile time (since you’ve written the framework ahead of time)
>> 
>> 2. Token replacing text in a template, like ${person.firstName}
>> 
>> Will there be some conversion of key paths to/from strings?
> 
> There won't be a conversion from strings in this initial proposal. That would 
> be a reasonable thing to add later. For the use case of formatting strings, 
> hopefully, there'll eventually be some way to build formatting templates that 
> are well-typed instead of relying on parsing strings at runtime.
> 
> -Joe
> ___
> 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] Smart KeyPaths

[Ricardo Parada via swift-evolution]

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
> 
> 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 
  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 be very 
 little extra typing anyway…
>>> 
>>> But that adds a lot of verbosity. They disregarded #keyPath because it was 
>>> too verbose.
>>> 
>> 
>> Then let me add a +1 for the verbose solution as well.
>> 
>> Sometimes verbosity is not bad.
> 
> Huge -1 from me.  What we do should be consistent with unbound methods.  This 
> idea should need to justify why the inconsistency (or changing unbound 
> methods - a breaking change) is worth the benefit you perceive.  I think 
> that's a pretty tough sell.
> 
> If we did go with the verbose option I hope the dot shorthand that only 
> requires a property name would still work in a type context expecting a key 
> path with a concrete root type.
> 
>> 
>> Regards,
>> Rien
>> 
>> Site: http://balancingrock.nl
>> Blog: http://swiftrien.blogspot.com
>> Github: http://github.com/Balancingrock
>> Project: http://swiftfire.nl
>> 
 Thanks,
 Jon
 
> On Mar 19, 2017, at 9:20 PM, Dietmar Planitzer via swift-evolution 
>  wrote:
> 
> 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 now:
> 
> class Person {
> 
> struct keypath {
> 
>  static let name = #keyPath(Person.name)
>  …
> }
> 
> …
> }
> 
> where a keypath is then used like this:
> 
> Person.keypath.name
> 
> and this has worked very well. It makes it easy to see where we are using 
> a keypath rather than accessing some static property, it works very 
> nicely with code completion and it makes it very easy to search for all 
> places where we are using key paths from the Person type.
> 
> I would prefer that the proposed keypath model would automatically 
> organize key paths like this.
> 
> 
> Regards,
> 
> Dietmar Planitzer
> 
> 
>> On Mar 19, 2017, at 20:49, Matthew Johnson via swift-evolution 
>>  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 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, it is difficult to distinguish a key path from a static 
>>> variable. Maybe that's not problematic? Well, it's up to the community 
>>> to decide.
>> 
>> Why don't we just say all instance properties are shadowed by a static 
>> constant property of the same name with the appropriate key path type.  
>> This makes it not mysterious at all but instead very straightforward.  
>> We could even say that static and class properties are shadowed by a key 
>> path property on the meta type.
>> 
>> 
>>> I do think it is a bit worrisome that static variable access might 
>>> cause side effects (or at least, might take a while to compute) but 
>>> creating key paths should not, but that's a fringe case probably.
>>> 
>>> On Mar 19, 2017, at 6:32 PM, Brent Royal-Gordon via swift-evolution 
>>>  wrote:
>>> 
> 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:
 
 sum :: (Num a, Foldable t) => t a -> a

Re: [swift-evolution] Smart KeyPaths

[Ricardo Parada via swift-evolution]

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 17, 2017, at 3:04 PM, BJ Homer > > wrote:
>> 
>> So then this would be disambiguated like this?
>> 
>> let staticValue = Foo.bar // Defaults to accessing the static value, when 
>> there is ambiguity
>> 
>> let value:   Bar   = Foo.bar
>> let keyPath: WritableKeyPath = Foo.bar
>> 
>> It’s a little unfortunately to have to spell out WritableKeyPath 
>> there, but as long as there’s some way to do it, I don’t think it’s a 
>> problem. This is likely a rare edge case.
> 
> You could also just write `: WritableKeyPath` and let the generic arguments 
> be deduced. I agree that, in most situations you want a key path, you'll 
> likely have type context that picks the right thing.
> 
> -Joe
> 
>> -BJ Homer
>> 
>>> On Mar 17, 2017, at 3:56 PM, Joe Groff >> > wrote:
>>> 
 
 On Mar 17, 2017, at 2:53 PM, Michael LeHew > wrote:
 
 
> On Mar 17, 2017, at 2:21 PM, BJ Homer  > wrote:
> 
> This looks great!
> 
> What happens in the case when there is a static property by the same name 
> as an instance property? e.g.
> 
> struct Foo {
> static var bar: Bar
> var bar: Bar
> }
> 
> Foo.bar // What is this?
> 
> Is it still possible to reference both the static property and a KeyPath 
> to the instance method? 
 
 This is essentially the same question that I arrived at in my reply to 
 Vladimir.  I think Joe might be best able to answer here.
>>> 
>>> We already encounter this situation with static vs instance methods, since 
>>> `Foo.bar` can refer to either a static method `bar` or an unbound instance 
>>> method `bar`. We use type context to disambiguate, favoring the static 
>>> member if context doesn't help:
>>> 
>>> struct X {
>>>   static func foo() {}
>>>   func foo() {}
>>> }
>>> 
>>> let foo1 = X.foo // Defaults to static member
>>> let foo2: () -> () = X.foo // Picks static member by type context
>>> let foo3: (X) -> () -> () = X.foo // Picks instance member by type context
>>> 
>>> -Joe
>> 
> 
> ___
> 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] Smart KeyPaths

[Ricardo Parada via swift-evolution]

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 
  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 this. With the proposed syntax, it’s unclear whether 
>>> you’re referring to a static property or a key path. It’s going to cause 
>>> confusion. There needs to be some kind of syntactic way to differentiate 
>>> the two.
>> 
>> How often do you have a property with the exact same name and type on both 
>> the instance and type? When you *do* have one, how often would it be better 
>> off with a name like `defaultFoo` instead of plain `foo`?
>> 

That crossed my mind too. If we have a static property with the same name as a 
property then make it a warning and we can easily rename one or the other in 
our code to fix the warning. 

>> Why is this a problem for keypaths, but not for unbound methods?
>> 

Hi Brent, what is an unbound method? Do you have a simple example just so that 
I can better follow what you are saying? Thanks. 


>> How is this different from a hundred other places in Swift where we allow 
>> overloading and tolerate ambiguity in order to enjoy nicer syntax?
>> 
>> When, in practice, do you expect this to cause trouble?
> 
> +1
> 
>> 
>> -- 
>> Brent Royal-Gordon
>> Architechies
>> 
>> ___
>> 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
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Smart KeyPaths

[Ricardo Parada via swift-evolution]

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. 

I'm not arguing in favor of this though. Im just trying to bring up possible 
solutions so we that we can better compare the alternatives and understand the 
pros and cons of each. 

By the way I do like the colon notation that you and others have suggested. I 
hope we pick the best 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 <mail...@xenonium.com> wrote:
> 
> 
>> Le 19 mars 2017 à 16:41, Ricardo Parada via swift-evolution 
>> <swift-evolution@swift.org> 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 as the property which would be an odd 
>> practice I think.  
> 
> 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.
> 
> Without context, the following statement is ambiguous, This ambiguity can 
> easily be avoid by choosing an other syntax. So why would we want to 
> introduce it in the first place ?
> 
> let name = Person:friends[0].name
> 
> 
> 
>> I was defining static properties with the same name as the property in order 
>> to smart key paths.  For example:
>> 
>> Class Person {
>>static firstName: KeyPath(“firstName”)
>>static lastName: KeyPath(“lastName”)
>> 
>>var firstName: String 
>>var lastName: String
>> 
>>…
>> }
>> 
>> 
>> So that I could create qualifiers, ie. Person.firstName.like(“R*”), and sort 
>> orderings, Person.firstName.asc().
>> 
>> I think with these smart key paths the need for these static properties that 
>> mirror the property on the instance would not be required.
>> 
>> 
>> 
>> 
>>> On Mar 17, 2017, at 2:27 PM, Vladimir.S via swift-evolution 
>>> <swift-evolution@swift.org> wrote:
>>> 
>>> On 17.03.2017 20:04, 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:
>>>> 
>>>> Many thanks,
>>>> -Michael
>>>> 
>>>> 
>>>> Smart KeyPaths: Better Key-Value Coding for Swift
>>>> ...
>>> 
>>> Just my 2 cents. FWIW, I feel like the proposed syntax is VERY confusing.
>>> 
>>> Person.friends[0].name - like access to static property. T.method can't 
>>> have subscript for it and then some field. So, I believe such key paths 
>>> deserve its own syntax.
>>> 
>>> luke[path] - very close to access the subscript of instance. In compare to 
>>> T.method, we can call result of T.method(i.e. let m = T.method; m()), just 
>>> like the T.method itself(foo.method()). But here we are calling some kind 
>>> of subscript instead of access property by "path".
>>> 
>>> There is no some 'special' marker for me that saying "hey, there is 
>>> references to properties used" from the first look.
>>> 
>>> Probably we can consider another separators, like
>>> 
>>> Person:friends[0].name
>>> luke:path
>>> 
>>> Person->friends[0].name
>>> luke->path
>>> 
>>> Person[friends[0].name] // single brackets for type
>>> luke[[path]] // double brackets for instance
>>> 
>>> Person@friends[0].name
>>> luke@path
>>> 
>>> or other with help of community.
>>> ___
>>> 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
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Smart KeyPaths

[Ricardo Parada via swift-evolution]

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 the property in order to 
smart key paths.  For example:

Class Person {
 static firstName: KeyPath(“firstName”)
 static lastName: KeyPath(“lastName”)

 var firstName: String 
 var lastName: String

 …
}


So that I could create qualifiers, ie. Person.firstName.like(“R*”), and sort 
orderings, Person.firstName.asc().

I think with these smart key paths the need for these static properties that 
mirror the property on the instance would not be required.




> On Mar 17, 2017, at 2:27 PM, Vladimir.S via swift-evolution 
>  wrote:
> 
> On 17.03.2017 20:04, 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:
>> 
>> Many thanks,
>> -Michael
>> 
>> 
>>  Smart KeyPaths: Better Key-Value Coding for Swift
>> ...
> 
> Just my 2 cents. FWIW, I feel like the proposed syntax is VERY confusing.
> 
> Person.friends[0].name - like access to static property. T.method can't have 
> subscript for it and then some field. So, I believe such key paths deserve 
> its own syntax.
> 
> luke[path] - very close to access the subscript of instance. In compare to 
> T.method, we can call result of T.method(i.e. let m = T.method; m()), just 
> like the T.method itself(foo.method()). But here we are calling some kind of 
> subscript instead of access property by "path".
> 
> There is no some 'special' marker for me that saying "hey, there is 
> references to properties used" from the first look.
> 
> Probably we can consider another separators, like
> 
> Person:friends[0].name
> luke:path
> 
> Person->friends[0].name
> luke->path
> 
> Person[friends[0].name] // single brackets for type
> luke[[path]] // double brackets for instance
> 
> Person@friends[0].name
> luke@path
> 
> or other with help of community.
> ___
> 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] Smart KeyPaths

[Ricardo Parada via swift-evolution]

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. NSPredicate in CoreData I think) 
using a better syntax.  Same for EOSortOrdering, equivalent to 
NSSortDescriptor.  For example:

let predicate = 
Person.lastName.like(“Para*").and(Person.birthDate.greaterThan(aDate))

Fetch objects from the database into a managed object context like this:

let people = context.fetch(Person.self, predicate: predicate)   // 
people is inferred as Array

Or perhaps filter elements from an array like this:

let matches = people.filtered(predicate)// 
matches is inferred as Array

Or create sort orderings like this:

let orderings = 
Person.age.desc().then(Person.lastName.asc().then(Person.lastName.asc()))   // 
orderings is Array

And sort like this:

let sortedPeople = people.sorted(orderings) // sortedPeople is 
Array

And predicates for to-many relationships, for example, if we had a Family class 
and a Pet class and a pets to-many relationship Family <—>> Pet, then building 
a predicate like this would be cool:

// Families with at least one pet
let predicate = Family.pets.isNotEmpty()

// Families with no pets
let predicate = Family.pets.isEmpty()

// Families with a cat or dog
let predicate = Family.pets.hasAtLeastOneObjectSatisfying(Pet.type.equals(.dog))

// Families with a puppy
let predicate = 
Family.pets.hasAtLeastOneObjectSatisfying(Pet.type.equals(.dog).and(Pet.ageInMonths.lessThan(12))

In SQL these translate to an EXISTS qualifier. For example, the last predicate 
would translate to something like this in SQL:

SELECT t0.family_id, …
FROM family t0
WHERE 
EXISTS (
select p.pet_id
from pet p
where p.family_id = t0.family_id
and p.pet_type = ‘dog’
and p.age_in_months < 12
)


Would these Star KeyPaths enable this sort of expressiveness?

Or creating ad hoc queries like this:

// records is Array>
let records = Query()
.select (Claim.provider, Claim.sumExpectedAmount)  // 
Claim.sumExpectedAmount is a derived non-class property defined as 
"SUM(expectedAmount)"
.from (Claim.entityName)// Claim.entityName is a static property for 
string “Claim”
.where (Claim.userGroup.equals(aUserGroup))
.groupBy (Claim.provider)
.having (Claim.sumExpectedAmount.greaterThan(1000.0))
.orderBy (Claim.sumExpectedAmount.asc())
.fetch (editingContext)

// Or to fetch into a custom class

// objects is Array
let objects = Query()
.select (Claim.provider, Claim.sumExpectedAmount)  // 
Claim.sumExpectedAmount is a derived non-class property defined as 
"SUM(expectedAmount)"
.from (Claim.entityName)// Claim.entityName is a static property for 
string “Claim”
.where (Claim.userGroup.equals(aUserGroup))
.groupBy (Claim.provider)
.having (Claim.sumExpectedAmount.greaterThan(1000.0))
.orderBy (Claim.sumExpectedAmount.asc())
.fetch (context) {
Foo(context: ec, data: row)
}

Then print the results like this:

for obj in objects {
Print(“Health provider: \(obj.provider?.fullName), Total Expected: 
\(obj.sumExpectedAmount)”)
}

Where Foo would be a custom class to hold the results and provide some type 
checking on the getters for the data fetched:

class Foo {
var data : [String: Any]

init(context: EditingContext, data row: [String: Any]) {
   data = row
}


var provider : Provider? {
get {
   return data[“provider”] as? Provider
}
}

var provider : Double? {
get {
   return data[“sumExpectedAmount”] as? Double
}
}
}


By the way I do this kind of stuff with WebObjects and Project Wonder.  It’s 
just that the key paths are static variables defined in the class in ALL CAPS, 
i.e. Person.FIRST_NAME.asc() to get an EOSortOrdering for ascending firstName.  
They also look not as elegant for key paths, i.e. 
Claim.PROVIDER.dot(Provider.LAST_NAME).like(“Para*”) for an EOQualifier.  This 
is all provided by a class named ERXKey.

And for ad hoc queries I use ERXQuery which I recently created a pull request 
to add to project Wonder.  It’s in my repository rparada/wonder on GitHub in 
the erxquery branch.




> On Mar 17, 2017, at 1:04 PM, 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:
> 
> Many thanks,
> -Michael
> 
> Smart KeyPaths: Better Key-Value Coding for Swift
> Proposal: SE-
> Authors: David Smith , Michael LeHew 
> , Joe Groff 
> Review Manager: TBD
> Status: 

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

[Ricardo Parada via swift-evolution]

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.  I would say just pick the trailing comma. 

Thanks

> On Feb 26, 2017, at 12:25 PM, Tino Heth via swift-evolution 
>  wrote:
> 
> I suggest to take a look at the topics "Variadics as an Attribute" and "array 
> splatting for variadic parameters" and 
> https://github.com/Haravikk/swift-evolution/blob/a13dc03d6a8c76b25a30710d70cbadc1eb31b3cd/proposals/-variadics-as-attribute.md.
> 
> This is basically the other way round (arrays would accept variadic 
> arguments), but it has the same effect — and more:
> You get rid of the odd "…" type, and it's also possible to use this with 
> types besides array (set, iterator….)
> ___
> 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] [pitch] Variadic Arguments should accept Arrays

[Ricardo Parada via swift-evolution]

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 I think it would be nice 
to do it explicitly as follows:

foo(args as Argument...)


> On Feb 27, 2017, at 4:49 PM, Jose Cheyo Jimenez via swift-evolution 
>  wrote:
> 
> 
>>> On Feb 27, 2017, at 1:20 PM, Tino Heth <2...@gmx.de> wrote:
>>> 
>>> These is very unfortunate as a solution for “spreading” a collection or 
>>> tuple so that It can be applied to function taking a variadic.
>>> It makes sense on the declaration site but not on the call site. 
>>> 
>>> someFunc(@nonVariadic [1])  
>>> someFunc(@variadic [1]) 
>>> 
>>> There is nothing special about variadic/ spreading that would warrant an 
>>> attribute. 
>>> 
>>> I think using attributes is not different than using a keyword like c# 
>>> uses. 
>>> http://stackoverflow.com/questions/7580277/why-use-the-params-keyword
>>> 
>>> Do we really want to tag every array/tuple with a @variadic or @nonVariadic 
>>> tag when packing and unpacking parameters?
>>> 
>>> variadic/ spreading (AKA packing / unpacking ) is a well known concept to 
>>> most languages. 
>> 
>> I have the impression there is a misunderstanding about the proposal:
>> It would not only make the variadics-syntax superflous, but also the whole 
>> splatting-magic.
>> There would only be functions that accept arrays, and you could freely 
>> choose to feed them a comma-seperated list instead.
>> The attribute would be written in the function declaration only — and we 
>> could even decide that it isn't needed at all, and simply accept lists 
>> wherever an array is expected.
> 
> Perhaps. Implicit splat behavior was removed for Tuples; I don’t see why we 
> would reintroduce it for Array like constructs. 
> https://github.com/apple/swift-evolution/blob/master/proposals/0029-remove-implicit-tuple-splat.md#alternatives-considered
> 
> I am in favor in explicit splat behavior but I don’t see it happening anytime 
> soon. Its tagged as low priority.  
> 
>  
> ___
> 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] [pitch] Variadic Arguments should accept Arrays

[Ricardo Parada via swift-evolution]

> 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

[Ricardo Parada via swift-evolution]

> 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 down the 
> existing runtime and quietly transition those that rely on dynamism to 
> checked reflection (yes, that is not in fact an oxymoron).  The more the 
> compiler knows about your program, the better it does.  Period.
> 
How would you implement something like Core Data in pure Swift on the server 
where the Obj-C runtime is not available?


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ricardo Parada via swift-evolution]

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 it. But Swift's 
limited reflection is lacking and is crucial for implementing a framework like 
WebObjects. 

Had WebObjects been designed with sealed classes, our hands would have been 
tied for all the many apps and systems that use it. 

I am hoping that if this proposal gets approved that libraries such as these 
get designed as subclassable. That to me is much more valuable, at least for 
these types of libraries. 

I think that in the long term libraries will sort themselves out. A well 
designed subclassable library will have more value. 




> On Jul 11, 2016, at 12:49 PM, L. Mihalkovic via swift-evolution 
>  wrote:
> 
> 
> Regards
> (From mobile)
> 
>> On Jul 11, 2016, at 12:53 PM, Tino Heth <2...@gmx.de> wrote:
>> 
>> 
>>> You do realize that then itunes store used to (i don't know hese days) for 
>>> many years run on java, despite objc being such a more advanced 
>>> environment. ;-)
>> well, from my experience, app developers are running circles around the 
>> itunes store all the time ;-)
> 
> Better yet... I once had lunch with the now defunct java team and the guy who 
> did the java rewrite of webobjects... can you guess from what language? or 
> why they had to do it? 
> Still running circles?
> ;-)
> Cheers & thank u for the smiles...
> 
> 
> ___
> 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] [Review] SE-0117: Default classes to be non-subclassable publicly

[Ricardo Parada via swift-evolution]

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 still not sure about subclassable and overridable implying public. I think 
it would be more clear to to read "public subclassable class C". 

I have these thoughts regarding the naming:

I think that subclassable could be implied when the class contains an 
overridable method or property. In other words, does it make sense to have an 
overridable method or property when the class is not subclassable? Oh, I just 
realized that it is more clear if it is expressed explicitly. It could also 
avoid making the mistake of making a class subclassable by accident. 

Also "subclassable class" sounds a bit redundant. In other words, I think 
subclassable implies it is a class. But I am not sure I would want to leave out 
the class part, which brings me to one of the other alternatives:

public open class C
public open func / var

The pros here are that is is more concise. The public part could be left out 
because open seems to imply public. Open also suggests that it may be 
subclassable/ overridable. On the other hand subclassable/ overridable are both 
very clear though. 

Thanks


> On Jul 9, 2016, at 12:29 PM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> 
>> On Jul 9, 2016, at 11:04 AM, Tino Heth <2...@gmx.de> wrote:
>> 
>> 
>>> Of course it can be done either way.  But there are significant ecosystem 
>>> robustness advantages to making sealed the default and comparatively few 
>>> downsides.  Most libraries are open source (so can be modified directly or 
>>> via PR if necessary)
>> First:
>> The claim about robustness sounds like a fact, despite being just an opinion 
>> (feel free to correct me if you have any evidence at all). We should stay 
>> honest with our predictions.
>> Second:
>> Do you really believe there will be positive impact on open-source libraries?
>> My forecast is that closed by default will dramatically increase trivial 
>> pull request where developers ask for unsealing so that they can do as they 
>> like…
> 
> I think this is a good thing.  It will force a considered answer and a 
> discussion about whether or not subclassing should be supported by the 
> library.  
> 
>> and I've no idea why somebody could come up with the idea that forking is 
>> desirable.
> 
> Forking is desirable if your goals, needs, values, etc are substantially 
> different than the library author such that you do not agree on what the API 
> contract should look like.
> 
> 
> ___
> 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] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

[Ricardo Parada via swift-evolution]

> 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/proposals/0117-non-public-subclassable-by-default.md
> 
>* What is your evaluation of the proposal?

-1

Perhaps because this is so different from what I have seen in other languages 
and used for so many years. I have not worked with a language that uses 
non-subclassable/ non-overridable as the default. 

I think that by default classes should be subclassable, not the other way 
around. I am afraid that developers will not take the time to specify which 
methods are overridable resulting in libraries that are difficult to patch, 
extend. 

In my 26+ years of object-oriented design and programming (other languages, 
Objective-C since 1990 and Java since 2001) I have worked with object oriented 
libraries and subclassed methods that the authors probably never anticipated. I 
have been able to fix problems, enhance classes by creating subclasses with 
fixes and enhanced behavior. 

In java for example I have seen that sometimes I would have been able to fix 
bugs or enhance the existing classes had the author not chosen a method to be 
protected or private. Sometimes they had a good reason but sometimes they 
didn't.  Is have been able to survive using an awesome library that was 
discontinued and end-of-lifed thanks to subclassing that has allowed me to fix 
problems and enhance over the years as the Java language kept evolving. 

In general I like to design classes with methods that have a very well defined 
purpose / logic. Such methods are potentially overridable. I find that making a 
method private or final can be selfish / restrictive at times and I choose it 
carefully for implementation details that are better served by going through 
the public methods. 

I think that making a class not subclassable by default is restrictive / 
limiting / selfish. 

Sometimes the extension points are clear. 
I also think that every other method with a well defined purpose / logic is 
also potentially an extension point. 

In my experience we should allow the developer to override by default.  That is 
how I design my classes and every method / property. 

I use private for the stuff that is obvious that should not be exposed. 

In the motivation section performance is also mentioned as driving this 
proposal. However I don't see any study that supports that. I would like to see 
that. This should not be taken lightly. 

Let's imagine that performance is important for a library that is heavily used 
and that the classes are not the type that you usually override. Wouldn't we be 
better served  by being able to seal the class, i.e. "public sealed class Foo"  
and then for the methods / properties that are clear extension points should be 
flagged overridable.  I would prefer something like that. And I think it would 
be more intuitive. 


>* Is the problem being addressed significant enough to warrant a change to 
> Swift?

No. 

>* Does this proposal fit well with the feel and direction of Swift?

I think it is counter-intuitive. I don't think that reading "public class Foo" 
would make anyone think that Foo is non-subclassable. 

On the other hand, reading "public class sealed Foo" would suggest to the 
reader that the class can be overridden but only the methods that are flagged 
as overridable. 

If we wanted to prohibit overriding then we could use "public final class Foo" 
without any extension points. Then nobody would be able to subclass and it 
would be an error to try to flag a method / property as overridable.  


>* If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?

I don't recall having seen this behavior in the languages that I have worked 
with. 

>* How much effort did you put into your review? A glance, a quick reading, 
> or an in-depth study?

I read the whole proposal and have been thinking about the implications for a 
few hours. 

> More information about the Swift evolution process is available at
> 
>https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> -Chris Lattner
> Review Manager
> 
> ___
> swift-evolution-announce mailing list
> swift-evolution-annou...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution-announce
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ricardo Parada via swift-evolution]

Hi Laurent,

Do you have the details of your proposal, I missed it. 

Thanks

> On Jun 2, 2016, at 1:48 AM, L Mihalkovic <laurent.mihalko...@gmail.com> wrote:
> 
> 
>>> On Jun 2, 2016, at 5:05 AM, Christopher Kornher via swift-evolution 
>>> <swift-evolution@swift.org> wrote:
>>> 
>>> 
>> 
>>> On Jun 1, 2016, at 7:48 PM, Ricardo Parada via swift-evolution 
>>> <swift-evolution@swift.org> wrote:
>>> 
>>> 
>>> On May 31, 2016, at 3:04 PM, Erica Sadun via swift-evolution 
>>> <swift-evolution@swift.org> 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 not encourage reuse.
>> 
>> -1For me too. Introducing this quasi-enum would increase cognitive load with 
>> little, if any, net benefit. This is the sort of feature that looks great 
>> and works wonderfully in example apps, but does not scale well to real 
>> systems, where options show up in more methods through time, get passed 
>> around to helpers, stored, marshaled into various formats, etc.
>> 
>> As someone mentioned, this would probably be a good fit If Swift adopts a 
>> structural type system (I suppose, I have ever used a language with one to 
>> my knowledge, unless duck typing counts)
>> 
>> As syntactic sugar for a true enum declaration, it would be a “cool” 
>> feature, but reuse would still be problematic. 
> 
> 
> there is no reuse problem in the interpretation I propose, and the long/short 
> form names are completely interchangeable.
> 
>> 
>>> 
>>> I would not be able to assign to a variable:
>>> 
>>> let selectedOperation = .fill
>>> 
>>> In order to then do this later in the program:
>>> 
>>> scaleAndCropImage(image: myImage, toSize: size, operation: 
>>> selectedOperation)
>>> ___
>>> 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
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ricardo Parada via swift-evolution]

> 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 ad hoc enum U is 
> expected if T ⊆ U.

If that were the case then it may not be that bad. 

I would not use it that much as I favor reusability and would normally create 
an enum for it for maximum flexibility and reuse. 

I like tuples but I don't use them much and I have survived in other languages 
without them. :-)

This is all sugar to me. I may use it when putting code together quickly but 
not in formal APIs. 

I really look forward to seeing other features in Swift that will elevate the 
language and run-time to levels where Objective-C still has an edge over Swift. 
In particular reflection, property behaviors, KVC, etc.   
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ricardo Parada via swift-evolution]

> 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 not encourage reuse. 

I would not be able to assign to a variable:

let selectedOperation = .fill

In order to then do this later in the program:

scaleAndCropImage(image: myImage, toSize: size, operation: selectedOperation)___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ricardo Parada via swift-evolution]

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 fullName were implemented as a 
computed property as opposed to an instance method? 

Thanks



> On May 27, 2016, at 2:59 PM, Austin Zheng  wrote:
> 
> Yes, it was pretty much meant as a KVC-like feature for Swift. Get a 
> reference to a property from a string which would allow you to get and set 
> its value.
> 
>> On Fri, May 27, 2016 at 11:53 AM, Ricardo Parada  wrote:
>> 
>>> 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 other day and my code to get a value given the 
>> property name looked more like this:
>> 
>> let age = myPerson.value(forKey:”age”) as! Int
>> 
>> And this is what I did:
>> 
>> // KVC stands for key-value-coding… but I only know how to get values.  I 
>> don’t know how to set values
>> 
>> protocol KVC {
>>func value(forKey key: String) -> Any!
>> }
>> 
>> // Default implementation
>> extension KVC {
>>func value(forKey key: String) -> Any! {
>>let aMirror = Mirror(reflecting:self)
>>for case let (label?, value) in aMirror.children {
>>if label == key {
>>return value
>>}
>>}
>>return nil
>>}
>> }
>> 
>> public struct Person : KVC {
>>let firstName: String
>>let lastName: String
>>let age: Int
>> 
>>func fullName() -> String {
>>return "\(firstName) \(lastName)"
>>}
>> }
>> 
>> let aPerson = Person(firstName:"John", lastName:"Doe", age:48)
>> 
>> // It works for stored properties
>> let lastName = aPerson.value(forKey:"lastName") as! String
>> print("Last name is \(lastName)")
>> 
>> // It does not work for instance methods, i.e. fullName is not a stored 
>> property
>> let fullName = aPerson.value(forKey:"fullName")
>> if fullName != nil {
>>print("Full name is \(fullName)")
>> } else {
>>print("Unable to get fullName via KVC")
>> }
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ricardo Parada via swift-evolution]

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 
>> / Hashable and you would not find out until you tried to use it.  Would that 
>> be bad?
> 
> Yes.  It would also be bad if implicit synthesis resulted in an unintentional 
> and incorrect definition of equality.  By requiring synthesis to be requested 
> with `deriving` the programmer is at least prompted to consider the meaning 
> of equality for their type.

Incorrect definition of equality? Hmm... :-)

I guess I have been running under the wrong assumption that if a struct uses 
values that are all Equatable then the default implementation for the struct 
which will compare the values against the values in the other struct will 
ALWAYS be correct. But I guess I can come up with an example where some of the 
values stored in the struct do not play a role in the definition of equality 
even if those values are Equatable. Then the default implementation would be 
incorrect. 

But I am not convince that is bad because   that can happen regardless of 
whether equatable is an opt-in thing or automatic. For example, let's say you 
opt-in by saying that it implements Equatable or by using the derived / 
synthesizes keyword that we have mentioned. The developer may not realize until 
later that the default implementation would be wrong for your fancy/unusual 
struct.  It is likely that opting in may raise a flag in your brain that says 
"hey, is the default implementation going to do the right thing? Do you need to 
customize it for your struct?" But it's not a guarantee either. And if it's not 
a guarantee then should it be automatic then? Most developer will go with the 
default implementation when they opt-in and then realize later that they may 
need to customize when things are not working quite the way the expected. 


>> 
>> 
 On May 26, 2016, at 11:35 AM, Matthew Johnson via swift-evolution 
  wrote:
 
 
 On May 26, 2016, at 10:18 AM, T.J. Usiyan via swift-evolution 
  wrote:
 
 +1 to a `deriving` keyword
>>> 
>>> + 1.  I like it as well.  It makes the feature opt-in, declaring 
>>> conformance and requesting synthesis at the same time.  The syntactic 
>>> difference from a simple conformance declaration means manual conformance 
>>> can still be checked properly with no ambiguity about whether you were 
>>> requesting synthesis or not.  This approach also generalizes well.
>>> 
>>> This bullet makes me uncomfortable though:
>>> 
 - It is compatible with generics. E.g. `struct Shape deriving 
 Equatable` will make every `Shape` equatable if `X` is equatable. But 
 if `X` is not equatable, `Shape` can be used as well. 
>>> 
>>> 
>>> You should not be able to just say `struct Shape deriving Equatable`.  
>>> You should have to do this:
>>> 
>>> extension Shape deriving Equatable where T: Equatable {}
>>> 
>>> Or some equivalent syntax that makes it clear that you only intend to 
>>> derive equatable when T meets the stated conditions.
>>> 
 
> On Thu, May 26, 2016 at 3:58 AM, Michael Peternell via swift-evolution 
>  wrote:
> Can we just copy the solution from Haskell instead of creating our 
> own? It's just better in every aspect. Deriving `Equatable` and 
> `Hashable` would become
> 
> struct Polygon deriving Equatable, Hashable {
> ...
> }
> 
> This has several advantages:
> - you don't have to guess wether `Equatable` or `Hashable` should be 
> automatically derived or not.
> - Deriving becomes an explicit choice.
> - If you need a custom `Equatable` implementation (for whatever reason), 
> you can still do it.
> - It doesn't break any code that is unaware of the change
> - It can be extended in future versions of Swift, without introducing any 
> new incompatibilities. For example, `CustomStringConvertible` could be 
> derived just as easily.
> - It is compatible with generics. E.g. `struct Shape deriving 
> Equatable` will make every `Shape` equatable if `X` is equatable. But 
> if `X` is not equatable, `Shape` can be used as well. (Unless `X` is 
> not used, in which case every `Shape` would be equatable. Unless 
> something in the definition of `Shape` makes deriving `Equatable` 
> impossible => this produces an error.)
> - It is proven to work in production.
> 
> -Michael
> 
> > Am 26.05.2016 um 03:48 schrieb Mark Sands via swift-evolution 
> > :
> >
> > Thanks so much for putting this together, Tony! Glad I was able to be 
> > some inspiration. :^)
> >
> >

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

[Ricardo Parada via swift-evolution]

> 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 other day and my code to get a value given the property 
name looked more like this:

let age = myPerson.value(forKey:”age”) as! Int

And this is what I did:

// KVC stands for key-value-coding… but I only know how to get values.  I don’t 
know how to set values

protocol KVC {
   func value(forKey key: String) -> Any!
}

// Default implementation
extension KVC {
   func value(forKey key: String) -> Any! {
   let aMirror = Mirror(reflecting:self)
   for case let (label?, value) in aMirror.children {
   if label == key {
   return value
   }
   }
   return nil
   }
}

public struct Person : KVC {
   let firstName: String
   let lastName: String
   let age: Int

   func fullName() -> String {
   return "\(firstName) \(lastName)"
   }
}

let aPerson = Person(firstName:"John", lastName:"Doe", age:48)

// It works for stored properties
let lastName = aPerson.value(forKey:"lastName") as! String
print("Last name is \(lastName)")

// It does not work for instance methods, i.e. fullName is not a stored property
let fullName = aPerson.value(forKey:"fullName")
if fullName != nil {
   print("Full name is \(fullName)")
} else {
   print("Unable to get fullName via KVC")
}



___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ricardo Parada via swift-evolution]

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-evolution 
>  wrote:
> 
>> 
>> On May 26, 2016, at 10:18 AM, T.J. Usiyan via swift-evolution 
>> > wrote:
>> 
>> +1 to a `deriving` keyword
> 
> + 1.  I like it as well.  It makes the feature opt-in, declaring conformance 
> and requesting synthesis at the same time.  The syntactic difference from a 
> simple conformance declaration means manual conformance can still be checked 
> properly with no ambiguity about whether you were requesting synthesis or 
> not.  This approach also generalizes well.
> 
> This bullet makes me uncomfortable though:
> 
>> - It is compatible with generics. E.g. `struct Shape deriving Equatable` 
>> will make every `Shape` equatable if `X` is equatable. But if `X` is not 
>> equatable, `Shape` can be used as well. 
> 
> 
> You should not be able to just say `struct Shape deriving Equatable`.  You 
> should have to do this:
> 
> extension Shape deriving Equatable where T: Equatable {}
> 
> Or some equivalent syntax that makes it clear that you only intend to derive 
> equatable when T meets the stated conditions.
> 
>> 
>> On Thu, May 26, 2016 at 3:58 AM, Michael Peternell via swift-evolution 
>> > wrote:
>> Can we just copy the solution from Haskell instead of creating our 
>> own? It's just better in every aspect. Deriving `Equatable` and `Hashable` 
>> would become
>> 
>> struct Polygon deriving Equatable, Hashable {
>> ...
>> }
>> 
>> This has several advantages:
>> - you don't have to guess wether `Equatable` or `Hashable` should be 
>> automatically derived or not.
>> - Deriving becomes an explicit choice.
>> - If you need a custom `Equatable` implementation (for whatever reason), you 
>> can still do it.
>> - It doesn't break any code that is unaware of the change
>> - It can be extended in future versions of Swift, without introducing any 
>> new incompatibilities. For example, `CustomStringConvertible` could be 
>> derived just as easily.
>> - It is compatible with generics. E.g. `struct Shape deriving Equatable` 
>> will make every `Shape` equatable if `X` is equatable. But if `X` is not 
>> equatable, `Shape` can be used as well. (Unless `X` is not used, in which 
>> case every `Shape` would be equatable. Unless something in the definition 
>> of `Shape` makes deriving `Equatable` impossible => this produces an error.)
>> - It is proven to work in production.
>> 
>> -Michael
>> 
>> > Am 26.05.2016 um 03:48 schrieb Mark Sands via swift-evolution 
>> > >:
>> >
>> > Thanks so much for putting this together, Tony! Glad I was able to be some 
>> > inspiration. :^)
>> >
>> >
>> > On Wed, May 25, 2016 at 1:28 PM, Tony Allevato via swift-evolution 
>> > > wrote:
>> > I was inspired to put together a draft proposal based on an older 
>> > discussion in the Universal Equality, Hashability, and Comparability 
>> > thread > > > that 
>> > recently got necromanced (thanks Mark Sands!).
>> >
>> > I'm guessing that this would be a significant enough change that it's not 
>> > possible for the Swift 3 timeline, but it's something that would benefit 
>> > enough people that I want to make sure the discussion stays alive. If 
>> > there are enough good feelings about it, I'll move it from my gist into an 
>> > actual proposal PR.
>> >
>> > Automatically deriving Equatable andHashable for value types
>> >
>> >   • Proposal: SE-
>> >   • Author(s): Tony Allevato
>> >   • Status: Awaiting review
>> >   • Review manager: TBD
>> > Introduction
>> >
>> > Value types are prevalent throughout the Swift language, and we encourage 
>> > developers to think in those terms when writing their own types. 
>> > Frequently, developers find themselves writing large amounts of 
>> > boilerplate code to support equatability and hashability of value types. 
>> > This proposal offers a way for the compiler to automatically derive 
>> > conformance toEquatable and Hashable to reduce this boilerplate, in a 
>> > subset of scenarios where generating the correct implementation is likely 
>> > to be possible.
>> >
>> > Swift-evolution thread: Universal Equatability, Hashability, and 
>> > Comparability
>> >
>> > Motivation
>> >
>> > Building robust value types in Swift can involve writing significant 
>> > boilerplate code to support concepts of hashability and equatability. 
>> > Equality is pervasive 

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

[Ricardo Parada via swift-evolution]

When would the automatic implementation fail?

I see your point about adding to the compile size and I had previously 
mentioned that. Usually in the apps I develop that is not a concern. However I 
can see it could be a concern for apps that are more restrictive. If Swift is 
to be used to build such apps too then I agree that not being automatic would 
be important. It would have to be opt-in. I would be okay with that solution. 
Hopefully most would make use of it in high-level frameworks.

I guess similar to reflection and enabling dynamism. I look forward to 
eventually being able to do key-value-coding in pure Swift and being able to 
implement a framework similar to WebObjects which would require being able to 
find properties by their name, getting and setting values. That would be 
another example of opting in for a richer run-time. 


> On May 27, 2016, at 10:11 AM, Patrick Smith <pgwsm...@gmail.com> wrote:
> 
> If you have to specify Equatable / Hashable, then you can get an error if the 
> automatic implementation failed, due to a member also not being 
> Equatable/Hashable. If it’s automatic, then it will just quietly fail, making 
> problems harder to know about and track. It will also always add to the 
> compile size, even if you didn’t want the functionality.
> 
> 
>> On 27 May 2016, at 10:46 PM, Ricardo Parada <rpar...@mac.com> wrote:
>> 
>> I agree, I think there is no need for deriving/synthesizes, but also, no 
>> need to specify Equatable, Hashable. They should get the functionality by 
>> default but allow for override and customization. 
>> 
>> 
>>> On May 26, 2016, at 11:02 PM, Patrick Smith <pgwsm...@gmail.com> wrote:
>>> 
>>> I don’t understand why you couldn’t conform to Equatable, and if it 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 yourself.
>>> 
>>> 
>>>> On 27 May 2016, at 12:57 PM, Ricardo Parada via swift-evolution 
>>>> <swift-evolution@swift.org> wrote:
>>>> 
>>>> 
>>>> 
>>>> I wonder if synthesizes would be a better choice than deriving. 
>>>> 
>>>> 
>>>> 
>>>>> On May 26, 2016, at 5:58 AM, Michael Peternell via swift-evolution 
>>>>> <swift-evolution@swift.org> wrote:
>>>>> 
>>>>> Can we just copy the solution from Haskell instead of creating our 
>>>>> own? It's just better in every aspect. Deriving `Equatable` and 
>>>>> `Hashable` would become
>>>>> 
>>>>> struct Polygon deriving Equatable, Hashable {
>>>>>...
>>>>> }
>>>>> 
>>>>> This has several advantages:
>>>>> - you don't have to guess wether `Equatable` or `Hashable` should be 
>>>>> automatically derived or not.
>>>>> - Deriving becomes an explicit choice.
>>>>> - If you need a custom `Equatable` implementation (for whatever reason), 
>>>>> you can still do it.
>>>>> - It doesn't break any code that is unaware of the change
>>>>> - It can be extended in future versions of Swift, without introducing any 
>>>>> new incompatibilities. For example, `CustomStringConvertible` could be 
>>>>> derived just as easily.
>>>>> - It is compatible with generics. E.g. `struct Shape deriving 
>>>>> Equatable` will make every `Shape` equatable if `X` is equatable. But 
>>>>> if `X` is not equatable, `Shape` can be used as well. (Unless `X` is 
>>>>> not used, in which case every `Shape` would be equatable. Unless 
>>>>> something in the definition of `Shape` makes deriving `Equatable` 
>>>>> impossible => this produces an error.)
>>>>> - It is proven to work in production.
>>>>> 
>>>>> -Michael
>>>>> 
>>>>>> Am 26.05.2016 um 03:48 schrieb Mark Sands via swift-evolution 
>>>>>> <swift-evolution@swift.org>:
>>>>>> 
>>>>>> Thanks so much for putting this together, Tony! Glad I was able to be 
>>>>>> some inspiration. :^)
>>>>>> 
>>>>>> 
>>>>>> On Wed, May 25, 2016 at 1:28 PM, Tony Allevato via swift-evolution 
>>>>>> <swift-evolution@swift.org> wrote:
>>>>>> I was insp

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

[Ricardo Parada via swift-evolution]

I agree, I think there is no need for deriving/synthesizes, but also, no need 
to specify Equatable, Hashable. They should get the functionality by default 
but allow for override and customization. 


> On May 26, 2016, at 11:02 PM, Patrick Smith <pgwsm...@gmail.com> wrote:
> 
> I don’t understand why you couldn’t conform to Equatable, and if it 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 yourself.
> 
> 
>> On 27 May 2016, at 12:57 PM, Ricardo Parada via swift-evolution 
>> <swift-evolution@swift.org> wrote:
>> 
>> 
>> 
>> I wonder if synthesizes would be a better choice than deriving. 
>> 
>> 
>> 
>>> On May 26, 2016, at 5:58 AM, Michael Peternell via swift-evolution 
>>> <swift-evolution@swift.org> wrote:
>>> 
>>> Can we just copy the solution from Haskell instead of creating our 
>>> own? It's just better in every aspect. Deriving `Equatable` and `Hashable` 
>>> would become
>>> 
>>> struct Polygon deriving Equatable, Hashable {
>>>...
>>> }
>>> 
>>> This has several advantages:
>>> - you don't have to guess wether `Equatable` or `Hashable` should be 
>>> automatically derived or not.
>>> - Deriving becomes an explicit choice.
>>> - If you need a custom `Equatable` implementation (for whatever reason), 
>>> you can still do it.
>>> - It doesn't break any code that is unaware of the change
>>> - It can be extended in future versions of Swift, without introducing any 
>>> new incompatibilities. For example, `CustomStringConvertible` could be 
>>> derived just as easily.
>>> - It is compatible with generics. E.g. `struct Shape deriving Equatable` 
>>> will make every `Shape` equatable if `X` is equatable. But if `X` is not 
>>> equatable, `Shape` can be used as well. (Unless `X` is not used, in 
>>> which case every `Shape` would be equatable. Unless something in the 
>>> definition of `Shape` makes deriving `Equatable` impossible => this 
>>> produces an error.)
>>> - It is proven to work in production.
>>> 
>>> -Michael
>>> 
>>>> Am 26.05.2016 um 03:48 schrieb Mark Sands via swift-evolution 
>>>> <swift-evolution@swift.org>:
>>>> 
>>>> Thanks so much for putting this together, Tony! Glad I was able to be some 
>>>> inspiration. :^)
>>>> 
>>>> 
>>>> On Wed, May 25, 2016 at 1:28 PM, Tony Allevato via swift-evolution 
>>>> <swift-evolution@swift.org> wrote:
>>>> I was inspired to put together a draft proposal based on an older 
>>>> discussion in the Universal Equality, Hashability, and Comparability 
>>>> thread <http://thread.gmane.org/gmane.comp.lang.swift.evolution/8919/> 
>>>> that recently got necromanced (thanks Mark Sands!).
>>>> 
>>>> I'm guessing that this would be a significant enough change that it's not 
>>>> possible for the Swift 3 timeline, but it's something that would benefit 
>>>> enough people that I want to make sure the discussion stays alive. If 
>>>> there are enough good feelings about it, I'll move it from my gist into an 
>>>> actual proposal PR.
>>>> 
>>>> Automatically deriving Equatable andHashable for value types
>>>> 
>>>>• Proposal: SE-
>>>>• Author(s): Tony Allevato
>>>>• Status: Awaiting review
>>>>• Review manager: TBD
>>>> Introduction
>>>> 
>>>> Value types are prevalent throughout the Swift language, and we encourage 
>>>> developers to think in those terms when writing their own types. 
>>>> Frequently, developers find themselves writing large amounts of 
>>>> boilerplate code to support equatability and hashability of value types. 
>>>> This proposal offers a way for the compiler to automatically derive 
>>>> conformance toEquatable and Hashable to reduce this boilerplate, in a 
>>>> subset of scenarios where generating the correct implementation is likely 
>>>> to be possible.
>>>> 
>>>> Swift-evolution thread: Universal Equatability, Hashability, and 
>>>> Comparability
>>>> 
>>>> Motivation
>>>> 
>>>> Building robust v

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

[Ricardo Parada via swift-evolution]

As Steve Jobs once said when demoing Interface Builder during the NeXT days: 
"The line of code you don't have to write is the line of code you don't have to 
debug."

P.S. I hope I got the quote right, but that was the idea. :-)





Sent from my iPhone

> On May 25, 2016, at 10:02 PM, Patrick Smith via swift-evolution 
>  wrote:
> 
> This would be very handy! It’s one of those rare scenarios where I think “I 
> can’t believe Swift makes me type all this out, there must be an easier way”.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution