Can someone explain this code?

I was looking over this code https://github.com/nu7hatch/gouuid/blob/master/uuid.go#L99 which should generate a new UUID v4. Looking at the NewV4() function it should return a pointer to a UUID right? (which is a slice of bytes) But the function has just return and not return u; or return &u; How does that work?

---

评论：

eugene-d:

https://tour.golang.org/basics/7

daniels0xff:

Thanks.

TheBeard_:

It's because it uses named values in the return definition. So it know what values to return, by them being set in the method. 

daniels0xff:

Now makes sense :D Thanks.

tmornini:

As others have pointed out, because it uses what is, IMNSHO, the only bad "feature" of Go, named returns.

For a language that prides itself on being minimal, how this bit of sorcery made it into the 1.0 spec is beyond my ability to comprehend. :-)

I guess it simply goes to show that nobody bats 1,000. :-)

Perhaps it could be removed in 2.0? How do others feel about it?

P.S. I love Go, and I appreciate the incredible work done by others and given to me for free.

shovelpost:

Agreed.

From what I've heard most people agree that it should be one of the first features to be removed from the language.

Personally I do not mind it too much and what I'd much rather get is a way to do this:

return _, err instead of return struct{}, err

In other words _ should return the zero value of a type.

tmornini:

I'd make that trade any day!

JackOhBlades:

Here here. Named returns I find quite unreadable and inconsistent. Can anyone give a scenario in which named returns are "better"? 

Edit: found some decent reasons on stackoverflow


There are some benefits to naming them: 
It serves as documentation. They are auto-declared and initialized to the zero values. If you have multiple return sites, you don't need to change them all if you change the function's return values since it will just say "return".

tmornini:

I get those "benefits" but don't agree they're net-helpful.

There's always a struggle between convenience and simplicity...

Bake_Jailey:

I definitely agree with using them as documentation. If your function returns (int, error), it's obvious what's going on, but if it returns (int, int), it might not be. I'd be happy if the names were there only for documentation, and not be actual defined variables, if anything.

ChristophBerger:

Agreed, using named return values for documentation is fine. Naked return statements, however, are only misleading and should be avoided. What I mean is:

func f() (min int, max int, err error) { // name the return values
    // lots of code
    return min, max err // always list the return values, never use a naked return
}

Best of both worlds.

tmornini:

Don't do that, put those ints in a struct where they belong. :-)

Bake_Jailey:

Not sure that's always the "right" thing to do. I can think of numerous reasons you wouldn't really want a struct, especially when you want to discard values you don't need. For example, named returns are used like this fairly often in the math library, like with Sincos or Frexp.

tmornini:

What is the disadvantage of a struct that would make you not want one?

joushou:

Well, it's not actually named returns, but naked returns. Named returns could in theory make sense, but naked returns make things a million times worse.
Not the only bad feature either, though. Go has a few nasty warts, but that's in a world where most languages have thousands.

tmornini:

Fair enough.
Perhaps I should have said it's worst feature. :-)