On Tue, Dec 13, 2016 at 10:48 AM, Jon <jonathan.gill...@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/golang/go/blob/master/src/errors/errors_test.go#L14
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+unsubscr...@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.
