I agree,
Some of the proposals introduce more trouble than the problem they are solving.
For example, the proposed try works only iff you are returning a single value
of type error. If you have more return values what happens?
--
You received this message because you are subscribed to the
The original, rejected proposal was better because it was a built-in, not a
new keyword, so it didn't break existing tools. Otherwise I don't see a
difference.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and
Error checking in Go: The try keyword.
This isn’t a complete proposal it only describes basic idea and the changes
suggested.
The following are modifications that deals with some of the problems
introduced in the original proposal
Repository: https://gitlab.com/tslocum/godoc-static
Demo output: https://docs.rocketnine.space
Inspired by the recent news of godoc.org shutting down I have created
godoc-static. While we could all migrate to pkg.go.dev, we could also host
and update our documentation ourselves.
When
On Thu, Feb 6, 2020 at 9:51 AM Dax McDonald wrote:
>
> Hit a small snag while using Go 1.14.
> Running go1.14beta1 build main.go on our project, github.com/rancher/rio
> results in
>
> go: github.com/StrongMonkey/linkerd2@v0.0.0-20191021165729-976fad67457a:
> parsing go.mod: go.mod:3: usage: go
On Wed, Feb 5, 2020 at 11:33 PM Manlio Perillo wrote:
>
> Is there some overhead due to preemption?
Sure, but measurements show that performance is better with this
approach, especially at scale.
> About EINTR, I suspect that some programs will have problems.
> As an example
>
Hello,
Hit a small snag while using Go 1.14.
Running go1.14beta1 build main.go on our project, github.com/rancher/rio
results in
go: github.com/StrongMonkey/linkerd2@v0.0.0-20191021165729-976fad67457a:
parsing go.mod: go.mod:3: usage: go 1.23
It looks like we are hitting
