Re: [go-nuts] Any way to exclude testcase(s) from 'go test'?

On Mon, Aug 31, 2020 at 9:03 PM xiangd...@arm.com wrote: > Thanks for replying, background is the github issue 39466 > and its potential fix > under reviewing, we are > trying not to introduce any

Re: [go-nuts] Any way to exclude testcase(s) from 'go test'?

Hi Kurtis, Thanks for replying, background is the github issue 39466 and its potential fix under reviewing, we are trying not to introduce any additional test files and tags but seeking for a change

Re: [go-nuts] Any way to exclude testcase(s) from 'go test'?

On Mon, Aug 31, 2020 at 8:46 PM xiangdong...@gmail.com < xiangdong...@gmail.com> wrote: > I'm looking for a way to exclude one specific testcase (perhaps multiple > in the future) from 'go test' and wondering how to define a 'negation' > pattern? > > For example, how to run all testcases of

[go-nuts] Any way to exclude testcase(s) from 'go test'?

Hi, I'm looking for a way to exclude one specific testcase (perhaps multiple in the future) from 'go test' and wondering how to define a 'negation' pattern? For example, how to run all testcases of misc/cgo/test except for a specific one, say Test7978? Thanks a lot. -- You received this

Re: [go-nuts] [generics] Bugs + something else

On Mon, Aug 31, 2020 at 5:49 PM p...@pjebs.com.au wrote: > > 1. > For this Go 2 snippet: https://go2goplay.golang.org/p/vbfBBmjxaMi > > Why can't I use square brackets when calling the constructor? Sorry, the Go 2 playground isn't fully up to date. > 2. Variadic `any` types + allowing a called

[go-nuts] [generics] Bugs + something else

1. For this Go 2 snippet: https://go2goplay.golang.org/p/vbfBBmjxaMi Why can't I use square brackets when calling the constructor? 2. Variadic `any` types + allowing a called function() to be used as an argument + return arguments types and numbers based on input arguments I want to implement

Re: [go-nuts] Re: [ generics] Moving forward with the generics design draft

On Mon, Aug 31, 2020 at 10:25 AM samir.el...@gmail.com wrote: > > Great improvements. Well done. > > Any intentions to make methods accept additional type arguments ? See https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#No-parameterized-methods . Ian

Re: [go-nuts] rin: return if nil syntactic sugar

> I am using flutter and so Dart for the frontend right now, and I have come to a Error context has a little value in the end user apps, I noticed this too at the example of just CLI utilities. It is totally different when it comes to modern network systems, because there're far more places of

[go-nuts] Re: [ generics] Moving forward with the generics design draft

Great improvements. Well done. Any intentions to make methods accept additional type arguments ? On Friday, August 21, 2020 at 2:28:23 AM UTC+2 Ian Lance Taylor wrote: > After many discussions and reading many comments, we plan to move > forward with some changes and clarifications to the

Re: [go-nuts] [ generics] Moving forward with the generics design draft

Great improvements. Well done. Any intentions of making methods accept additional type arguments ? On Wednesday, August 26, 2020 at 1:54:49 PM UTC+2 Alan Donovan wrote: > On Wed, 26 Aug 2020 at 04:31, Denis Cheremisov > wrote: > >> > possibility of using angle brackets >> >> Please stop >>

Re: [go-nuts] rin: return if nil syntactic sugar

Dear, On Mon, Aug 31, 2020, 4:16 AM Zakaria bin Haris wrote: > Hi, gophers! > > Idk if this has been proposed or discussed before. > > Given the last error handling abbreviation proposal is rejected. How about > some simple syntactic sugar like this: > > *rin* Something() > I love the

Re: [go-nuts] rin: return if nil syntactic sugar

I read the try proposal and they're quite different from my simple suggestion which is just a statement. Pada tanggal Sen, 31 Agt 2020 14.02, Axel Wagner < axel.wagner...@googlemail.com> menulis: > Oh, sorry: I mixed the history up. > AIUI this is the same as the try proposal with a different

Re: [go-nuts] rin: return if nil syntactic sugar

On 2020-08-31 03:34, Ian Lance Taylor wrote: >> Idk if this has been proposed or discussed before. >> >> Given the last error handling abbreviation proposal is rejected. How about >> some simple syntactic sugar like this: >> >> rin Something() >> >> Which is just a sugar for: >> >> if err :=

Re: [go-nuts] rin: return if nil syntactic sugar

On Mon, Aug 31, 2020 at 3:31 PM Zakaria wrote: > If the objections on the too magical handle part, why not cut that part > and retain the check part? > > Most of the time the we just forward the error on to the next level > anyway. Handling error is rarely done and should be explicit. > It's

Re: [go-nuts] rin: return if nil syntactic sugar

On Monday, 31 August 2020 06:32:09 UTC+1, Zakaria wrote: > > If the objections on the too magical handle part, why not cut that part > and retain the check part? > > Most of the time the we just forward the error on to the next level anyway. > Often, good error handling requires replacing the

Re: [go-nuts] rin: return if nil syntactic sugar

Oh, sorry: I mixed the history up. AIUI this is the same as the try proposal with a different keyword and *that* got rejected for the "magical" control flow. On Mon, Aug 31, 2020 at 9:00 AM Axel Wagner wrote: > On Mon, Aug 31, 2020 at 7:32 AM Zakaria wrote: > >> If the objections on the too

Re: [go-nuts] rin: return if nil syntactic sugar

On Mon, Aug 31, 2020 at 7:32 AM Zakaria wrote: > If the objections on the too magical handle part, why not cut that part > and retain the check part? > The objection was mainly on the too magical check part, AIUI. > > Most of the time the we just forward the error on to the next level >