On Tue, Jul 7, 2020 at 2:56 AM Amnon wrote:
> A sensible, well thought out, design.
>
> My main worry is that we will come unstack in places that are using
> versions of the Go toolchain older than N-2.
> Is there any reason for them not to upgrade? No
> Should they upgrade? Definitely
> But
A sensible, well thought out, design.
My main worry is that we will come unstack in places that are using
versions of the Go toolchain older than N-2.
Is there any reason for them not to upgrade? No
Should they upgrade? Definitely
But some still haven't.
Perhaps we should force them to upgrade
My suggestion was a variation on rsc's #2. Still a simple rule that is easy
for people to remember and doesn't require asking the go command.
Prefer a simple rule compared to any intermediation by a program.
> On Jul 1, 2020, at 11:54 AM, jimmy frasche wrote:
>
> Running find -name "*_*.go" |
Running find -name "*_*.go" | xargs grep " +build" on goroot shows a
lot of files with redundant build tags or additional constraints not
present in the file name so they don't seem like much of a single
point of truth.
I'd be fine with removing file names sometimes implying build tags.
Add build
4. Use two underscores for constraints. At least new constraints.
Aside: Are you plantin' an idea about Plan10?
> On Jul 1, 2020, at 11:06 AM, Russ Cox wrote:
>
> For what it's worth, I am (unsurprisingly) a big fan of the filename-based
> constraints. It's a lightweight convention that has
For what it's worth, I am (unsurprisingly) a big fan of the filename-based
constraints. It's a lightweight convention that has served us incredibly
well. I really like being able to see in a directory listing which files go
with what. It would be unfortunate if we had to put the redundant info
This might as well replace makefiles for testing and other tools. or
similar formats.
//go:test devenv
func TestFoo(t *testing.T) {}
//go:test devenv -failfast -short -cover ./...
func TestFoo2(t *testing.T) {}
//go:test prod
func TestProduction(t *testing.T) {}
$ go test devenv
On Wed, Jul
I agree. I like the filename based constraints, but having both is
annoying and since the comment based constraints are more flexible I
think they'd have to be the ones to stay. I frequently find myself
looking for constraints by grepping for whatever it is I want, but if I
have filename based
FWIW, I *like* the filename-based constraints. I can look at the source for
the OS package (https://golang.org/src/os/) and immediately go to the
_windows.go files to see how they do things on Windows (for example). It's
really obvious from the directory listing, and I don't have to dig into
Hm, though I guess in terms of compatibility, it should be mentioned that
according to the design, this currently valid program wouldn't build at
go1.(N-1) (and later, unless the `foo` build tag is specified):
https://play.golang.org/p/436NUYC7rno
If that's okay, then maybe mandating build tags is
On Wed, Jul 1, 2020 at 1:10 AM roger peppe 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
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
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
13 matches
Mail list logo
