Is there a way to take an md5 value of a string x in one line?

I want to take the md5 sum (I know it's almost completely broken. I need it for non-crypto code. If CRC32 would be as easy, I'd use it instead).

Right now, I do:

    md5 := md5.Sum([]byte{'a', 'b'})
fmt.Println("Hello, playground" +  hex.EncodeToString(md5[:]))

But I'd rather do that in a single line (why not?). So I plug md5 in, and get

    fmt.Println("Hello, playground" + hex.EncodeToString((md5.Sum([]byte{'a', 'b'}))[:]))

But it won't compile, complaining of

invalid operation md5.Sum([]byte literal)[:] (slice of unaddressable value)

https://play.golang.org/p/dy7aemajWa

Is there a way to shorten it?

---

评论：

Redundancy_:

Make a function?

plectid:

fmt.Printf("%x\n", md5.Sum([]byte("ab")))

allowthere:

I don't want to print it. I want to do something with it, and I don't think (I could be wrong) that fmt.Sptrintf is as fast as EncodeToString

TheMerovius:

It's always possible to do something in a single line. Whether it's possible to do it in a single statement, or expression is a different question.

But it also seems a misguided goal to me. "why not" is not a valid reason when asking how to do something. If you think your two lines aren't readable enough, make a function hexMD5Sum or whatever and use that. Purely minimizing the number of lines is not a contest that go is designed to win at.

ChristophBerger:

Remember the Go proverb, "Clear is better than clever."

allowthere:

I may be wrong, but something like hex.EncodeToString(md5.Sum(myByteArray)) seems simpler than using intermediate values. 

ChristophBerger:

It may be simpler but it is not clearer. The two lines perform two different tasks: The first one does an md5 calculation, the second one turns the result into textual output. Clear separation of concerns.

The combined line mingles these two logically separate steps together. Simpler maybe, as it saves an intermediate value, but less clear IMO.

And I don't see a problem with having an intermediate value. 

allowthere:

I'm not an expert in Go, but I create a temp variable when:


You use it in two places.

You have no choice (your first function returns two variables, so you can't nest. So Atoi can't be nested directly).

You have deep nesting. So a(b(c(d),f(g),h(i,j))) (did I match the parentheses? ) is much less clear than

temp1 := c(d)
temp2 := f(g)
temp3 := h(i,j)
temp4 := b(temp1,temp2,temp3)
a (temp4)

but 

a := XtoA(CtoX(c)) 

is much clearer than 
temp := CtoX(c)
a := XtoA(temp)

It could be that I'll have no choice here because of language semantics, but such a short function chain doesn't seem to merit a temp variable.
Maybe I'll ask it as an independent question on the Reddit.

ChristophBerger:

I understand your reasoning. But the one-liner you came up with does have 4 levels of parentheses, so your point 3 seems to apply here.
But anyway, try to avoid micro-optimization, you just lose time and gain almost nothing. Two lines vs one line; a temp var vs no temp var - this is far less important than finally shipping code that works (and is maintainable, of course).

metamatic:

If CRC32 would be as easy, I'd use it instead

What's hard about using CRC?

epiris:

Please don't
fmt.Printf("%x",&[][md5.Size]byte{md5.Sum(data)}[0])

I'm not even sure it's shorter.. lol