On Wed, Jul 1, 2020 at 1:10 AM roger peppe <rogpe...@gmail.com> wrote:
> LGTM. This is a welcome change. I often need to look up how to spell > "// +build" currently :) > > One thing I'd really like to see is the eventual deprecation of > filename-based build constraints (e.g. file_linux.go). > They make it hard for users (not everyone knows the name of all > architectures), hard for tooling (tools > need to maintain a list of current architectures) and potentially > compatibility-breaking (adding > a new architecture can change the meaning of existing files). Could we > eventually mandate > in-file build constraints instead? > I think *mandating* this could be considered a backwards incompatible change (the only real counter-argument is that it's "just tooling"). AIUI, Russ' design doesn't actually remove `// +build` for this reason, but only deprecates it with automatic re-writing. Of course, nothing would prevent us from doing the same - deprecating purely filename-based constraints and have `gofmt` actively add build tags. Note that the filenames wouldn't go away anyways; you still need separate files, so you still need separate names. You wouldn't need *these specific* names, but you'd probably end up with very similar ones. If you'd indeed suggest removing file name based constraints altogether, I'd argue that it should probably happen in this same process (not "eventually" :) ) - it involves touching ~every Go package with constraints anyway, so having to only do this once would probably be preferable. > > cheers, > rog. > > > On Tue, 30 Jun 2020 at 21:04, Russ Cox <r...@golang.org> wrote: > >> Hi all, >> >> I've posted a draft design for replacing // +build lines with //go:build >> lines that support standard boolean expression syntax. It is a draft design >> I'm circulating for feedback, not an official proposal. (I certainly hope >> it will be well received and can be made into a proposal, but that's not >> where we are today.) >> >> If you are interested, there is a doc and a video, linked below. As an >> experiment, I'd like to try using Reddit for the discussion, also linked >> below. The idea is that proper threading support should scale better than >> GitHub or a single large mail thread here would. But for those who don't do >> Reddit, I will keep an eye on this thread and reply as best I can. >> >> Video: https://golang.org/s/go-build-video >> Design: https://golang.org/s/go-build-design >> Q&A: https://golang.org/s/go-build-reddit >> >> Thanks! >> >> Best, >> Russ >> >> -- >> You received this message because you are subscribed to the Google Groups >> "golang-nuts" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to golang-nuts+unsubscr...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/golang-nuts/CAA8EjDTO1NX%3DacOTqEfD%3D6pumUWzNNcGO%2BsPMrQVYdO0cmWsvQ%40mail.gmail.com >> <https://groups.google.com/d/msgid/golang-nuts/CAA8EjDTO1NX%3DacOTqEfD%3D6pumUWzNNcGO%2BsPMrQVYdO0cmWsvQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/CAJhgacjXjt%2BhKVOLadcRxvwMnWRMJS%2BPwnKt8GdCa%2Bc77GUmRQ%40mail.gmail.com > <https://groups.google.com/d/msgid/golang-nuts/CAJhgacjXjt%2BhKVOLadcRxvwMnWRMJS%2BPwnKt8GdCa%2Bc77GUmRQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAEkBMfE5_nmDLd_WNO88ChzSoVAh77mCxgxEreo9xa%2BuN77fkQ%40mail.gmail.com.
