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
arnottcr opened this issue Jul 11, 2020 · 5 comments
Open

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

arnottcr opened this issue Jul 11, 2020 · 5 comments
Labels
Projects
Milestone

Comments

@arnottcr
Copy link
Contributor

@arnottcr arnottcr 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
@gopherbot gopherbot added the Proposal label Jul 11, 2020
@mdempsky
Copy link
Member

@mdempsky mdempsky commented Jul 13, 2020

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

@arnottcr arnottcr commented Jul 14, 2020

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
Member

@mdempsky 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)

@arnottcr
Copy link
Contributor Author

@arnottcr arnottcr commented Aug 6, 2020

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

@ianlancetaylor ianlancetaylor added this to Incoming in Proposals Aug 6, 2020
@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Aug 6, 2020

@arnottcr Done.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Proposals
Incoming
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.