<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class="">On Jun 21, 2016, at 15:48, Jonathan Cotton 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 class="">I'd support $() as is in use by other languages, including Kotlin, as mentioned it seems less disruptive and more inline with the tokenised parameters that are already supported in closures.<br class=""><br class=""><blockquote type="cite" class="">On 21 Jun 2016, at 21:43, Kenny Wyland via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class="">Hi all,<br class=""><br class="">I'm new to the list and I just searched through the archives as best I could to see if someone else had already brought this up, but I didn't find anything. Forgive me if this horse has been beaten.<br class=""><br class="">I find that typing \(var) is very disruptive to my typing flow. The more I code in Swift, the more I like it, but every time I'm coding and then have to hiccup while typing \ then ( causes me to be annoyed. I know, it's minor, but it isn't a key combination that flows quickly.<br class=""><br class="">I would much rather have $() or perhaps ${} (like Groovy lang) or perhaps @() to go along with other uses of @ throughout the language. <br class=""><br class="">A shifted key, like $ or @, followed by another shifted key like (, allows for a much faster flow and they are much closer to the home keys than \ which is nearly as far from home keys as possible (and awkward). <br class=""><br class="">Thoughts?<br class=""><br class="">Kenny Wyland<br class=""><a href="http://inadaydevelopment.com" class="">InADayDevelopment.com</a><br class=""></blockquote></div></div></blockquote><br class=""></div><div>I have to disagree - The \ syntax is consistent with other string escape sequences (\n etc.) and reads naturally to me in that regard. Additionally, the \ is very visually distinctive in a string, much moreso than the "traditional" $ variable marker. Almost every language I’ve seen using $ for interpolation in strings is doing so because it also uses it as a variable prefix in non-string contexts. To top it off, using $ instead would, for me, just add yet another language for which I have to remember "does the $ go inside or outside the name delimiter braces/brackets/whatever?", "is it parenthesis, braces, brackets, or some other delimiter for variable names?", "what kind of expressions can I use in this context?", "can I use interpolation without any delimiters for simple cases?", etc. See also PHP, Perl, ten flavors of shell scripts, JavaScript, JSP/ASP, XPath, and so forth. The \() syntax is unique to Swift and therefore very easy to remember.</div><div><br class=""></div><div>I also don’t see that Swift carries an expectation of being able to use a syntax which is traditionally confined to interpreted/scripting languages, and even there $ is by no means ubiquitous. Here are just a few counterexamples among various languages:</div><div><br class=""></div><div>- C (printf formats)</div><div>- C++ (stream modifiers)</div><div>- Objective-C (NSString formats)</div><div>- C# ($, but with the unusual syntax $"blah {foo} blah")</div><div>- Lua (printf formats and language hacks)</div><div>- Python (printf formats with trailing "% (tuple)" syntax)</div><div>- Ruby ("#{}")</div><div>- Java (printf formats)</div><div><br class=""></div><div>There’s an obvious pattern in these example, which brings to something I _would_ like to see for string interpolation in Swift: Better control over the precise representation of the data. I’m sure the topic has been done to death many times before, but I haven’t found any solid information at a quick search, so I apologize if this is all old hat.</div><div><br class=""></div><div>Anyway - Creating, configuring, and invoking various Formatter types in order to present data in the proper fashion is an option, and a preferable one when the data is intended for user consumption (especially to get the maximum support from localization). But for logging, debugging, parsing of textual formats, writing textual formats, etc., I almost always want a traditional C/POSIX/ISO representation as easily provided by printf()-style specifiers. 99% of the time when I want to do an number-to-string (integer or otherwise) conversion especially, I’m being specific about the appearance of the number.</div><div><br class=""></div><div>For example, for a hex representation of sockaddr_in.sin_addr.s_addr, I would in other languages write "printf("0x%08x", address.sin_addr.s_addr);", or "%02hhu" times four to get dotted-decimal notation. (Ignoring for the moment the existence of inet_ntop() for the sake of the example :). In Swift, I currently have to make a call to printf(), fprintf(), dprintf(), NSString(format:), asprintf() (with a wrapper to deal with getting a Swift.String from allocated memory), etc. A configured NumberFormatter instance is a great deal more code - even NumberFormatter.localizedString(from: foo, number: .decimal) is very verbose, and that *still* doesn’t yield the same level of format control!).</div><div><br class=""></div><div>And to top it off, these still carry the traditional problem of printf() formats - separation between the format specifier and the data that format applies to. I’m sure most of us have at one time or another written a printf() with enough arguments that it was easy to lose track of them and end up being very grateful for the existence of -Werror=format (and frustrated that __attribute__((format(..))) is as limited as it is :).</div><div><br class=""></div><div>I’m not sure exactly what form support for formatted data in interpolated strings would take in Swift, but it’s certainly one of the things I find myself actively missing on a regular basis, and I do have some ideas on how to go about it, if it isn’t already under discussion/development.</div><div><br class=""></div><div>-- Gwynne Raskind</div><div><br class=""></div></body></html>