Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

go.dev

Post reply on HN
Print view View original

31–40 of 81 posts

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

#31

Post by ternaryoperator »

tptacek wrote: post #22
dwattttt wrote: post #16

Earlier quoted context omitted.

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…

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.

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

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

#32

Post by dwattttt »

tptacek wrote: post #25
dwattttt wrote: post #24

Earlier quoted context omitted.

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.

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.

The part I object to is overloading comments, which aren't meant to be load bearing. A tool developed outside the language has no choice but to take something that has no meaning and overload it, but language owners weren't forced to take this route; they could've made directives not comments.

In practice, the Go language developers carved syntax out of comments, so that a comment is "anything that starts with //, unless the next characters are go:"

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

#33

Post by Groxx »

omoikane wrote: post #7

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

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.

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

#34

Post by pastel8739 »

dwattttt wrote: post #21
joshuamorton wrote: post #18

Earlier quoted context omitted.

> 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 y…

And yet it still breaks "comments aren't semantic". That transformation I described is still invalid.

I don’t understand why that wouldn’t be valid. As far as I understand if you compile code with these go:fix comments, they will be ignored. But if instead of compiling the code you run ‘go fix’, the source code will be modified to inline the function call. Only after the source code has been modified in this way would compiling reflect the inlining. Do you have a different understanding?

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

#36

Post by YesThatTom2 »

dwattttt wrote: post #32
tptacek wrote: post #25

Earlier quoted context omitted.

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.

The part I object to is overloading comments, which aren't meant to be load bearing. A tool developed outside the language has no choice but to take something that has no meaning and overload it, but language owners weren't forced to take this route; they could've made directives not comments. In practice, the Go language developers carved syntax out of comments, so that a comment is "anything that starts with //, un…

So how many angels can you fit on the head of a pin?

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

#37

Post by gnabgib »

vismit2000 wrote: post #35

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

Far later submission. Check the ID again.. you were 2 days later.

There was even a more upvoted post between your triple dupe and this https://news.ycombinator.com/item?id=47347322 #scp

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

#38

Post by RossBencina »

shoo wrote: post #4

If I follow, this isn't a compile time inline directive, it's a `go fix` time source transformation of client code calling the annotated function. Per the post, it sounds like this is most effective in closed-ecosystem internal monorepo-like contexts where an organisation has control over every instance of client code & can `go fix` all of the call sites to completely eradicate all usage of a deprecated APIs: > For m…

I'm not sure what all of the hazards are, but I could imagine a language (or a policy) where public APIs ship with all of the inline fix directives packaged as robust transactions (some kind of "API-version usage diffs"). When the client pulls the new API version they are required to run the update transaction against their usage as part of the validation process. The catch being that this will only work if the fix is entirely semantically equivalent, which is sometimes hard to guarantee. The benefits would be huge in terms of allowing projects to refine APIs and fix bad design decisions early rather than waiting or never fixing things "because too many people already depend on the current interface".

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

#39

Post by tapirl »

tapirl wrote: post #15
tapirl wrote: post #3

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") }

Another example (fixable): package main import "unsafe" //go:fix inline func foo[T any]() { var t T _ = 1 / unsafe.Sizeof(t) } func main() { foo[struct{}]() } Go is a language full of details: https://go101.org/details-and-tips/101.html

similar:

    package main

    //go:fix inline
    func foo[T [8]byte | [4]uint16]() {
        var v T
        var n byte = 1 > len(v)
        if n == 0 {
            println("T is [8]byte")
        } else {
            println("T is [4]uint16]")
        }
    }

    func main() {
        foo[[8]byte]()
    }

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

#40

Post by dwattttt »

pastel8739 wrote: post #34
dwattttt wrote: post #21

Earlier quoted context omitted.

And yet it still breaks "comments aren't semantic". That transformation I described is still invalid.

I don’t understand why that wouldn’t be valid. As far as I understand if you compile code with these go:fix comments, they will be ignored. But if instead of compiling the code you run ‘go fix’, the source code will be modified to inline the function call. Only after the source code has been modified in this way would compiling reflect the inlining. Do you have a different understanding?

I mean that directives other than inlining impact correctness. If you have a source file that only builds for one OS, stripping the build tag will break your build.
Post reply on HN