//go:fix inline and the source-level inliner

[−] omoikane 62d ago

I wonder why they chose to add these directives as comments as opposed to adding new syntax for them. It feels like a kludge.

https://wiki.c2.com/?HotComments

[−] kjksf 62d ago

Go designers distinguish between Go language as defined by Go spec and implementation details.

//go:fix is something understood by a particular implementation of Go. Another implementation could implement Go without implementing support for //go:fix and it would be a fully compliant implementation of Go, the language.

If they made it part of the syntax, that would require other implementations to implement it.

[−] dwattttt 62d ago

If the comments impact correctness (which inlining doesn't, but I believe there are other directives that do), saying it's "an implementation detail" waves away "it's an implementation detail that everyone needs" aka part of the spec.

The reason it feels like a kludge is that "comments" are normally understood to be non-impactful. Is a source transformation that removes all comments valid? If comments have no impact per the spec, yes. But that's not the case here.

In practice comments in go are defined to be able to carry semantic meaning extensibly. Whether they're safe to ignore depends on what meaning is given to the directives, e.g. conditional compilation directives.

[−] scheme271 62d ago

There are directives and packages that affect correctness. E.g. the embed package allows you to initialize a variable using a directive. E.g. //go:embed foo.json followed by var jsonFile string initializes the jsonFile variable with the contents of the foo.json file. A compiler or tooling that doesn't support this results in broken code.

[−] tptacek 62d ago

There's nothing unique to Go about this kind of tooling. It exists in C, Java, Rust, Typescript, and probably dozens of other settings as well. It's the standard way of implementing "after-market" opt-in directives.

[−] dwattttt 62d ago

Are we referring to 'go fix' as after market tooling?

It's certainly done in many places. JsDoc is the biggest example I can think of. But they're all walking the line of "this doesn't have an impact, except when it does".

It being done by the language owners just makes them the ones walking the line.

[−] tptacek 62d ago

That's exactly how this works: it doesn't have an impact, except when you ask it to. This is an idiomatic approach to this problem.

[−] omoikane 62d ago

In the listed examples, the compiler will emit a diagnostic upon encountering those comments:

https://go.dev/blog/inliner#example-fixing-api-design-flaws

So these comments carry more weight than how those comment annotations might be consumed by optional tools for other languages.

For most of the listed examples, I think the corresponding C annotation would have been "[[deprecated]]", which has been added to the syntax as of C23.

[−] ternaryoperator 62d ago

It does not exist in Java. Comments in Java do not change code.

[−] Patryk27 62d ago

There are no comment-based directives in Rust, are there?

[−] joshuamorton 62d ago

> The reason it feels like a kludge is that "comments" are normally understood to be non-impactful. Is a source transformation that removes all comments valid? If comments have no impact per the spec, yes. But that's not the case here.

This is not inlining in the compiler. It's a directive to a source transformation (refactoring) tool. So yes, this has no impact on the code. It will do things if you run go fix on your codebase, otherwise it won't.

[−] bheadmaster 62d ago

That's such an elegant solution.

I keep being impressed at subtle but meaningful things that Go does right.

[−] Groxx 62d ago

Because these are instructions for users for making tool-assisted changes to their source code, not a behavior that exists at runtime (or even compile time). A new syntax wouldn't make sense for it.

For other things, like //go:noinline, this is fair criticism. //go:fix inline is quite different in every way.

[−] 0x696C6961 62d ago

The //go:xyz comments are an established pattern in the Go tooling.

[−] piekvorst 62d ago

I suppose, to minimize its use. If annotations have the same syntactic weight as normal statements, such as “if” or “for” statements, there’s a temptation to use them liberally, which is clearly not a good fit for Go.

By making them comments, Go subtly signals that these are exceptional, making them less prominent and harder to abuse.

[−] freakynit 62d ago

Can't golang devs prioritize something like annotations or other attribute/metadata system instead of writing these in comments? I'm pretty sure this must have been raised a lot of times before, so just wanted to ask if there is/are any specific reason(s)?

[−] ansgri 62d ago

Good illustration that a seemingly simple feature could require a ton of functionality under the hood. Would be nice to have this in Python.

[−] tapirl 62d ago

It looks the following code will be rewritten badly, but no ways to avoid it? If this is true, maybe the blog article should mention this.

    package main
    
    //go:fix inline
    func handle() {
        recover()
    }
    
    func foo() {
        handle()
    }
    
    func main() {
        defer foo()
        panic("bye")
    }

[−] vismit2000 62d ago

Earlier submission: https://news.ycombinator.com/item?id=47385766

[−] measurablefunc 62d ago

https://en.wikipedia.org/wiki/Hygienic_macro

[−] rishabhjajoriya 61d ago

That was quite insightful read

[−] useftmly 61d ago

[dead]

//go:fix inline and the source-level inliner (go.dev)

81 comments