[swift-evolution] Thoughts on replacing \() with $() or some other symbol

[Leonardo Pessoa]

I'll stick with Gwynne here. Each language has its syntax for
interpolating string and as such I don't see a reason to change this.
As for formatting, I agree it is an issue but we have to remember that
inside \() we have code that can do pretty much everything one may
need. You may even add a formatting function to String or Int in order
to produce the result you need (even simplifying the calls to
NumberFormatter - I myself have a whole library of "shortcuts" I add
to every project).

L

On 21 June 2016 at 18:49, Gwynne Raskind via swift-evolution
<swift-evolution at swift.org> wrote:
> On Jun 21, 2016, at 15:48, Jonathan Cotton via swift-evolution
> <swift-evolution at swift.org> wrote:
>
> 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.
>
> On 21 Jun 2016, at 21:43, Kenny Wyland via swift-evolution
> <swift-evolution at swift.org> wrote:
>
> Hi all,
>
> 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.
>
> 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.
>
> I would much rather have $() or perhaps ${} (like Groovy lang) or perhaps
> @() to go along with other uses of @ throughout the language.
>
> 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).
>
> Thoughts?
>
> Kenny Wyland
> InADayDevelopment.com
>
>
> 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.
>
> 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:
>
> - C (printf formats)
> - C++ (stream modifiers)
> - Objective-C (NSString formats)
> - C# ($, but with the unusual syntax $"blah {foo} blah")
> - Lua (printf formats and language hacks)
> - Python (printf formats with trailing "% (tuple)" syntax)
> - Ruby ("#{}")
> - Java (printf formats)
>
> 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.
>
> 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.
>
> 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!).
>
> 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 :).
>
> 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.
>
> -- Gwynne Raskind
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>