Feels wrong to me. It's ugly (looks like line noise) and unnecessary (this much flexibility isn't required in practice). Making features more powerful doesn't always make them better.
Some of the use cases you have in mind are probably better handled by macros, whenever they make it into Swift. Macros provide a general and elegant way to handle customizable special cases without introducing an unusual complicated syntax for each of them. So, nope, sorry, let's stick to making tripe-quote multiline strings as awesome as possible, but not awesomer. :D A. > On Mar 23, 2016, at 10:49 AM, Steve K. Chiu via swift-evolution > <[email protected]> wrote: > > Hi, > > I am new to swift-evolution list, here is my draft proposal for the > multi-line string literal problem. > The idea had been discussed in the list before, but it seems there are no > real solution to many of the string literal problem. > Let's first define what are the problem with string literal: > > 1. should be able to disable escape char > > 2. or better, able to replace escape char with user defined char > > 3. should be able to write multi-line string literal, and is copy-paste > friendly > > 4. for multi-line string, should be able to remove first and last newline > char, so user can write string in block > > 5. for multi-line string, should be able to remove leading indent, or remove > all indent > > 6. for multi-line string, should be able to replace newline with user > defined string ("\r\n", "\r", "\r", or simply " ") > > 7. should be able to add feature over time, without breaking existing code > > My proposal to the above problem is to introduce new 'process instruction' > (not sure how to call it), in the following form: > > #string(options) "text" > > for example: > > #string(escape: nil) "^\d+" > > #string(escape: "$", end: "<EOF>") " > $(username), > Is it 1358 yet? > <EOF>" > > It is possible to add many options list above, and you can add more options > over time without breaking code. > > #string( > escape: Character? = "\\", > end: String? = nil, > skipEnclosureNewline: Bool = true, > skipLeadingIndent: Bool = true, > skipAllIndent: Bool = false, > newline: String? = nil > ) > > for 1. & 2., escape option to replace escape char, pass nil will disable > escape. > > for 3., end option for end-of-string mark, pass nil will disable multi-line > processing. > > for 4., skipEnclosureNewline will skip newline if it is the first or last > char of the string. > > for 5., skipLeadingIndent will skip leading indent, leading indent is the > leading white-spaces of first line of multi-line string. > > for 5., skipAllIndent will skip all indent, this will override > skipLeadingIndent. > > for 6., newline option to replace newline char in multi-line string, pass nil > will disable the replacement (as-is in the source). > > But there are one problem remain, as you can see, the #string with options > will become very long; I don't think it is a pleasure to use such expression > except for one time literal. To fix the problem, I propose yet another > process instruction: > > #let #rex = #string(escape: nil) > #let #mail = #string(escape: "$", end: "<EOF>") > > Now you can write the string as: > > #rex "^\d+" > > #mail " > $(username), > Is it 1358 yet? > <EOF>" > > #let should be able to be used with other # process instruction as well, for > example, #available, among other things. > > What do you think? > > > _______________________________________________ > 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
