[go-nuts] Re: Advancing the container/set design?

+1 On Monday, July 1, 2024 at 2:49:40 PM UTC-6 twp...@gmail.com wrote: > +1 on this. > > At the moment, every module that needs a set implementation ends up > creating its own, either using map[T]struct{} or map[T]bool. Having a set > implementation in the standard library would significantly i

Re: [go-nuts] Error vs. Panic: Should functions like strings.Repeat return an error value?

Good point integer overflow. Thanks! On Thursday, June 30, 2016 at 10:30:46 AM UTC-6, Andy Balholm wrote: > > When a function is used incorrectly, a panic is appropriate. If the count > comes from an untrusted source, the caller should check that it is > non-negati!e (and not too large) before c

Re: [go-nuts] Error vs. Panic: Should functions like strings.Repeat return an error value?

Ah yes, operations that can and will fail are different than those that fail because of a logic error. Thanks! On Thursday, June 30, 2016 at 10:27:18 AM UTC-6, Ian Lance Taylor wrote: > > On Thu, Jun 30, 2016 at 9:17 AM, Michael Whatcott > wrote: > > The blog post on error

[go-nuts] Error vs. Panic: Should functions like strings.Repeat return an error value?

The blog post on error handling in go establishes the following guideline: > In Go, error handling is important. The language's design and conventions encourage you to explicitly check for errors where they occur (as distinct from the convention