Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal: sizeof: add synthetic, pointer-like types #40169

Open
urandom2 opened this issue Jul 11, 2020 · 6 comments
Open

proposal: sizeof: add synthetic, pointer-like types #40169

urandom2 opened this issue Jul 11, 2020 · 6 comments
Labels
Milestone

Comments

@urandom2
Copy link
Contributor

urandom2 commented Jul 11, 2020

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.

@gopherbot gopherbot added this to the Proposal milestone Jul 11, 2020
@mdempsky
Copy link
Contributor

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(...)?

@urandom2
Copy link
Contributor Author

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
Copy link
Contributor

mdempsky commented Jul 15, 2020

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: #29982 (comment)

@urandom2
Copy link
Contributor Author

urandom2 commented Aug 6, 2020

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

@ianlancetaylor
Copy link
Member

@arnottcr Done.

@rsc
Copy link
Contributor

rsc commented Nov 11, 2020

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

@rsc rsc moved this to Hold in Proposals Aug 10, 2022
@rsc rsc added this to Proposals Aug 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: Hold
Development

No branches or pull requests

5 participants