proposal: Go 2: indentation in multiline raw string literals

[RodionGork]

At go 1.13 version and earlier raw literal can be multiline. However there is no way to indent continuation lines without adding spare spaces to it, e.g.

// printing help message on program parameters, for example
func printHelp() {
    fmt.Println(`Usage:
    ./program server [arg1]
    ./program client [arg2]`)
}

in this case .program... is indented compared to Usage by 4 spaces, which makes sense, though code is not indented nicely (we'd like Println args all be indented further). However if fmt.Println is enclosed in some block (e.g. if) during refactoring, even this indentation may change, which is not good.

Suggestion

It is possible (like in Scala) introduce the rule, that if continuation line of the raw literal starts with |, then spaces before it are skipped. So the snippet could be rewritten:

    fmt.Println(`Usage:
            |    ./program server [arg1]
            |    ./program client [arg2]`)

Here we have normal 8 spaces indentation for arguments (or we can align them with the opening parenthesis if such style is preferred).

(if the line should start with | character we simply shall use two of them)

This is slightly breaking change so we may want introduce "extended" version of raw literal, for example enclosed in double backticks, e.g.

    fmt.Println(``Usage:
            |    ./program server [arg1]
            |    ./program client [arg2]``)

UPD as both versions are "breaking" as pointed out by colleagues below, I think we'll need to use "triple-tick"*. Suggesting double tick I just thought no one will use it for empty literal... But of course this couldn't be granted... E.g.

    fmt.Println(```Usage:
            |    ./program server [arg1]
            |    ./program client [arg2]```)

Though I understand it is slightly against the idea of not having two syntaxes for almost same things...

[ianlancetaylor]

See also #32590.

[ianlancetaylor]

Both of your suggestions could break existing programs. I don't see how we could do them.

[mvdan]

I don't agree with this proposal overall, but to provide another angle to @ianlancetaylor's comment - it would be possible, I think, if this feature was turned on for a new Go language version in a module's go.mod. Existing modules and packages would not break on their own, as their language version would be older until changed. Though, granted, when updating the language version one could encounter very subtle breakages.

[RodionGork]

Both of your suggestions could break existing programs. I don't see how we could do them.

Yes Friends, sorry. I suggest non-breaking form is if we use "triple-tick" - this couldn't be confused with empty tick literal, right?

fmt.Println(```Usage:
            |    ./program server [arg1]
            |    ./program client [arg2]```)

[magical]

@mvdan The language version is not carte blanche for language changes, though many people seem to think it is.

In Proposal: Go 2 transitions, Ian lays out the conditions for which the language can be safely evolved. In particular, they propose that additions and removals from the language would be okay, but redefinitions would not. The danger is that code could silently change meaning depending on the language version, and the compiler would not be able to detect code compiled with the wrong version. It would lead to "subtle breakages", as you put it.

A redefinition is a case where we have code that compiles successfully with both versions 1.N and version 1.M, where M > N, and where the meaning of the code is different in the two versions. [...] The complexity of a redefinition is, of course, that we can no longer rely on the compiler to detect the problem. [...] The only possibility would be to let programmers set the language version. [..] Of course, setting such a version would be error prone. [...]

I think the only feasible safe approach is to not permit language redefinitions.

Since this proposal would silently change the meaning of raw string literals, i don't see how it can safely be adopted as originally proposed.

The triple-tick variant would introduce a new syntax, so it would be a language addition rather than a redefinition, which should be safe.

[ianlancetaylor]

This basic idea is discussed in various ways in #32590. Closing this issue as a dup of that one.