Thanks for the thorough answer! I think you answered my question. The errors package was the simplest piece of code I could find where it didn't seem to matter whether a value or pointer was passed so I wanted to know why a pointer was passed instead of a value.
As you mentioned twice now (with proof <https://github.com/golang/go/blob/master/src/errors/errors_test.go#L14>) it did matter that a pointer was passed and the time package is likely a great counter example where Time is retuned as a value instead of pointer from time.New. (I'm now interested to know why time.New does this. I believe I read an explanation some time ago which I'll search for.) I don't have a specific semantic problem per se – I just wanted to learn more about some nuances/uses of the language and you helped greatly. Thanks! On Tuesday, 13 December 2016 12:36:17 UTC, Axel Wagner wrote: > > On Tue, Dec 13, 2016 at 10:48 AM, Jon <jonathan...@gmail.com <javascript:> > > wrote: > >> Axel, that's an interesting thought on why errors.New() returns a >> &errorString. However, I would argue that being able to do >> errors.New("foo") == errors.New("foo") could be seen as a feature by some >> people to break dependencies >> > > Well, not by the authors of the errors package, apparently :) > > Also note, that there is a common adage about not comparing error strings. > I'd also argue, that this is confusing: > return fmt.Errorf("foo failed: %s", v) > In some instances this could be seen as "the same error", even with > different v, in other instances not. I believe it's better to be explicit > about this and not depend on the error-message; the error-message is for > humans to read, not for computers to distinguish (I mean, if nothing else, > comparing strings is less efficient than comparing a pointer). > > > >> Therefore I am not quite convinced this is the sole reason why >> &errorString{} is returned instead of errorString{}. >> > > Allow me to convince you, then: > https://github.com/golang/go/blob/master/src/errors/errors_test.go#L14 > <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fgolang%2Fgo%2Fblob%2Fmaster%2Fsrc%2Ferrors%2Ferrors_test.go%23L14&sa=D&sntz=1&usg=AFQjCNGBrbg1RKyZ8RiCjbNvDJ-w2vX01g> > It's clearly a requirement chosen by the author of the package (which is > rsc, btw, who I CC'ed). And I, at least, can't think of a better way to > achieve this requirement. > > In case any one else reads this, this question/discussion isn't really >> about the errors package it's about what to return from a New function if >> you need similar functionality to the errors package. >> > > I think you should be more precise, than "similar functionality". The > errors package is special, as we've discussed here, in that it has very > specific semantics about how equality works. If you want the same semantics > then do the same thing. If you don't want those semantics, don't do it :) > > I mean, regardless of whether you believe that the semantics where > *intended*, those are the semantics that you'll *get* (and AFAIK they're > the most sensible way to get them), so you should work from that. > > You could also look at time.Time, which has different semantics (it's a > small struct, but it's supposed to be passed around by value and you need > to be aware of the used *time.Location when comparing (and use Before/After > if you are interested in the instant in time). > > There are tons of other examples, each with their own specific semantic. > Knowing what the semantics are, that you are going for, would be helpful > here :) > > >> I want to know what the thought process was behind returning a >> &errorString{} from errors.New instead of errorString{} or even 'type >> errorString string'. >> >> On Saturday, 10 December 2016 22:13:16 UTC, Axel Wagner wrote: >>> >>> >>> >>> On Sat, Dec 10, 2016 at 8:10 PM, Jon <jonathan...@gmail.com> wrote: >>> >>>> I would like to know what my default practice should be when returning >>>> structs from functions. Should I return a value or a pointer? (Assume I >>>> don't need the functionality of returning a pointer and my struct contains >>>> at most one simple field so a vast copy isn't needed if I return a value.) >>>> >>>> A specific example could be the errors package >>>> <https://golang.org/src/errors/errors.go> with errors.New. >>>> >>>> The New function is implemented by returning an errorString pointer: >>>> <https://play.golang.org/p/WPmP8ZVS0_> >>>> >>>> func New(text string) error { >>>> return &errorString{text} >>>> } >>>> >>>> Could it just as easily have been implemented by returning an errorString >>>> value <https://play.golang.org/p/Gawy-mgw2X>? If so why was the >>>> pointer return chosen over value return? >>>> >>> >>> Because that way >>> errors.New("foo") != errors.New("foo") >>> This means, that if two packages were to define errors with the same >>> message by coincidence, they wouldn't get mixed up. >>> >>> >>>> func New(text string) error { >>>> return errorString{text} >>>> } >>>> >>>> Could it also have been implemented as below >>>> <https://play.golang.org/p/H2NIARHO-Y> which looks even simpler? >>>> >>>> func New(text string) error { >>>> return errorString(text) >>>> } >>>> // errorString is a trivial implementation of error. >>>> type errorString string >>>> >>>> func (e errorString) Error() string { >>>> return string(e) >>>> } >>>> >>>> What was the thought process that went into the implementation of the >>>> errors package? Were the latter two implementation options I suggest >>>> considered? If so why were they disregarded? Performance? Coding >>>> standards? >>>> Heap allocation benefits? >>>> >>>> -- >>>> 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...@googlegroups.com. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> -- >> 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...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > -- 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. For more options, visit https://groups.google.com/d/optout.
