If we use triple quotes (i.e. """) at the beginning of the multi line string
literal and again at the end, it seems very unlikely that the heredoc notation
would be needed.
I would simplify and remove the heredoc alternative from the proposal.
Also, for those of us who like the continuation quotes, I think the
continuation quotes could be optional. For example this:
let html = """<html>
". <body>
" <h1>\(title)<h1>
". <p class="fancy">A paragraph.<p>
". </body>
"</html>
"""
would be equivalent to:
let html = """<html>
. <body>
<h1>\(title)<h1>
. <p class="fancy">A paragraph.<p>
. </body>
</html>
"""
What do you think?
> On May 5, 2016, at 2:13 PM, L Mihalkovic via swift-evolution
> <[email protected]> wrote:
>
>
>> On May 5, 2016, at 12:30 PM, Michael Peternell via swift-evolution
>> <[email protected]> wrote:
>>
>> Hi,
>>
>> it's not a secret that I'm not a big fan of the proposal. The third draft
>> doesn't change this and it's unlikely that any future draft will, because
>> for me, the problem are the continuation quotes, and for Brent it seems like
>> they are a must-have-feature (correct me if I'm wrong.)
>>
>> I just wanted to say that I have drafted a proposal that solves the issues
>> that I have encountered. (It's here:
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160425/016219.html
>> )
>> - it allows pasting text as-is
>> - it allows creating string literals where leading space on each line is
>> stripped (while keeping indentation differences intact)
>> - it allows creating string literals where leading space on each line is not
>> stripped
>> - optionally it allows strings to be raw, without any string interpolation
>> or escaping whatsoever
>> - in none of the literals you have to write "<book id=\"bk101\"
>> empty=\"\">", you can just write """<book id="bk101" empty="">""". This also
>> lets you copy&paste text out of the program source and back into a HTML file.
>>
>> It had the idea that maybe the motivation behind continuation quotes is to
>> make using multiline strings harder to use; in order to discourage their use
>> at all. Two points to consider:
>> - people who don't want to use MSL will not, even if you throw Python-like
>> """multi-line strings""" at them.
>> - people who want to use them do it, even if there is no MSL available. I
>> saw that in Objective-C, with multiple lines of HTML and CSS wrapped into a
>> big multiline objc-string-literal and thrown at a WebView. I could send the
>> literal to the console before sending it to the WebView and it was basically
>> unreadable. I eventually refactored it to put the thing into a file (also
>> because the HTML grew in space, and the inline-literal became impractical)
>> - my most important point: if someone uses multiple lines of HTML or CSS or
>> XML directly within the code, I want it to look okay. I don't want an MSL
>> feature that is so unwieldy that people voluntarily not use it; it would be
>> better to have no MSL at all.
>>
>> I don't think that multiline strings are a must-have feature for a language,
>> because they are not used very often. (I included an example of a good use
>> case in my proposal.) I acknowledge that in many programming cases it would
>> be better to not put a huge pile of text directly into the source, but to
>> load the text from a file at runtime. But even when these MSL are misused, I
>> prefer to read a """python multiline string""" over a
>> "concatenated\n"+"Java\n"+"String".
>>
>> -Michael
>
>
> Hi Michael. hope this helps
> https://gist.github.com/lmihalkovic/11f2b1b23b78bbb9cbf0292ffc480b3d
>
>
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
