proposal: slices: add FromPointer function

[davidgauch]

Proposal Details

I propose a small, trivial addition to the slices package.

// Safely converts a potentially nil pointer into a slice without copying the underlying data.
// If input is nil the result is the nil slice
// Otherwise the result is a slice with length 1
func FromPointer[T any](t *T) []T {
	if t == nil {
		return nil
	}
	// Safety: T and [1]T have the same memory layout.
	return (*[1]T)(unsafe.Pointer(t))[:]
}

This is inspired by Rust's Option::as_slice which has the main advantage of not doing any copying of the underlying data which can come in handy, especially when dealing with large types such as buffers.

[davidgauch]

This is the code I used to test my proposed function in case it is useful:

func TestFromPointer(t *testing.T) {
	if FromPointer((*struct{})(nil)) != nil {
		t.Error("FromPointer(nil) == nil")
	}

	value := struct{}{}
	fromValuePtr := FromPointer(&value)
	if fromValuePtr == nil {
		t.Error("FromPointer() != nil")
	}
	if len(fromValuePtr) != 1 {
		t.Error("len(FromPointer(&value)) == 1")
	}

	if &fromValuePtr[0] != &value {
		t.Error("&FromPointer(&value) != &value")
	}
}

[seankhliao]

I think we'd need to see many examples of real / existing code that would benefit from this function being added to the standard library.
https://go.dev/doc/faq#x_in_std

[DeedleFake]

How is this any different from just doing unsafe.Slice(t, 1)?

Edit: unsafe.Slice((*int)(nil), 1) causes a panic, so that's slightly different, but is that really worth an entire extra function just to do a nil check?

If you really want something like that, maybe an alternative could be to change unsafe.Slice() to always return a nil slice when given a nil pointer instead of panicking if given a nil pointer and a non-zero length. Considering that nil checks is essentially why unsafe.SliceData() exists, I was actually a bit surprised that that panicked.

[davidgauch]

I think we'd need to see many examples of real / existing code that would benefit from this function being added to the standard library. https://go.dev/doc/faq#x_in_std

I did a quick and dirty search on GitHub and I found ~5 pages of people using *[1]T)(unsafe.Pointer(t))[:] to create slices from references.
Here are some of the examples I found:
https://github.com/elliotchance/c2go/blob/89476bd63d993280494bda13b623460369f3a916/README.md?plain=1#L101
https://github.com/quaadgras/graphics.gd/blob/813884f8347135b699b5f45dfa417504236d3e62/internal/objects.go#L98
https://github.com/chadac/golang/blob/5bc5b13dd94ffd5dae333eae6c6aa34aceb62bf9/src/runtime/mwbbuf.golang#L135
https://github.com/kijimaD/comemo/blob/cf57253cf74f2d0d137c232c8677b4878179bdcc/commit_data/20283.txt#L985

Most of these cases (and the one I encountered which inspired this PR) involve calling a library function with an unfriendly signature.

[davidgauch]

How is this any different from just doing unsafe.Slice(t, 1)?

Edit: unsafe.Slice((*int)(nil), 1) causes a panic, so that's slightly different, but is that really worth an entire extra function just to do a nil check?

If you really want something like that, maybe an alternative could be to change unsafe.Slice() to always return a nil slice when given a nil pointer instead of panicking if given a nil pointer and a non-zero length. Considering that nil checks is essentially why unsafe.SliceData() exists, I was actually a bit surprised that that panicked.

You're not wrong that this could have been implemented with unsafe.Slice(t, 1) and another nil check. I chose to use the pointer casting because I figured the generated code looked better in (and I was right, It avoids two unnecessary conditional jumps)

Also I think adding a safe implementation not in the "unsafe" package is worthwhile; I think most people try to avoid using unsafe when not strictly necessary.

[seankhliao]

126 hits isn't a lot, and ~none of them do a nil check before.
https://github.com/search?q=language%3AGo+%2F%5C%28%5C*%5C%5B1%5C%5D.*%5C%29%5C%28unsafe%5C.Pointer%5C%28.*%5C%29%5C%29%5C%5B%3A%5C%5D%2F&type=code

If were to do something, it'd be in the unsafe package, just like how unsafe.SliceData is "safe", but it's in unsafe because it's a type conversion breaking the regular rules.
And we do have it in unsafe already as pointed out above: unsafe.Slice.

[jakebailey]

This isn't an unsafe operation, it's just one that can only be written with unsafe today, same as other array/pointer/slice conversions that have previously been made legal, like https://go.dev/ref/spec#Conversions_from_slice_to_array_or_array_pointer and co from Go 1.17 and Go 1.20.

A similar (or superseding) ask would be for for the conversion of *T to *[1]T, which than can be sliced into []T. https://go.dev/play/p/Bjkbh-NVI2K

x := 1234
ptr := &x

arr := (*[1]int)(ptr)
slice := arr[:]

In any case, I feel like this is being prematurely closed before hitting the proposal committee.

[seankhliao]

the changes to legality are a language / spec change, a standard library function isn't going to launder current unsafe usage as safe

[jakebailey]

I disagree that this is "laundering", and it seems not abnormal at all for library requests to be determined to actually be better as language changes within the same thread...

[seankhliao]

you're free to file a spec change for what you proposed above

[zigo101]

126 hits isn't a lot,

Thus is just a pure/hard need. Denying it by saying it is a rare case is ridiculous.