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

[xiangdong...@gmail.com]

The issue happens at building time of 'go test' for misc/cgo/test, I was 
expecting 'go test' is powerful enough to skip building a specific case 
given a negation pattern and without involving tags, but just realized it's 
a wrong way, 'go test' always builds all dependency stuff.

Now the requirements are:
1. not building Test7978 on arm64 when running the 'dist' test, and
2. minimize the change so that it could be reverted easily when the link 
issue gets fixed later.

To disable the testing to misc/cgo/test for several 'internal linking' 
cases on arm64 is an option, but that means other 90 tests are skipped 
meanwhile.

On Tuesday, September 1, 2020 at 12:43:57 PM UTC+8 Kurtis Rader wrote:

> 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 additional test files and tags but seeking 
>> for a change to test command line only,
>> other opinions are welcome.
>>
>
> Okay, those links are helpful (and should have been in your first 
> message). I only skimmed each of them but I don't understand why being able 
> to "define a 'negation' pattern" is preferable to using `-tags` to define a 
> "positive pattern" for tests to be run.
>
> -- 
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
>

-- 
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/b909a788-a4b3-4e97-b1c3-0c319eae497en%40googlegroups.com.

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

[Kurtis Rader]

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 additional test files and tags but seeking for
> a change to test command line only,
> other opinions are welcome.
>

Okay, those links are helpful (and should have been in your first message).
I only skimmed each of them but I don't understand why being able to
"define a 'negation' pattern" is preferable to using `-tags` to define a
"positive pattern" for tests to be run.

-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

-- 
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/CABx2%3DD8BQ8v2LLsspTCBLszwTULSkFanvvRUM1MYnS6-VWdF_w%40mail.gmail.com.

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

[xiangd...@arm.com]

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 to test command line only,
other opinions are welcome.

On Tuesday, September 1, 2020 at 11:56:16 AM UTC+8 Kurtis Rader wrote:

> On Mon, Aug 31, 2020 at 8:46 PM xiangd...@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 misc/cgo/test except for a 
>> specific one, say Test7978? 
>>
>
> Knowing why you need to do this might elicit better answers but my 
> recommendation would be to put the test in its own test file and add either 
> a `// +build ignore` comment or use a custom build tag and the `-tags` 
> option to optionally enable it. For example, `go test -tags test7978` and 
> `// +build test7978` at the top of the test file you want run only when 
> explicitly enabled.
>
> -- 
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
>

-- 
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/f689065e-20fe-4147-ae24-ea97c62b9708n%40googlegroups.com.

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

[Kurtis Rader]

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 misc/cgo/test except for a
> specific one, say Test7978?
>

Knowing why you need to do this might elicit better answers but my
recommendation would be to put the test in its own test file and add either
a `// +build ignore` comment or use a custom build tag and the `-tags`
option to optionally enable it. For example, `go test -tags test7978` and
`// +build test7978` at the top of the test file you want run only when
explicitly enabled.

-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

-- 
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/CABx2%3DD95tk3o_ohrL9gXHMxJoCbPyBdMZ14w_y8vtm3%3Dhxhhww%40mail.gmail.com.

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

[xiangdong...@gmail.com]

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 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/56d87527-cdd4-4b86-a86a-5549dd972245n%40googlegroups.com.

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

[Ian Lance Taylor]

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 function() to be used as an 
> argument + return arguments types and numbers based on input arguments
>
> I want to implement a `must` function which I proposed here: 
> https://github.com/golang/go/issues/32219
>
> Based on the current generics proposal, I don't seem to be able to do so.
> Am I missing something or is must outside its ambit?

The current design draft does not support variadic type parameters.
Maybe someday.

Ian

-- 
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/CAOyqgcUFPaZoU46rPsS-RpXA2eAM2Xnr1dEXi_b%3DtHXNGm55MA%40mail.gmail.com.

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

[p...@pjebs.com.au]

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 a `must` function which I proposed here: 
https://github.com/golang/go/issues/32219

Based on the current generics proposal, I don't seem to be able to do so.
Am I missing something or is must outside its ambit?


-@pjebs

-- 
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/a6963665-380b-481e-b75b-618ef4e2548an%40googlegroups.com.

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

[Ian Lance Taylor]

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

-- 
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/CAOyqgcVNjM1jzLQH6isUJyvh8oVj4Ciw-5FxMXfgnWeiOj2yjw%40mail.gmail.com.

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

[Denis Cheremisov]

> 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 errors 
there. Imagine you have requested an item and this leads to fetching data 
from several sources and you got an error at one. Imagine you did not 
decorate it and got some basic network error. It will be nearly useless as 
it is. Decorated one will be useful:

return errors.Wrap(err, "request something from service.method")

And you are asking engineers what is wrong with that service, or dig into 
yourself. Problem solved.

Sure, it is artificial example, but the pricnicple is one: there are lots 
of places where you can get at error in distributed systems. Context is 
extremely useful.

понедельник, 31 августа 2020 г. в 12:06:16 UTC+3, m8il...@gmail.com: 

> 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 := Something(); err != nil {
> >> return err
> >> }
> >>
> >> To make it worth the new keyword make it so that:
> >>
> >> rin v := Something()
> >>
> >> equals to:
> >>
> >> v, err := Something()
> >> if err != nil {
> >> return err
> >> }
> > This is similar to the check/handle design draft, without the handle.
> > You may want to take a look at https://golang.org/issue/40432.
> > Thanks.
>
> I am using flutter and so Dart for the frontend right now, and I have come 
> to a
> conclusion that is related but perhaps beyond magical. It is my opinion 
> that
> having additional syntax simply for syntactic sugar reasons offers little
> benefit but pointless cognitive load when reading code. I now remove 
> syntactic
> sugar in Dart like => and ... in my codebases. As the full syntax does the 
> same
> thing but offers greater functionality, I see negatives with negligible 
> benefit
> in any case.
>
> Especially when there is the potential for code readers to switch from 
> backend
> to frontend and not necessarily being masters in both languages.
>

-- 
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/70a1bb39-cb66-4447-86a4-11a67c576d75n%40googlegroups.com.

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

[samir.el...@gmail.com]

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 generics design
> draft.
>
> 1.
>
> We’re going to settle on square brackets for the generics syntax.
> We’re going to drop the “type” keyword before type parameters, as
> using square brackets is sufficient to distinguish the type parameter
> list from the ordinary parameter list. To avoid the ambiguity with
> array declarations, we will require that all type parameters provide a
> constraint. This has the advantage of giving type parameter lists the
> exact same syntax as ordinary parameter lists (other than using square
> brackets). To simplify the common case of a type parameter that has
> no constraints, we will introduce a new predeclared identifier “any”
> as an alias for “interface{}”.
>
> The result is declarations that look like this:
>
> type Vector[T any] []T
> func Print[T any](s []T) { … }
> func Index[T comparable](s []T, e T) { … }
>
> We feel that the cost of the new predeclared identifier “any” is
> outweighed by the simplification achieved by making all parameter
> lists syntactically the same: as each regular parameter always has a
> type, each type parameter always has a constraint (its meta-type).
>
> Changing “[type T]” to “[T any]” seems about equally readable and
> saves one character. We’ll be able to streamline a lot of existing
> code in the standard library and elsewhere by replacing “interface{}”
> with “any”.
>
> 2.
>
> We’re going to simplify the rule for type list satisfaction. The type
> argument will satisfy the constraint if the type argument is identical
> to any type in the type list, or if the underlying type of the type
> argument is identical to any type in the type list. What we are
> removing here is any use of the underlying types of the types in the
> type list. This tweaked rule means that the type list can decide
> whether to accept an exact defined type, other than a predeclared
> type, or whether to accept any type with a matching underlying type.
>
> This is a subtle change that we don’t expect to affect any existing
> experimental code.
>
> We think that this definition might work if we permit interface types
> with type lists to be used outside of type constraints. Such
> interfaces would effectively act like sum types. That is not part of
> this design draft, but it’s an obvious thing to consider for the
> future.
>
> Note that a type list can mention type parameters (that is, other type
> parameters in the same type parameter list). These will be checked by
> first replacing the type parameter(s) with the corresponding type
> argument(s), and then using the rule described above.
>
> 3.
>
> We’re going to clarify that when considering the operations permitted
> for a value whose type is a type parameter, we will ignore the methods
> of any types in the type list. The general rule is that the generic
> function can use any operation permitted by every type in the type
> list. However, this will only apply to operators and predeclared
> functions (such as "len" and "cap"). It won’t apply to methods, for
> the case where the type list includes a list of types that all define
> some method. Any methods must be listed separately in the interface
> type, not inherited from the type list.
>
> This rule seems generally clear, and avoids some complex reasoning
> involving type lists that include structs with embedded type
> parameters.
>
> 4.
>
> We’re going to permit type switches on type parameters that have type
> lists, without the “.(type)” syntax. The “(.type)” syntax exists to
> clarify code like “switch v := x.(type)”. A type switch on a type
> parameter won’t be able to use the “:=” syntax anyhow, so there is no
> reason to require “.(type)”. In a type switch on a type parameter
> with a type list, every case listed must be a type that appears in the
> type list (“default” is also permitted, of course). A case will be
> chosen if it is the type matched by the type argument, although as
> discussed above it may not be the exact type argument: it may be the
> underlying type of the type argument. To make that rule very clear,
> type switches will not be permitted for type parameters that do not
> have type lists. It is already possible to switch on a value “x”
> whose type is a type parameter without a type list by writing code
> like “switch (interface{})(x).(type)” (which may now be written as
> “switch any(x).(type)”). That construct is not the simplest, but it
> uses only features already present in the language, and we don’t
> expect it to be widely needed.
>
>
> These changes will soon be implemented in the experimental design on
> the dev.generics branch, and in the go2go playground. Some of them
> already work. We will update the design draft accordingly.
>
>
>

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

[samir.el...@gmail.com]

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 
>>
>>- call these operator signs “brackets”
>>- pretending they are good in a role of brackets — they are not
>>- spreading this nonsense from C syntax family of languages to saner 
>>once — yes, you heard it right. C is known for its chaotic development 
>> and 
>>lack of careful planning.
>>- thinking yet another strange workaround is a good thing
>>
>>
> On terminology:
> US: [brackets], (parens).
> UK: (brackets), [square brackets],
> I'm sure other locales have their own equally confusing names for these 
> things, but the Go team is based in the US, so you can't fault them for 
> using that dialect.
>
> To the rest of your points, I will only say: arguments are more persuasive 
> than insults.
>
>

-- 
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/4866e592-8cf5-4681-8017-b925d4089661n%40googlegroups.com.

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

[Mohamed Yousif]

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 consistency and the one way of doing things. It's indeed boring
to write 'if err ! nil', but I don't like the try catch either. Being
explicit is actually nice and errors as part of return values is more easy
to reason about.

I would rather pollute my code with if err than having two ways for return.


> Which is just a sugar for:
>
>   if err := Something(); err != nil {
> return err
>   }
>
> To make it worth the new keyword make it so that:
>
>   *rin* v := Something()
>
> equals to:
>
>   v, err := Something()
>   if err != nil {
> return err
>   }
>
> --
> 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/955d78f2-67cb-4940-845c-034fb45e816an%40googlegroups.com
> 
> .
>

-- 
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/CAHrL7wHOD-eB%3D7A5C%3DtWW-wAPemBhXB09xQdocUwb87N1uveLQ%40mail.gmail.com.

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

[Zakaria]

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 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 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
>>> anyway. Handling error is rarely done and should be explicit.
>>>
>>> I got better keyword for this: reterr
>>> A portmanteau of return error.
>>>
>>> Pada tanggal Sen, 31 Agt 2020 10.34, Ian Lance Taylor 
>>> menulis:
>>>
 On Sun, Aug 30, 2020 at 7:16 PM Zakaria bin Haris 
 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 := Something(); err != nil {
 > return err
 >   }
 >
 > To make it worth the new keyword make it so that:
 >
 >   rin v := Something()
 >
 > equals to:
 >
 >   v, err := Something()
 >   if err != nil {
 > return err
 >   }

 This is similar to the check/handle design draft, without the handle.
 You may want to take a look at https://golang.org/issue/40432.
 Thanks.

 Ian

>>> --
>>> 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/CAET7USmazC1m-sWrXahCOptL2uGi5x2Xei2KySNx2Pc9ro9ipA%40mail.gmail.com
>>> 
>>> .
>>>
>>

-- 
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/CAET7US%3DCHcCL%2BioBMEt5TVzx66HCEfX5kvuLa_wWwiKq6Y_KMA%40mail.gmail.com.

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

[Kevin Chadwick]

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 := Something(); err != nil {
>> return err
>>   }
>>
>> To make it worth the new keyword make it so that:
>>
>>   rin v := Something()
>>
>> equals to:
>>
>>   v, err := Something()
>>   if err != nil {
>> return err
>>   }
> This is similar to the check/handle design draft, without the handle.
> You may want to take a look at https://golang.org/issue/40432.
> Thanks.

I am using flutter and so Dart for the frontend right now, and I have come to a
conclusion that is related but perhaps beyond magical. It is my opinion that
having additional syntax simply for syntactic sugar reasons offers little
benefit but pointless cognitive load when reading code. I now remove syntactic
sugar in Dart like => and ... in my codebases. As the full syntax does the same
thing but offers greater functionality, I see negatives with negligible benefit
in any case.

Especially when there is the potential for code readers to switch from backend
to frontend and not necessarily being masters in both languages.

-- 
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/d7a23054-25d5-5cb3-2fd1-33a310bf4917%40gmail.com.

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

[Jesse McNelis]

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 important to note that Go has been around for >10 yrs and for the
whole of that time people have proposed this same concept just with varying
syntax.
The concept has been debated on this list for more than a decade. The core
developers are well aware of this possibility and its implications.

-- 
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/CAAuPoqc8rgz3gmfke4mnvjNPcj%3Dr_DjfUK1GEeyVxcQXSESVJA%40mail.gmail.com.

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

[Brian Candler]

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 error or wrapping it with 
context, rather than just passing the raw error upstream.  Having a blessed 
way of saying "just return the raw error" will discourage good error 
handling practice.

-- 
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/176ad5db-362b-499a-856e-ce83bb47a00eo%40googlegroups.com.

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

['Axel Wagner' via golang-nuts]

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 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
>> anyway. Handling error is rarely done and should be explicit.
>>
>> I got better keyword for this: reterr
>> A portmanteau of return error.
>>
>> Pada tanggal Sen, 31 Agt 2020 10.34, Ian Lance Taylor 
>> menulis:
>>
>>> On Sun, Aug 30, 2020 at 7:16 PM Zakaria bin Haris 
>>> 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 := Something(); err != nil {
>>> > return err
>>> >   }
>>> >
>>> > To make it worth the new keyword make it so that:
>>> >
>>> >   rin v := Something()
>>> >
>>> > equals to:
>>> >
>>> >   v, err := Something()
>>> >   if err != nil {
>>> > return err
>>> >   }
>>>
>>> This is similar to the check/handle design draft, without the handle.
>>> You may want to take a look at https://golang.org/issue/40432.
>>> Thanks.
>>>
>>> Ian
>>>
>> --
>> 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/CAET7USmazC1m-sWrXahCOptL2uGi5x2Xei2KySNx2Pc9ro9ipA%40mail.gmail.com
>> 
>> .
>>
>

-- 
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/CAEkBMfGJR5GBNzaVRPp3nXAO9-AhfV%2BGV-Xx8d40GmGONzTgnQ%40mail.gmail.com.

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

['Axel Wagner' via golang-nuts]

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
> anyway. Handling error is rarely done and should be explicit.
>
> I got better keyword for this: reterr
> A portmanteau of return error.
>
> Pada tanggal Sen, 31 Agt 2020 10.34, Ian Lance Taylor 
> menulis:
>
>> On Sun, Aug 30, 2020 at 7:16 PM Zakaria bin Haris 
>> 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 := Something(); err != nil {
>> > return err
>> >   }
>> >
>> > To make it worth the new keyword make it so that:
>> >
>> >   rin v := Something()
>> >
>> > equals to:
>> >
>> >   v, err := Something()
>> >   if err != nil {
>> > return err
>> >   }
>>
>> This is similar to the check/handle design draft, without the handle.
>> You may want to take a look at https://golang.org/issue/40432.
>> Thanks.
>>
>> Ian
>>
> --
> 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/CAET7USmazC1m-sWrXahCOptL2uGi5x2Xei2KySNx2Pc9ro9ipA%40mail.gmail.com
> 
> .
>

-- 
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/CAEkBMfEOAoXQmQPebRFYS7NpGXyyLzeZFoQSA%3DyC86zCbbz_gw%40mail.gmail.com.