I'm interested in exploring (and maybe coding/contributing) an addition that would allow individual source files to identify their own chain of interpreters (somewhat akin to the sha-bang line of shell scripts).

//!FILTER github.com/Osndok/golang-braces/cmd/go-fix-braces
//!FILTER github.com/DAddYE/igo/cmd/indention-instead-of-braces arg1 arg2
//!FILTER /usr/bin/cpp -Dkey=value - -
//!FILTER /usr/bin/sed -E 's/oneThing/another/g'

func main()
{
    //the rest of the file is normal (with the above filter chain)
}

As seen in the first two lines, I was thinking that it would not be too hard to call "go build" if needed for the additional ease of go's fetch/build magic.

The idea being... if anyone:

• is so terribly bothered by any particular/trivial golang design choice that it might exclude them, and
• is a sufficiently advanced programmer to encode the minor difference in a filter

...then the community at large is probably better off having them "in" the golang corner.

What's more... when combined with github, it would provide an easy mechanism for the owners/moderators of golang to gauge what is important to the community (that which they invest time in, and are using) by scanning go repos for an easy-to-match string, and counting/sorting uniques.

There are a few major drawbacks, of course, the biggest of which is probably obvious:

//!FILTER rm -rf /some/important/file

...which could wreck havoc in build servers (don't build as root!).

Therefore, presuming this is not something that is desired in this (the upstream repo), I'd be quite content with this issue being closed for an answer to these questions (to whoever knows):

• at a minimum, what points in the source would need the changes/additional code, and
• if developed, what conditions (if any) might allow such a change in the official repo?