[swift-evolution] Fwd: Alternate proposal for multi-line string literial

Thu Mar 24 08:42:23 CDT 2016

> this much flexibility isn't required in practice

I think the syntax may be improved in some way, but I don't agree with this.
The options is needed if you ever try to use swift as source code (or html)
generator, take skipLeadingIndent option for example, it will remove
leading indent for each line in the text block, without it you have to put
each line at line start, rather than indent nicely with your code.

I am not sure about tripe-quote multiline (is there any link to the
proposal?), but I suppose you take hint from markdown, a short example may
look like this:

class Test {
    func output(resp: HtmlResponse) {
        resp.write(```
<HTML>
<BODY>
    ooxx
</BODY>
</HTML>
```)
    }
}

And in my proposal, :

#let #html = #string(end:"--", skipLeadingIndent: true)

class Test {
    func output(resp: HtmlResponse) {
        resp.write(#html "
            <HTML>
            <BODY>
                ooxx
            </BODY>
            </HTML>
            --")
    }
}

I don't think it look ugly in anyway.

2016-03-24 5:13 GMT+08:00 Andrey Tarantsov <andrey at tarantsov.com>:

> 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 <
> swift-evolution at swift.org> 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
> > swift-evolution at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160324/9d160bb3/attachment.html>