Go: proposal: sizeof: add synthetic, pointer-like types

[arnottcr]

The (approved) proposal #29982, excludes complex and dynamic types from the new sizeof package. For primitive, value-like types (structs and arrays), this is in required, since they are of variable length. But synthetic, pointer-like types (channels, functions, interfaces, maps, slices, and strings) instead point to their data and are of constant size. Can we add the following types:

package sizeof

const (
    Channel    = Uintptr
    Function   = Uintptr
    Int        = Uint
    Interface  = Uintptr * 2
    Map        = Uintptr
    Slice      = Uintptr + Int*2
    String     = Uintptr + Int
)

Technically one can calculate the unsafe.Sizeof any of these types today, but the intention of the sizeof package is to make that unsafe interface less necessary. Furthermore, while these types are more complex, we can add test cases to ensure that new architectures or changes to the implementation of these types are reflected in sizeof.

[mdempsky]

But synthetic, pointer-like types (channels, functions, interfaces, maps, slices, and strings) instead point to their data and are of constant size.

This is an implementation detail, not specified by the Go spec. The size of slice []T is arguably constrained as being independent of T because of reflect.SliceHeader, and String is well-defined as unsafe.Sizeof(""), but the other types are currently opaque. E.g., there's no reason that users should assume unsafe.Sizeof(interface{}(nil)) and unsafe.Sizeof(interface{m()}(nil)) are equal.

I'm also wondering what the use cases for these constants would be? In particular, are there use cases where user code is simplified by having (e.g.) sizeof.Channel instead of just using unsafe.Sizeof(...)?

[arnottcr]

The desire is to expose as much unsafe.Sizeof functionality as possible using consts. It is not so much documenting the language specification, as the implementation. As long as we are not concerned with the values of the opaque types changing, something that other consts within the stdlib already do (e.g. unicode.Version), this is effectively just _derived_ information available at compile time.

The main use case I see is access to these values as compile time constants. I was not part of the initial proposal, so may be missing some purposes.

[mdempsky]

I think if there's a need for sizes of types beyond what's currently proposed for package sizeof, we should just add a new builtin sizeof that allows type arguments and returns untyped constants. Then sizeof.Int can just be written as sizeof(int).

Edit: This counter-proposal is further expanded upon (including a working proof-of-concept CL for cmd/compile) here: https://github.com/golang/go/issues/29982#issuecomment-658950758

[arnottcr]

@ianlancetaylor: can you add this to the proposals project?

[ianlancetaylor]

@arnottcr Done.

[rsc]

Putting on hold with the other sizeof issue (#29982).