In the very old days, errors.New was spelled os.NewError, and it returned
an os.errorString, not an &os.errorString, and so those error
implementations did compare by string value. Arranging for the pointer to
be used instead was done explicitly so that errors.New called with the same
text from multiple packages didn't end up accidentally returning equal
results. For example if you have (somewhat artificially)
package json
var ErrInvalid = errors.New("invalid argument")
package strings
func Something(s string) error { ... return errors.New("invalid
argument") ... }
then it's at least a bit confusing that you might compare the result of
strings.Something(s) to json.ErrInvalid and find they are equal.
The API question was the most important deciding factor, but of course a
pointer comparison is cheaper than a string comparison, and errors are
compared for equality all the time, so that's nice to make cheaper.
Russ
On Tue, Dec 13, 2016 at 8:17 AM, Jon <jonathan.gill...@gmail.com> wrote:
> 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> 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/golan
>> g/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.
>>> 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.
