Go: proposal: Go 2: prefixed labels for backtick literals
It's common in Go source code to write code in other languages like JSON, SQL, HTML, or JavaScript.
For this, backtick literals are helpful as you can format your code as desired:
var script =`console.log('Hello world');`
var page = `
<html>
<head>
<title>Title</title>
</head>
<body>
<p>Hello, world!</p>
</body>
</html>
`
This proposal is a simple change to allow an optional prefixed label for backtick literals:
var script = javascript`console.log('Hello world');`
var page = html`
<html>
<head>
<title>Title</title>
</head>
<body>
<p>Hello, world!</p>
</body>
</html>
`
Allowing prefixed labels enables IDEs and language parsers to act on the string contents:
- An IDE can provide linting and syntax highlighting for string contents.
- Like
gofmt, a program could format the string contents automatically by inferring the type from the label.
Like the 1.13 change which allows underscores between digits, prefixed labels are meant as a syntactic hint which has no effect on the string value itself, that is:
10000 == 10_000 // true
"contents" == foo`contents` // true
mbranch
All 7 comments
Another approach would be a comment. This wouldn't require changing the language.
//go:syntax html
var page = `
<html>
<head>
<title>Title</title>
</head>
<body>
<p>Hello, world!</p>
</body>
</html>
`
icholy
on 24 Jul 2020
Another approach would be a comment. This wouldn't require changing the language.
//go:syntax html var page = ` <html> <head> <title>Title</title> </head> <body> <p>Hello, world!</p> </body> </html> `
I think the benefit of formally adding to the language is that how to label a string becomes explicit. There wouldn't be special rules around how to format or place comments (before? after? either?) in order to get the benefit. With that clarity, I believe better tooling and features could be derived.
mbranch
on 24 Jul 2020
I agree with @icholy that additional text with no semantic meaning is better handle by a comment. The go/parser package already provides a well documented mechanism for commenting variables: the same as doc comments. And in 1.15 Go documentation packages don't display comments that start with //go: (see #37974). So I don't think there will be much confusion over the formatting or placement of these comments.
ianlancetaylor
on 24 Jul 2020
I do think #37974 makes using comments much more palatable.
@ianlancetaylor So I don't think there will be much confusion over the formatting or placement of these comments.
Playing with it, I came across an example where a comment approach is ambiguous:
_, err := c.exec(ctx, `
SELECT *
FROM orders
WHERE state = $1 AND id = $2;
`, /*go:syntax sql*/ "pending", id)
When trying to put the comment adjacent to the backtick literal, it jumps behind or in front of nearby commas after gofmt.
Obviously, this string could be refactored out of being inline and that could just be the rule, but with a prefix labeling approach, it would just work and be clear in all cases I can think of.
Related, most IDEs won't have access to an AST—so support for a comment-based approach might have to come in the form of syntax definitions based on regular expressions. Obviously not impossible, but probably pretty rough to get right.
mbranch
on 24 Jul 2020
A simple rule would be that //go:syntax ... affects the first string following the directive.
//go:syntax sql
_, err := c.exec(ctx, `
SELECT *
FROM orders
WHERE state = $1 AND id = $2;
`, "pending", id)
That would be easy for a regex.
icholy
on 24 Jul 2020
backtick literals seem to have been proposed in #32590 already.
martisch
on 28 Jul 2020
Closing in favor of #32590.
mbranch
on 28 Jul 2020
Related issues
bbodenmiller
·
3Comments
mingrammer
·
3Comments
myitcv
·
3Comments
ajstarks
·
3Comments
dominikh
·
3Comments
Most helpful comment
I agree with @icholy that additional text with no semantic meaning is better handle by a comment. The go/parser package already provides a well documented mechanism for commenting variables: the same as doc comments. And in 1.15 Go documentation packages don't display comments that start with
//go:(see #37974). So I don't think there will be much confusion over the formatting or placement of these comments.