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

21–30 of 81 posts

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

#21

Post by dwattttt »

joshuamorton wrote: post #18
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…

> 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.

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

#22

Post by tptacek »

dwattttt wrote: post #16
kjksf wrote: post #11

Earlier quoted context omitted.

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.

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.

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

#23

Post by arjvik »

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

recover()'s semantics make it so that "pointless" use like this can be inlined in a way that changes its semantics, but "correct" use remains unchanged.

Yes, maybe some code uses recover() to check if its being called as a panic handler, and perhaps `go fix` should add a check for this ("error: function to be inlined calls recover()"), but this isn't a particularly common footgun.

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

#24

Post by dwattttt »

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.

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.

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

#25

Post by tptacek »

dwattttt wrote: post #24
tptacek wrote: post #22

Earlier quoted context omitted.

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.

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.

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

#26

Post by Mond_ »

thwarted wrote: post #17
Mond_ wrote: post #12

Earlier quoted context omitted.

This is begging the question. Yes, but why did they do that over dedicated syntax? (My personal theory is that early go had a somewhat misguided idea of simplicity, and preferred overloading existing concepts with special cases over introducing new keywords. Capitalization for visibility is another example of that.)

//go:xyz is dedicated syntax that is compatible with both the language spec and other toolchains that don't know about it.

It's an overloaded comment. I am personally quite fine with it, I don't think it's bad. but it is an overloaded comment.

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

#27

Post by Patryk27 »

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.

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

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

#28

Post by omoikane »

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.

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.

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

#29

Post by tptacek »

Patryk27 wrote: post #27
tptacek wrote: post #22

Earlier quoted context omitted.

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.

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

Eh, you're right, they have a structured attribute system.

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

#30

Post by thwarted »

Mond_ wrote: post #26
thwarted wrote: post #17

Earlier quoted context omitted.

//go:xyz is dedicated syntax that is compatible with both the language spec and other toolchains that don't know about it.

It's an overloaded comment. I am personally quite fine with it, I don't think it's bad. but it is an overloaded comment.

I'm no longer sure what you're saying. You asked why they didn't go with dedicated syntax, I listed two advantageous aspects of the chosen syntax. We know it's an overloaded comment: that's literally one of the advantages.
Post reply on HN