spec: allow conversion from slice to array

[bradfitz]

I recently tried to use the new #395 feature (for converting a slice to an array pointer: https://golang.org/cl/216424) in:

https://go-review.googlesource.com/c/go/+/322329

But in review, it was pointed out that it was a little ugly, as what I wanted to return was an array, which required a dereference:

	return *(*[Size224]byte)(sum[:Size224])

It would've been nicer if I could've just converted to an array instead:

	return ([Size224]byte)(sum[:Size224])

Talking to @ianlancetaylor and @griesemer, we couldn't remember great reasons for not also allowing this as part of #395. It does mean there's an subtle copy, but arguably the * dereference above is also a somewhat subtle copy.

Could we also add support for converting to the array?

/cc @katiehockman @josharian @rogpeppe @mdempsky

[randall77]

Note the [:Size224] is unnecessary. There, I saved you more characters than the 2 *s you were worried about!

I think the decision to omit direct-to-array casts was just to keep the feature change minimal. We need the cast-to-pointer regardless to support aliasing to the same backing store, and cast-to-array is easily implemented using cast-to-pointer.

[zigo101]

Some like #36890

[mdempsky]

I don't immediately see anything wrong with allowing slice to array conversions, but I feel like saving two asterisks in an already rather niche feature doesn't justify the extra complexity on compilers and tooling.

[bcmills]

Since this conversion would do a copy anyway, would we also add a conversion from string to [N]byte for consistency?

[rsc]

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

[rogpeppe]

FWIW I didn't propose this originally because it could easily be implemented, even prior to #395, by using copy, albeit not quite so concisely.

I'm not entirely convinced that it's worth it tbh, especially given the possibility for the expression to panic.

[katiehockman]

Question: is it possible to make changes to copy() so that it is equally performant to the *(*array)(slice) conversion? Then we don't need to support this additional conversion at all, and it can just be common practice to use copy in such situations.

FWIW I'm a lot less concerned about a few extra characters in the line than I am about readability. I was pretty confused as a reader to see a conversion in the form *(*array)(slice). I read it as "Cast a slice to a pointer to an array, then dereference this array", which felt more like a hack than a best practice. But maybe I just need to get used to it.

[mdempsky]

Question: is it possible to make changes to copy() so that it is equally performant to the *(*array)(slice) conversion? Then we don't need to support this additional conversion at all, and it can just be common practice to use copy in such situations.

Probably. I don't think there's any fundamental reason they'd perform differently. Can you file an issue with examples of code that you think should perform equivalently, and we can look into it for Go 1.18?

I was pretty confused as a reader to see a conversion in the form *(*array)(slice). I read it as "Cast a slice to a pointer to an array, then dereference this array"

Assuming you meant "dereference this [pointer to] array", that description is pretty much how I think of it, though arguably it's more of a (checked) "assertion" (as in type assertions), as conversions generally can't fail. A slice is a pointer + dynamic length (and capacity). The conversion here is changing it to a pointer + static length, with a runtime check to ensure the lengths are compatible.