proposal: unsafe: Sizeof isn't unsafe and could be elsewhere

[robpike]

For Go 2, find a better package for unsafe.Sizeof and maybe unsafe.Alignof and
unsafe.Offsetof.

[robpike]

Comment 1:

Labels changed: added languagechange.

[rsc]

Comment 2:

Labels changed: added repo-main.

[rsc]

Comment 3:

Adding Release=None to all Priority=Someday bugs.

Labels changed: added release-none.

[ianlancetaylor]

A program that uses unsafe.Sizeof and friends is sacrificing a certain degree of platform independence. That seems to be the main argument for keeping them in unsafe. (The other thing that makes programs platform dependent is the size of int; that would be addressed if we adopted #19623).

If we do move these functions out of unsafe, they could become predeclared identifiers like len, or we could invent another package known to the compiler. builtin? reflect?

[bradfitz]

It's already in reflect. It's just not as efficient. I suppose the compiler could recognize at least certain (simple) uses of reflect.Type.Size, though.

[bradfitz]

e.g. https://play.golang.org/p/FI189RAF71

[mdempsky]

A simpler solution would probably be for safe mode to only deny access to type unsafe.Pointer, not the entire package unsafe.

[robpike]

People are confused by Sizeof. They think it's like C sizeof (although that might not be how they would describe it themselves). But it's really not, or at least not in a way that's simple to describe. It's hard to define it in a non-operational way. Just look at go doc unsafe.sizeof.

I think a better idea is to make it portable to ask the simple-to-answer questions, perhaps by constants in the reflect or runtime packages: SizeofInt, SizeofBool, etc. We'd leave out SizeofSlice and SizeofString and such because they are confusing.

In other words, handle the safe (that is, simple and non-confusing) case safely, and leave the nastier cases in package unsafe.

[ianlancetaylor]

There doesn't seem to be a strong reason to implement this change. We can consider Rob's suggestion above (runtime.SizeofInt, ...) separately.