> On 6 Apr 2017, at 21:47, David Hart <[email protected]> wrote:
>
>>
>> On 6 Apr 2017, at 22:34, Haravikk via swift-evolution
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>>
>>> On 6 Apr 2017, at 20:35, Joe Groff via swift-evolution
>>> <[email protected] <mailto:[email protected]>> wrote:
>>>
>>> • What is your evaluation of the proposal?
>>
>> I'm a -1 for several reasons, mostly subjective but still. First thing is
>> that I'm generally not comfortable with encouraging the use of multi-line
>> strings at all. These are things that usually should be templated or
>> localised, and personally I don't see what's inconvenient about
>> concatenating on those occasions where you can't (or just don't want to);
>> I'm actually of the opinion that this is the kind of thing that should be
>> awkward and annoying, to encourage developers to think about what they're
>> doing.
>
> IMHO, there are plenty of uses for multi-line strings that are entire valid
> and acceptable. SQL queries is the example I encounter the most in my
> day-to-day work. And concatenating makes working with them very cumbersome.
Maybe, but with SQL I long moved on to using placeholders for variables, which
makes most statements fairly compact. And in fact these days I almost entirely
use stored procedures, so most SQL statements I work with are just enough to
call a procedure.
Even so, while that may be an argument for the need for multi-line strings it's
a use case that would still be better handled by continuation quotes IMO, but
again, they don't offer so much added convenience over concatenation to really
be worth it.
Also, just wanted to add, but those arguing against continuation quotes on the
basis of pasting into Swift; you already can paste into Swift using regular
double quotes, you just don't get to indent text and have the indentation
magically handled for you. It's the magic handling of indentation that makes me
most uncomfortable about the main proposal. This is why I mentioned the idea of
using a compiler directive which would be more explicit in what's going on, as
well as being more discoverable as it would provide something easy to search
for. Like so:
let foo = #trimleft("
foo
bar
baz
")
Becoming (behind the scenes):
let foo = "foo
bar
baz"
It has the same benefits as heredocs but without any new syntax, and someone
new to the language can just search for "Swift #trimleft" (or whatever it'd be
called) to find out what it does exactly._______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
