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, albeit suboptimal. Therefore I am not quite
convinced this is the sole reason why &errorString{} is returned instead of
errorString{}.
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 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 <javascript:>>
> 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 <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.
