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

[Dave Yost via swift-evolution]

> On May 26, 2017, at 9:47 AM, Dave Yost  wrote:
> 
> Btw I don't mean for the close quote delimiter to be the only thing on the 
> line, as one might expect by analogy with shell syntax.

Sorry, to be clearer the close quote delimiter must be the first thing on the 
line following indenting whitespace, but it need not be the last thing on the 
line.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Dave Yost via swift-evolution]

I regret that I didn't send my two proposals much earlier, but I was operating 
under the assumption that Swift 4 was not going to include changes such as 
this, so I thought I should wait and was surprised to stumble on this change. 
(I wonder if anyone else is in the same boat.)

If people are not sure the existing commit is optimal, certainly it would make 
sense for it to be backed out sooner rather than later.

Btw I don't mean for the close quote delimiter to be the only thing on the 
line, as one might expect by analogy with shell syntax.

Dave

> On May 25, 2017, at 11:24 PM, Robert Widmann  wrote:
> 
> A quick question since we’ve already accepted this proposal and have an 
> implementation in-tree: do you expect this breaking change to be accepted for 
> Swift 4, or do you expect this change to break everybody once they’ve already 
> migrated to the triple-quoted string form in a future release?
> 
> ~Robert Widmann
> 
>> On May 25, 2017, at 11:02 PM, Dave Yost via swift-evolution 
>>  wrote:
>> 
>> 
>> Beauty is a top-three goal of Swift, so a proposal that is not beautiful 
>> should be rethought until it is.
>> 
>> 1. """ is ugly.
>> 
>> 2. Choosing syntax so as to pander to hacks in a few existing tools is the 
>> road to Ugly.
>> 
>> 3. It’s inelegant syntax design for start and end delimiters to be 
>> identical, as for example ASCII quote marks are.[1]
>> 
>> 4. Mirror image start and end delimiters are preferred, for example { and 
>> }.[1]
>> 
>> 5. Escaping is ugly and preferably should not be necessary or even allowed.
>> 
>> Therefore, I propose, by example:
>> 
>>   let foo = 
>> /"xx
>> The indent of /"
>> dictates indentation and must match 
>> all indents through the "/
>> "/xx
>> 
>> where an optional arbitrary identifier, for example “xx”, can be appended to 
>> both the open and the close quote delimiters to avoid the need for escaping 
>> the close quote delimiter. The identifier has no other significance in the 
>> program.
>> 
>> I further propose that /' and '/ should be used to delimit a string that is 
>> interpreted literally, including newlines except for the newline on the last 
>> line of the string.
>> 
>> In future, consideration should be given to the idea of following the /" 
>> delimiter by a set of space-separated flags to determine treatment of 
>> newlines, the escape character (so it doesn’t have to be backslash), use of 
>> interpolated strings, the use of escape characters, etc.
>> 
>> Dave
>> 
>> (I intended all single and double quotes in this message to be ASCII, not 
>> curly. If any are curly, then blame the macOS Mail app.)
>> 
>> [1].  I think Swift should allow delimiting strings with “curly” quotes, and 
>> they should nest. See 3, 4, 5 above.
>> 
>> ___
>> 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-0168: Multi-Line String Literals

[Adrian Zubarev via swift-evolution]

Well /" "/ is far from being the queen of the beautiful syntaxes.

I summed up my thoughts in the following two gists:

https://gist.github.com/DevAndArtist/d9282e032ee241cfd1a403961cedffdf
https://gist.github.com/DevAndArtist/0c95f8549bb7d97387b360b4cfb3e09e
David Hart and I are patiently waiting for post WWDC to see how the broader 
mass will react to the accepted changes. Furthermore, Chris Lattner said that 
he views WWDC betas as the way to figure out if proposals need to be fixed 
before release.



-- 
Adrian Zubarev
Sent with Airmail

Am 26. Mai 2017 um 08:02:28, Dave Yost via swift-evolution 
(swift-evolution@swift.org) schrieb:


Beauty is a top-three goal of Swift, so a proposal that is not beautiful should 
be rethought until it is.

1. """ is ugly.

2. Choosing syntax so as to pander to hacks in a few existing tools is the road 
to Ugly.

3. It’s inelegant syntax design for start and end delimiters to be identical, 
as for example ASCII quote marks are.[1]

4. Mirror image start and end delimiters are preferred, for example { and }.[1]

5. Escaping is ugly and preferably should not be necessary or even allowed.

Therefore, I propose, by example:

  let foo = 
    /"xx
    The indent of /"
        dictates indentation and must match 
    all indents through the "/
    "/xx

where an optional arbitrary identifier, for example “xx”, can be appended to 
both the open and the close quote delimiters to avoid the need for escaping the 
close quote delimiter. The identifier has no other significance in the program.

I further propose that /' and '/ should be used to delimit a string that is 
interpreted literally, including newlines except for the newline on the last 
line of the string.

In future, consideration should be given to the idea of following the /" 
delimiter by a set of space-separated flags to determine treatment of newlines, 
the escape character (so it doesn’t have to be backslash), use of interpolated 
strings, the use of escape characters, etc.

Dave

(I intended all single and double quotes in this message to be ASCII, not 
curly. If any are curly, then blame the macOS Mail app.)

[1].  I think Swift should allow delimiting strings with “curly” quotes, and 
they should nest. See 3, 4, 5 above.

___
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-0168: Multi-Line String Literals

[Robert Widmann via swift-evolution]

A quick question since we’ve already accepted this proposal and have an 
implementation in-tree: do you expect this breaking change to be accepted for 
Swift 4, or do you expect this change to break everybody once they’ve already 
migrated to the triple-quoted string form in a future release?

~Robert Widmann

> On May 25, 2017, at 11:02 PM, Dave Yost via swift-evolution 
>  wrote:
> 
> 
> Beauty is a top-three goal of Swift, so a proposal that is not beautiful 
> should be rethought until it is.
> 
> 1. """ is ugly.
> 
> 2. Choosing syntax so as to pander to hacks in a few existing tools is the 
> road to Ugly.
> 
> 3. It’s inelegant syntax design for start and end delimiters to be identical, 
> as for example ASCII quote marks are.[1]
> 
> 4. Mirror image start and end delimiters are preferred, for example { and 
> }.[1]
> 
> 5. Escaping is ugly and preferably should not be necessary or even allowed.
> 
> Therefore, I propose, by example:
> 
>   let foo = 
> /"xx
> The indent of /"
> dictates indentation and must match 
> all indents through the "/
> "/xx
> 
> where an optional arbitrary identifier, for example “xx”, can be appended to 
> both the open and the close quote delimiters to avoid the need for escaping 
> the close quote delimiter. The identifier has no other significance in the 
> program.
> 
> I further propose that /' and '/ should be used to delimit a string that is 
> interpreted literally, including newlines except for the newline on the last 
> line of the string.
> 
> In future, consideration should be given to the idea of following the /" 
> delimiter by a set of space-separated flags to determine treatment of 
> newlines, the escape character (so it doesn’t have to be backslash), use of 
> interpolated strings, the use of escape characters, etc.
> 
> Dave
> 
> (I intended all single and double quotes in this message to be ASCII, not 
> curly. If any are curly, then blame the macOS Mail app.)
> 
> [1].  I think Swift should allow delimiting strings with “curly” quotes, and 
> they should nest. See 3, 4, 5 above.
> 
> ___
> 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] SE-0168: Multi-Line String Literals

[Dave Yost via swift-evolution]

Beauty is a top-three goal of Swift, so a proposal that is not beautiful should 
be rethought until it is.

1. """ is ugly.

2. Choosing syntax so as to pander to hacks in a few existing tools is the road 
to Ugly.

3. It’s inelegant syntax design for start and end delimiters to be identical, 
as for example ASCII quote marks are.[1]

4. Mirror image start and end delimiters are preferred, for example { and }.[1]

5. Escaping is ugly and preferably should not be necessary or even allowed.

Therefore, I propose, by example:

  let foo = 
/"xx
The indent of /"
dictates indentation and must match 
all indents through the "/
"/xx

where an optional arbitrary identifier, for example “xx”, can be appended to 
both the open and the close quote delimiters to avoid the need for escaping the 
close quote delimiter. The identifier has no other significance in the program.

I further propose that /' and '/ should be used to delimit a string that is 
interpreted literally, including newlines except for the newline on the last 
line of the string.

In future, consideration should be given to the idea of following the /" 
delimiter by a set of space-separated flags to determine treatment of newlines, 
the escape character (so it doesn’t have to be backslash), use of interpolated 
strings, the use of escape characters, etc.

Dave

(I intended all single and double quotes in this message to be ASCII, not 
curly. If any are curly, then blame the macOS Mail app.)

[1].  I think Swift should allow delimiting strings with “curly” quotes, and 
they should nest. See 3, 4, 5 above.

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

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

[Dave Yost via swift-evolution]

I corresponded with Steve Bourne about here docs a while ago. He said

He said the only reason that indenting was not supported in his shell is that 
he didn’t think of it and neither did the other guys at Cambridge from whom he 
got the idea. And,

> I never considered the indent idea.  It’s a good idea although I don’t like 
> the idea of post processing the temp file to remove the leading white space.  
> I agree the way it is now is not easy to look at and I can't think of a way 
> to have the ident amount specified in advance of reading the document.


He liked this idea: The proposal could be extended so that if the open quote 
marking appears on a line by itself, the indentation on that line rules, and 
all lines through the close quote marking must have the same indenting.

  let foo = 
"""
indent of initial quote
dictates indentation
and must match 
indent of trailing quote
"""

If that proposal is adopted, then there are two alternatives if the open quote 
marking does not appear on a line by itself:
1. The indent is dictated by the close quote marking (current proposal). The 
coder can choose to take the parser performance hit, with apologies to srb.
2. There is no indenting and the close quote must appear flush left. (I don’t 
like this alternative.)

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