"""Just in my opinion: having to start each line with a particular token kinda defeats the purpose of multiline string literals. "can't we just continue" "the literal on the next line anyways," "like in C?" "or maybe the "+ "at the end of the line can be"+ "optimized away?" """
What is wrong with just using """ as a delimiter? Except that maybe there are other languages which use this already. You can copy&paste whole XML snippets into such a thing. It's also good for usage instructions in a command line tool, and I think everyone will understand what it means. Is it a design goal to do something completely new? Or are you just unhappy with all existing multi-line string literal syntaxes? -Michael (who would be happy with Perl Heredoc-Syntax as well) > Am 26.04.2016 um 01:00 schrieb ted van gaalen via swift-evolution > <[email protected]>: > > possible improvement, one could allow > leading spaces before the "data line token" > thus enabling indentation, like so > { > let str = > \\dataaaaaaaaaahgdfhhfdxfg cvcsffggcfg > \\c jggjvhfh fhffhfgxfxgdgfhgj jvhhfhfhcgxgc > . > . > } > > TedvG > > On 25 Apr 2016, at 20:47, Ted F.A. van Gaalen <[email protected]> wrote: > >> This could be a simple solution: >> >> Starting each line with a special token. >> >> In the example here it is the \\ double-backslash . >> when the \\ appears in the first two columns of a source line, >> this tells the compiler that it is a data line and that more might follow. >> the last line starting with \\ completes the data entry. >> >> Here is an example of a string declaration with some XML >> (no escape sequences needed for “) >> Of course it could be anything other kind of textual data as well. >> >> let str = >> \\<!DOCTYPE html> >> \\<html> >> \\<body> >> \\ >> \\<h1>W3Schools Internal Note</h1>\n >> \\<div> >> \\<b>To:</b> <span id="to"></span><br>\n >> \\<b>From:</b> <span id="from"></span><br>\n >> \\<b>Message:</b> <span id="message"></span> >> \\</div> >> \\\n >> \\<script> >> \\var txt, parser, xmlDoc; >> \\txt = "<note>" + >> \\"<to>Tove</to>" + >> \\etc. this is the last data line. >> >> >> Conditions: >> >> - Every line starting with \\ in first and second column of the line >> is treated as a data line. >> - All characters behind the \\ are regarded as data, thus note that: >> - the “ is not regarded as a string delimiter >> - the // chars and whatever follows it are interpreted as data on such >> a line, not as comment. >> - \\ within the data itself are treated as data e.g. this line is >> valid: >> \\There \\ are three backslashes (as data) in this line \\\\ today. >> \\ >> the above data line is empty but is allowed. >> >> - Leading and embedded spaces are respected. >> - Tabs, Linefeeds etc. can be inserted the usual way using \t \n etc. >> - trailing spaces and line terminators cr lf are ignored, filtered out. >> >> let dutchNumbers = >> \\ een twee drie vier vijf >> >> \\ zes zeven acht negen tien >> \\these two data lines are orphans, >> >> Blank lines or other Swift statement lines in-between >> breaks a set of \\ data lines >> >> >> All \\ lines together are treated as one single string literal >> and may occur everywhere where “normal” string literals are allowed. >> >> // E.g. this if statement would be correct: >> // Yes, this would be legal but doesn’t look so great: Indentation not >> possible here >> if cars == >> \\Ford >> \\ Delorean >> \\ Chevrolet >> { >> doSomething() >> } >> >> An array with 2 string elements: >> >> var ar = >> [ >> \\sdkdslkdslkdsldkshfkjdljfsdljkfdshjklfd dioioioioio \n\nsljkf sdflkf >> dsl;dfsk sdlfk dfsfkds >> \\ sdkdfkdfldkfd fdfldk fdlkfd jkfds hjklfd dsljkf sdflkf dsl;dfsk sdlfk >> dfsfkds >> , >> \\There are many ships in the ha >> \\rbour that are soon sailing away. >> ] >> >> >> I also thought about using “” as token, but this would be interpreted as an >> empty string. >> or “”” but this is an empty string followed by an unclosed string literal. >> >> Should be relatively easy to implement? What y’all think? >> >> >> Kind Regards >> TedvG > _______________________________________________ > 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
