<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div>Whops sorry I got the symbols mixed up, Swift's macro system uses "%", but the preprocessor uses "#". By using "#" as a delimiter, the lexer would have to be adjusted quite a bit to work for both literals and the preprocessor.</div><div><br>On 12 Dec 2015, at 02:09, Kametrixom Tikara via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div></div><div>This would probably conflict with Swift's non-official (hopefully official in the future) macro-system (the .gyb files), which makes heavy use of "#".</div><div><br>On 12 Dec 2015, at 01:13, Marc Knaup via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">What about <font face="monospace, monospace">#</font>?<div><br></div><div><font face="monospace, monospace">###</font></div><div><font face="monospace, monospace">string</font></div><div><font face="monospace, monospace">###</font></div><div><br></div><div>If your string does contain "<font face="monospace, monospace">###</font>" you can simply guard the string with more # until it fits. Must be symmetrical though. No escaping necessary.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Dec 12, 2015 at 1:08 AM, Travis Tilley via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">Ah. My sincerest apologies for making that assumption then.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Your suggestion doesn't solve my use case, personally. I'm also <i>hoping</i> to officially propose something less complex than heredocs once there's been enough feedback.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">-Travis Tilley</div><span class=""><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 11, 2015 at 5:52 PM, Brent Royal-Gordon <span dir="ltr"><<a href="mailto:brent@architechies.com" target="_blank">brent@architechies.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>> I'm not entirely sure how to respond to this, but I think some of your suggestions might go against the goal of having less noise in defining a multi-line string. It's actually more to type than:<br>
> "this is the first line \n" +<br>
> "this is the second line \n"<br>
> ...which we can already do.<br>
><br>
> Your suggestion that each line should end in \n makes me think you're actually trying to have a bit of fun with me, but I can't really tell and I really don't want to be rude by making that assumption.<br>
<br>
</span>I am being serious. This proposal does require more characters, it’s true. However, it doesn’t require more *reading*—because the leading indicators will generally line up, you can ignore them and read everything to the right, like the “> “ used to demarcate your text above from my text—and with an editor feature to select several lines and quote them (the way you can with comments in most editors), it wouldn’t require more *writing* either. And although it uses more characters, it *also* unmistakably sets off quoted material from code, comments, other multiline string literals, and anything else, while being unambiguous about whether indentation is intended to style the literal or be part of it, without a bunch of funky obscure modifier characters like "<<-END".<br>
<br>
The \n thing was an idle thought being presented for discussion, not a concrete suggestion, but it was also not a joke. (I realized after sending it, however, that the trailing newline problem can be solved by simply having a rule that you strip one trailing newline. If you want your string to end with a newline, include a sacrificial blank “Foo>” line at the end of the literal. Some sort of modifier to indicate the trailing newline behavior is possible too, but see the previous paragraph for my thoughts on those.)<br>
<br>
I’ve used and loved heredocs in Perl and Ruby, but I always understood that they have significant problems. That experience shaped this proposal.<br>
<span><font color="#888888"><br>
--<br>
Brent Royal-Gordon<br>
Architechies<br></font></span></blockquote></div>
</div></span></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=6ZGE61OxINd5lLe2xYh9Ku-2BXbixWNr2nvfzp2IB1sZhF5OtlN9KLh14-2BQCU672scOtprmdWZTZFupNu4qHmT2-2FKHJY1n7IPILplbGZZjHmctk4tego7kFHtu1GFt70DO7zfo90eVFeTt-2F8fgD1neE725-2Fq0ZlWefP0F-2FmgjnYWB3-2FdKf-2B1OVBYxdr4CwM7xPsm4Qi-2BZbmw9LBhJkPmLuSw-3D-3D" alt="" width="1" height="1" border="0" style="min-height:1px!important;width:1px!important;border-width:0!important;margin-top:0!important;margin-bottom:0!important;margin-right:0!important;margin-left:0!important;padding-top:0!important;padding-bottom:0!important;padding-right:0!important;padding-left:0!important">
<br>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=UMghxGHOvTEcVGG3PKHzuJe-2F1jwKPcDcSNH0SiRhP15drJL9DhT9ph3I4Eh8ib8g4faMxAZFembvj3CarjoKYYIGQLSVtaL9Z4NhXa-2F5URRXp3FLkFTvL8JVjwomFnvIJiSKsXD9sTQTwCiy67uReTXuyZcM7-2B1-2FiAPNLtCKd-2FBAn7Pm5vtYkf1R4HZW3Bwi4HOiisuJf7PVigl0-2FVNaEEOtIgkgJp77wXr5krWI3Xg-3D" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;">
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=UMghxGHOvTEcVGG3PKHzuJe-2F1jwKPcDcSNH0SiRhP16Qbz31M16pElP5CuV3CfKQweDPGzhQ906EgtImaMJUPRAyJVA16zJPrq0AZzc9GSS0r4VOGuLmmq3KzxalcBrUf3GCnFwqRfPMVO7lSuM1w0j0HX9yw2gKPEWTwulycgyV03ZOTPhJZ6BTWpnB3Pe-2F-2Fd9j0XtLg4IshsFdICIIT0hvriHkTWzrwH2HP5lsy9A-3D" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;">
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>