> On Jun 21, 2016, at 3:51 PM, Jordan Rose via swift-evolution > <swift-evolution@swift.org> wrote: > > >> On Jun 21, 2016, at 15:26, Xiaodi Wu via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> On Tue, Jun 21, 2016 at 5:10 PM, Daniel Resnick via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> I also disagree for the same reasons that Gwynne and Brent mentioned: I find >> '\(...)' easy to read, fine to type, and consistent with other string >> escaping syntax. >> >> Those are persuasive arguments. Consistency with other string escaping >> syntax is a huge plus. Moreover, now that I think about it, \r or \n isn't >> really a bother to type. The \( combination takes a little getting used to, >> but it's not absurdly terrible. I suppose we could consider \{} or even \[] >> instead of \() to alleviate the reach. > > Gwynne and Brent indeed hit on the logic for the original design: backslash > is already an escape character in strings. The parentheses () over another > kind of delimiter were originally to match calls (string interpolation once > generated direct calls to String initializers), but even without that it’s > still something that’s used with expressions, while curly braces {} are used > for general code blocks and square brackets [] are used with collections. > > I’m strongly in favor of keeping things the way they are, both because I like > it a fair bit and because it’d be another source-breaking change that would > be very hard to migrate.
I completely agree with Jordan. This is a classical bikeshed, and any new design would have to be extremely compelling, because it would have to overcome the advantage of the \() approach: that it is compatible with the use of \ as the escape character for other things. It would be really unfortunate to have to start escaping $ or whatever other character you would pick. -Chris
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
