Why would backslashes at the end of each line be a nice idea?

Sent from my iPhone

> On Apr 3, 2017, at 2:44 PM, Paweł Wojtkowiak via swift-evolution 
> <[email protected]> wrote:
> 
> I think that there's nothing wrong with two "tools" for the same task in this 
> case. Multiline strings look better in the code and are easier to read and 
> can serve many purposes. By reading different texts from swift dev team I 
> feel like this is something the language was designed with in mind. They're 
> also easier to type and it needn't neccessarily be a string presented to the 
> user. 
> 
> Lets say I want a simple json literal for testing purposes - reading from a 
> file takes much more effort comparing to inserting it directly in the code. 
> Taking out every new line character makes it hard to read, and inserting 
> quotes and pluses every line both needs extra effort and also decreases 
> readability. Adding it as a multiline string would make a perfect solution 
> for this to me.
> 
> There are so many other cases where this could be useful too. I like how 
> python has the """ and I think this would be a good direction to go, although 
> this is true that python uses indentation in a different way, so I think 
> backslashes at the end of each line would be a nice idea - this is still 
> better than concatenating each line with " and +, and would have the least 
> readability impact. Also, it could be treated as a literal and be evaluated 
> at compile time.
> 
>> I just checked with -O and without and was surprised to find that `let x = 
>> "abc" + "def" + "ghi"` wasn't collapsed into a single string literal 
>> "abcdefghi" in the generated assembly code. Maybe it's more difficult than 
>> it is in some other languages because of operator overloads and different 
>> kinds of text literals (strings, extended grapheme clusters, Unicode 
>> scalars)?
>> 
>> Regardless of the reasons, a separate syntax isn't the right way to achieve 
>> this optimization—the compiler should just do it automatically. Like 
>> Ricardo, "multi-line string literals" should be reserved for string literals 
>> that include the newline characters that are used to break them up in 
>> source. The idea of supporting something like the Python example above just 
>> provides two ways to do the same thing, which I don't think we really need.
>> 
>> 
>>> On Mon, Apr 3, 2017 at 8:18 AM Ricardo Parada via swift-evolution 
>>> <[email protected]> wrote:
>>> 
>>> I would think that the concatenation would get resolved at runtime, unless 
>>> the compiler gets smart about it.  But either way I do not see it as a 
>>> problem.  The reason is that I don't remember ever worrying about the 
>>> performance of concatenating a few lines of text.  :-)
>>> 
>>> Thanks
>>> 
>>> 
>>>> On Apr 3, 2017, at 11:13 AM, Adrian Zubarev 
>>>> <[email protected]> wrote:
>>>> 
>>>> To me a literal a single entity which is solved at compile time. The 
>>>> concatenation is however resolved at runtime if I’m not mistaken here (it 
>>>> might be optimized at compile time but I still would expect a function 
>>>> executed a couple of times at runtime).
>>>> 
>>>> Please correct me if I’m wrong here.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> -- 
>>>> Adrian Zubarev
>>>> Sent with Airmail
>>>> 
>>>> Am 3. April 2017 um 17:10:36, Ricardo Parada ([email protected]) schrieb:
>>>> 
>>>>> How is that better than this?
>>>>> 
>>>>> template = "This is the first line.\n" +
>>>>>             "This is the second line.\n" +
>>>>>             "This is the third line."
>>>>> 
>>>>>> On Apr 3, 2017, at 10:42 AM, Ricardo Parada via swift-evolution 
>>>>>> <[email protected]> wrote:
>>>>>> 
>>>>>> It look prettier without the \n
>>>>>> 
>>>>>> It's not laziness.
>>>>>> 
>>>>>> I want my code to look pretty.
>>>>>> 
>>>>>> 
>>>>>>> On Apr 3, 2017, at 10:40 AM, Adrian Zubarev 
>>>>>>> <[email protected]> wrote:
>>>>>>> 
>>>>>>> What I was trying to say is that by automatically adding a new line 
>>>>>>> character does not provide any benefit except of being lazy to type \n.
>>>>>>> 
>>>>>>> // In your model this would be equivalent
>>>>>>> let s1 = "\n\n\n"
>>>>>>> let s2 = """
>>>>>>>     " // However in my model this is an empty string and should be 
>>>>>>> banned
>>>>>>>     "
>>>>>>>     """ // That's also an empty string, but it that case it indicates 
>>>>>>> the end of the multi lined string
>>>>>>> I dislike the tradeoff of precision for laziness.
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> -- 
>>>>>>> Adrian Zubarev
>>>>>>> Sent with Airmail
>>>>>>> 
>>>>>>> Am 3. April 2017 um 16:29:44, Ricardo Parada ([email protected]) schrieb:
>>>>>>> 
>>>>>>>> By the way, the multi-line string should allow \n\n, or as many as you 
>>>>>>>> may want to throw in there.  I don't see a problem with that.
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> swift-evolution mailing list
>>>>>> [email protected]
>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>> 
>>>> 
>>>> 
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> [email protected]
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to