[dead]
//go:fix inline and the source-level inliner
71–80 of 81 posts
Re: //go:fix inline and the source-level inliner
#72Earlier quoted context omitted.
Understood... but why in comments?
Someone else said this below... > 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…
That does seem a strange argument, it could simply be `%%` (or whatever) to introduce a 'metadata comment', and then a Go implementation that doesn't support metadata would simply lex both `%%` and `//` as comments and treat them identically.
Re: //go:fix inline and the source-level inliner
#73That was quite insightful read
Re: //go:fix inline and the source-level inliner
#74If 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…
> It could still have some incremental benefit for public APIs where client code is not under centralised control, but would not allow deprecated APIs to be removed without breakage.
It makes those breakages less painful. A project can eventually remove a deprecated API after notifying other projects to run `go fix`. And when projects ignore that advice (some always will), they can revert to a previous working version, run `go fix`, and then upgrade, without spending time in the code identifying how to replace each removed API.
And for those projects that routinely update and run `go fix`, they'll never notice the removal of deprecated code. Given the other benefits of `go fix`, switching to easier to read methods, and leveraging more efficient methods, in addition to security fixes that come with regular updates, this should be the workflow for most maintained projects.
Re: //go:fix inline and the source-level inliner
#75Earlier 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…
Actually, in practice the rule is "The delimiter for a comment is '// '", which to be clear, is slash-slash-space. Slash-slash-(not a space) is in practice a directive. There are several basic tools in the community that work on this principle including one of the basic linters.
If it would make you happier you can imagine this is part of the spec. It wouldn't change much if it was.
Re: //go:fix inline and the source-level inliner
#76Earlier quoted context omitted.
> I mean, technically you could write your entire business logic inside comments and have some tool parse it successfully. It sounds like you are talking about cgo. I think you have a stronger case there, but it is much the same situation: It's conceptually a third-party add-on that the Go language doesn't know anything about. "Cgo is not Go"[1] I mean, if you really did have your own business logic language that you…
I think your latest comment clarifies a lot of things for me here... primary being that it's something language designer did not wanted... just that tool developers went ahead with because there wasn't somethinf else (or something better) they could use. If that is indeed the case, I believe it's fair. Im not into language/compiler design etc., but if I have to take a guess, this is where metaprogramming would have h…
> this is where metaprogramming would have helped, right?
It is infinitely flexible for any kind of tool you can imagine, so it is quite likely that someone has created a tool to use in a place where metaprogramming could have been used instead. But I am not sure if it helps globally. The very directive in question, `//go:fix inline`, is a directive for a tool that refactors code — changing the files stored on disk to meet modern idioms. I don't think you would want to use metaprogramming for that, would you? It is not something you want to happen at compile time or run time. It is something you run only when you are ready to modernize your codebase (which, in some cases, might be never).
Re: //go:fix inline and the source-level inliner
#77As usual, great writeup and problem solving from Go team. One nitpick: wording "call to oldmath.Sub should be inlined" might be a bit confusing due to existing meaning of word "inlining" for functions (i.e. compiler inlining optimization). Without this article I would not be able to guess that this diagnostic message refer to something else.
Re: //go:fix inline and the source-level inliner
#78Earlier quoted context omitted.
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…
Actually, in practice the rule is "The delimiter for a comment is '// '", which to be clear, is slash-slash-space. Slash-slash-(not a space) is in practice a directive. There are several basic tools in the community that work on this principle including one of the basic linters. If it would make you happier you can imagine this is part of the spec. It wouldn't change much if it was.
The book says "Comments begin with //." and "// +build" is a special comment. It was only replaced with "//go:build" 1.17 (2021) . So your statement incorrectly implied that this strict syntax distinction between directives and comments has always existed, what happened was people started doing this slowly over time and eventually noticed the disconnect and changed "// +build" which they could because all that stuff was implementation-defined behavior. Right now gofmt handles "// +build" "//+build" and "//go:build" by moving them to the top, adding //go:build if it doesn't exist and adding a space to "//+build", which already breaks setups that add a build comment.
Why would millions of programs becoming out of date with the spec make me happy. There is value in the language maintainers and go programmers talking about the same object. I don't disagree that '// ' is standard Go style (and more readable), but it would break all the code that uses //comments /// ////.
I DO agree that it wouldn't change much if by 'it' you mean the go language and it's tooling, a proper spec does prevent arbitrary change. But it should have been added at least 5 years ago.
Re: //go:fix inline and the source-level inliner
#79Earlier quoted context omitted.
Actually, in practice the rule is "The delimiter for a comment is '// '", which to be clear, is slash-slash-space. Slash-slash-(not a space) is in practice a directive. There are several basic tools in the community that work on this principle including one of the basic linters. If it would make you happier you can imagine this is part of the spec. It wouldn't change much if it was.
The book says "Comments begin with //." and "// +build" is a special comment. It was only replaced with "//go:build" 1.17 (2021) . So your statement incorrectly implied that this strict syntax distinction between directives and comments has always existed, what happened was people started doing this slowly over time and eventually noticed the disconnect and changed "// +build" which they could because all that stuff…
"So your statement incorrectly implied that this strict syntax distinction between directives and comments has always existed,"
There was no such statement. "In practice" clearly indicates the contrary about it being "strict" and certainly encompasses the possibility that it only developed over time.
Re: //go:fix inline and the source-level inliner
#80Earlier quoted context omitted.
I think your latest comment clarifies a lot of things for me here... primary being that it's something language designer did not wanted... just that tool developers went ahead with because there wasn't somethinf else (or something better) they could use. If that is indeed the case, I believe it's fair. Im not into language/compiler design etc., but if I have to take a guess, this is where metaprogramming would have h…
> this is where metaprogramming would have helped, right? It is infinitely flexible for any kind of tool you can imagine, so it is quite likely that someone has created a tool to use in a place where metaprogramming could have been used instead. But I am not sure if it helps globally. The very directive in question, `//go:fix inline`, is a directive for a tool that refactors code — changing the files stored on disk t…
Hmm... I believe nodejs ecosystem solves this by using separate, tool-specific config files.. though i hate it (having so many config files).