<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 13, 2015, at 10:31 PM, Alex Gordon via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">If Swift is ever going to have multi-line string literals, type affixes should be a prefix and not a suffix. Otherwise the suffix would get lost at the end of a long string.</div></div></div></blockquote><div><br class=""></div><div>Now that you mention it, I completely agree, great point.</div><div><br class=""></div><div>-Chris</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class=""><div class="">A nice extra use for affixes is as metadata so that your editor can do syntax highlighting. When I write r"..." in Python (for a raw string), my editor assumes that it is a regex and gives regex-specific highlighting. For SQL, it can only take a guess from the content.</div><div class=""><br class=""></div><div class="">So I can see re"[a-z0-9]+" and sql"select * from table" adding value, even if the latter is just a pass-through.</div><div class=""><br class=""></div><div class="">As far as raw strings go, the general feeling in the multi-line strings thread was to either go for single quotes or backticks. If backticks, it could married with this proposal as follows: any prefix + backticks = raw string. e.g.</div><div class=""><br class=""></div><div class="">r`raw string "quotes"` // raw string</div><div class="">re`<a href="[^"]+">` // raw regex literal</div><div class=""><span class=""><br class=""></span></div>
<div class=""><div class="">- Alex</div></div></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Sat, Dec 12, 2015 at 9:19 PM, Kevin Ballard via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u class=""></u>
<div class=""><div class="">I think you're reading too much into that one example. That was a demonstration of where the ambiguity between Character and UnicodeScalar matters, not the sole reason to use this. Suffice to say, I've hit the ambiguity error between Characters and UnicodeScalars often enough to consider it worth addressing.<br class=""></div>
<div class=""> </div>
<div class="">-Kevin</div><div class=""><div class="h5">
<div class=""> </div>
<div class="">On Sat, Dec 12, 2015, at 03:26 AM, ilya via swift-evolution wrote:<br class=""></div>
<blockquote type="cite" class=""><div dir="ltr" class=""><div class="">> var s = ""<br class=""></div>
<div class="">> s.append("c")<br class=""></div>
<div class="">><br class=""></div>
<div class="">> This code looks pretty straightforward,<br class=""></div>
<div class=""> </div>
<div class="">This looks to me like you're adding a string, which can be done via <br class=""></div>
<div class=""> </div>
<div class="">s += "c"<br class=""></div>
<div class=""> </div>
<div class="">Yes, I know adding a character can theoretically be a bit more performant, but why would that be a consideration for static strings? Compiler should optimize both expressions above to the same result.<br class=""></div>
<div class=""> </div>
<div class="">> UInt : u // or uint<br class=""></div>
<div class="">> Int16 : i16<br class=""></div>
<div class="">> Int32 : i32<br class=""></div>
<div class=""> </div>
<div class="">I think <br class=""></div>
<div class=""> </div>
<div class="">let number = 56i32<br class=""></div>
<div class=""> </div>
<div class="">is much less readable than <br class=""></div>
<div class=""> </div>
<div class="">let number: Int32 = 56<br class=""></div>
<div class=""> </div>
<div class="">so probably best not to encourage it.<br class=""></div>
<div class=""> </div>
</div>
<div class=""><div class=""> </div>
<div class=""><div class="">On Sat, Dec 12, 2015 at 1:48 AM, Marc Knaup via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""></div>
<blockquote style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex" class=""><div dir="ltr" class=""><div class="">Too bad that string literals don't conform to a specific protocol.<br class=""></div>
<div class=""> </div>
<div class="">This would also be a nice but doesn't work:<br class=""></div>
<div class=""><p class=""><span style="font-family:monospace,' monospace'" class=""><span class="">// </span></span><span style="font-family:monospace,monospace" class="">StaticString:</span><span style="font-family:monospace,monospace" class=""></span><span style="font-family:monospace,monospace" class="">"An simple string designed to represent text that is 'knowable at compile-time'."<br class=""></span><span style="font-family:monospace,monospace" class="">extension</span><span style="font-family:monospace,monospace" class=""></span><span style="font-family:monospace,monospace" class="">StaticString</span><span style="font-family:monospace,monospace" class=""> {</span></p><p class=""><span style="font-family:monospace,' monospace'" class=""><span class=""> var</span><span class=""> x: </span><span class="">Int</span><span class=""> {<br class=""></span><span class=""> return</span><span class=""></span><span class="">123<br class=""></span> }<br class="">}<br class=""><span class=""><br class="">print</span><span class="">(</span><span class="">"abc"</span><span class="">.x)</span></span></p></div>
</div>
<div class=""><div class=""><div class=""><div class=""> </div>
<div class=""><div class="">On Fri, Dec 11, 2015 at 11:38 PM, Joe Groff via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""></div>
<blockquote style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex" class=""><div class="">I was a little disappointed something like this didn't already work:<br class=""></div>
<div class=""> </div>
<div class="">
struct Foo: StringLiteralConvertible { var f: Foo { return self } }<br class=""></div>
<div class="">
struct Bar: StringLiteralConvertible { var b: Bar { return self } }<br class=""></div>
<div class=""> </div>
<div class="">
"x".f // currently a failed lookup in String; could produce a Foo<br class=""></div>
<div class="">
"y".b // same, for Bar<br class=""></div>
<div class=""> </div>
<div class="">
-Joe<br class=""></div>
<div class=""> <span class=""><br class="">
> On Dec 10, 2015, at 11:07 AM, Kevin Ballard via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class="">
><br class=""></span></div>
<div class=""><div class=""><div class="">> The fact that Swift uses the exact same syntax ("a") for String, Character, and UnicodeScalar can get annoying at times. When unconstrained it's always String, and the only way to disambiguate between the two when used in a context that takes both Character and UnicodeScalar is to explicitly constraint it further, e.g. with `"a" as Character`. A trivial example of this in action is<br class=""></div>
<div class="">
><br class=""></div>
<div class="">
> var s = ""<br class=""></div>
<div class="">
> s.append("c")<br class=""></div>
<div class="">
><br class=""></div>
<div class="">
> This code looks pretty straightforward, but it throws an ambiguity error (and the annoying part is, it doesn't actually matter which way it's resolved, the behavior is the same).<br class=""></div>
<div class="">
><br class=""></div>
<div class="">
> Having to type `"c" as Character` and `"c" as UnicodeScalar` can get pretty annoying if you have to do it a lot. It would be great to reduce this typing a bit.<br class=""></div>
<div class="">
><br class=""></div>
<div class="">
> My initial proposal here is to introduce string literal suffixes. Let me type something like `"c"c` for a Character and `"c"us` for a UnicodeScalar (and maybe `"c"s` to explicitly mean a String, although that's the default if unconstrained). AFAIK this is not ambiguous with the current syntax, as I don't believe it's ever legal to put an identifier like that after a string.<br class=""></div>
<div class="">
><br class=""></div>
<div class="">
> Ideally this could be extended by library code with new suffixes. The obvious way to do that is to allow for a new type of "operator" declaration, perhaps something like `literal operator c { type Character }` (where `literal` is a context-sensitive keyword), which declares the suffix and the type (the actual type construction will be done with StringLiteralConvertible, StringInterpolationConvertible, UnicodeScalarLiteralConvertible, or ExtendedGraphemeClusterLiteralConvertible). If the same suffix is declared in two different modules that are imported into the same program, they're unambiguous within their source modules, and within the parent module using the suffix operator will be ambiguous unless further constrained (e.g. similar to using a function that's overloaded on its return type).<br class=""></div>
<div class="">
><br class=""></div>
<div class="">
> One possible library use for this would be something like `"^\s*foo"r ` for a regular expression (although regular expressions probably also want some sort of "raw" string literal syntax to deal with escapes, but that's orthogonal to this proposal).<br class=""></div>
<div class="">
><br class=""></div>
<div class="">
> Syntax is up for debate. I picked postfix characters because I believe it's ambiguous and it has precedent, both in C's numeric literals, and in C++11's user-defined literals (although C++11 has a required underscore before the literal, I believe this is just to allow C++11 to define its own new suffixes without ambiguity). This syntax could also work for numeric literals, come to think of it, with the same declaration and using IntegerLiteralConvertible or FloatLiteralConvertible. Heck, it could work for array and dictionary literals too, though that's less likely to be useful.<br class=""></div>
<div class="">
><br class=""></div>
<div class="">
> FWIW, Playground color and image literals have the form [#Color(colorLiteralRed: 1, blue: 0, green: 0, alpha: 1)#] and [#Image(imageLiteral: "hi.png")#]. These are interesting, but don't solve the original problem (of having to type out the full type name) so this syntax is not appropriate for this feature (but the syntax is fine for what Playgrounds use it for, which is to embed literal colors/images into the source code).<br class=""></div>
<div class="">
><br class=""></div>
<div class="">
> -Kevin Ballard<br class=""></div>
<div class="">
> _______________________________________________<br class=""></div>
<div class="">
> swift-evolution mailing list<br class=""></div>
<div class="">
> <a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class=""></div>
<div class="">
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div>
<div class=""> </div>
<div class="">
_______________________________________________<br class=""></div>
<div class="">
swift-evolution mailing list<br class=""></div>
<div class=""> <a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class=""></div>
<div class=""> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div>
</div>
</div>
</blockquote></div>
<div class=""> </div>
</div>
</div>
</div>
<div class=""><img style="min-height:1px!important;width:1px!important;border-top-width:0px!important;border-right-width:0px!important;border-bottom-width:0px!important;border-left-width:0px!important;margin-top:0px!important;margin-bottom:0px!important;margin-right:0px!important;margin-left:0px!important;padding-top:0px!important;padding-bottom:0px!important;padding-right:0px!important;padding-left:0px!important" border="0" height="1" width="1" alt="" src="https://www.fastmailusercontent.com/proxy/fafb845a419772e6350c9cfbc9467eb4fbca434666071d51c515dc0560f54f7c/8647470737a3f2f25723030323431303e23647e23756e64676279646e2e65647f27766f2f60756e6f35707e6d3130793a4562723f463a6655493b47567f6d22324939655165497e48337c607439496a79796c4773766075343f4a40714c49616072366d22364e48446d2236426572536d223649634a5c4c4a4a7849743869694246603c48703172454758497473457658417b6d2236497d68325458393d2232427a717b423562623832564577613262797d2236417a587050536174333476735d4862594272407f4476635d2236484941476b467a5c4a53303376316551397659735e4d4236413d655d2236435167603a4d22324c623749303e435351763d22324a7768376465793478363153514264645242573c696352773559617565623a7d483354686035575b6c4532417d4d23344/open" class=""> <br class=""></div>
<div class="">_______________________________________________<br class=""></div>
<div class="">
swift-evolution mailing list<br class=""></div>
<div class=""> <a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class=""></div>
<div class=""> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div>
<div class=""> </div>
</blockquote></div>
</div>
<div class=""><img style="min-height:1px!important;width:1px!important;border-top-width:0px!important;border-right-width:0px!important;border-bottom-width:0px!important;border-left-width:0px!important;margin-top:0px!important;margin-bottom:0px!important;margin-right:0px!important;margin-left:0px!important;padding-top:0px!important;padding-bottom:0px!important;padding-right:0px!important;padding-left:0px!important" border="0" height="1" width="1" alt="" src="https://www.fastmailusercontent.com/proxy/ef4798b73b474ffd30ef5dcf38e7bed1d6145ee43227c0327356db6aa70b70cb/8647470737a3f2f25723030323431303e23647e23756e64676279646e2e65647f27766f2f60756e6f35707e6d3148765176786c673171614a7d2236454230345272776e485d22324848367d2236483666713f6e6568686172303a723173653b4d223240775668575f643365787055723c415f456f4c4a5564415a677333656971717f6d42316f4d2236464560523e65407f4677623965647a4a63433264767377667541713d22364f6253636331445153375567427753657c494e4855476933776939577f4a7a763f4179487258546d6b46566139405a52756e4f6e437a5838336968437b436b62487577623b44767d4d675e4077723a584c6c607d223648446c424a76576a683e455c68596f653533377d23344d23344/open" class=""><br class=""></div>
<div class=""><u class="">_______________________________________________</u><br class=""></div>
<div class="">swift-evolution mailing list<br class=""></div>
<div class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class=""></div>
<div class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div>
</blockquote><div class=""> </div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=ufQ1sKmNNtjEC-2BBUON-2BgZPd8t-2F4PFTin0qlI9lRM0Al-2Fo0RNLyXGvN-2BQGfGaSDMNlf5Row4Hg8xxIMMDrkfL6WuTyPvAFBTUJwFGGqBelfe0IvGdRAXyPYMDhQ3WvhjYg6V2dj1kv038jAj7wizZIkPWkzrDEqzZBoY8LuIaqNd1eBRg1uxkOps7I1V-2F6fCzNM20n5F9Xpe-2BA6WFbDOAtbOyU-2F0AnknqITGHvxdsIPQ-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" class="">
</div></div></div>
<br class="">_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
<br class=""></blockquote></div><br class=""></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=RC5Cq0zAxCHc1sM9Uy3-2BojrrUAw-2F96zH69NULNHPvCsQhrAZ8VtZeR1g0aXXj2-2FPueJMeImJsxTHiqBv7xPFYOynKAGv-2F1pHpbT8mlw53ZgBvu50kUE8LoZXYTLaEjN08ZlKA3kbPjZSz5Uvc8wulN6-2BdHrBIDNTLj7fjAhLihi9hQDekANUj8db6onpm-2BeTMxkx7PbwJEm8wFjUC7-2FBNLuI66oRIMQ6xgd1ZIEbHMo-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;" class="">
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>