proposal: spec: allow unsafe.Alignof and unsafe.Sizeof to take a type literal argument

[mdempsky]

Proposal:

Relax unsafe.Alignof and unsafe.Sizeof to accept either an expression or type literal argument.
If a type literal argument is provided, then they return the alignment or size (respectively) of the specified type.

Arguments for:

• Simple consistent syntax for finding the alignment or size of a type, regardless of its underlying type.
• Within the standard library, there are 105 instances of (Align|Size)of\([^)]*(\(0\)|\{\})\).

Arguments against:

• Just turd polishing; "using package unsafe is going to be ugly anyway".
• You can already write something like unsafe.Sizeof(*new(T)) if you can't/don't know the underlying type of T.
• Use cases are much less common outside of the standard library.

Notes:

• Go's function call syntax already allows the first argument to be a type rather than an expression.
  • Caveat: While the built-in functions make and new take a type instead of an expression, unsafe.Alignof and unsafe.Sizeof would be the first functions to accept either a type or expression.
• In the expression a.b, a may already be either an expression or a receiver type.
  • Caveat: unsafe.Alignof(x) and unsafe.Sizeof(x) would be the first expressions where x can be either an expression or an arbitrary type literal (i.e., not just T or *T, but also []T, chan T, struct{T}, etc).
• Because unsafe.Alignof and unsafe.Sizeof are defined as compile-time constant expressions, type checking code already needs to special case them (i.e., as opposed to stubbing them as something like func Sizeof(x interface{}) uintptr).
• If the untyped composite literal proposal is accepted, parsers/type-checkers/compilers/etc will need to be updated for Go 1.6 anyway.
• Proof-of-concept CLs:
  • cmd/compile: https://golang.org/cl/16092
  • go/types: https://golang.org/cl/16093

CC @griesemer

[minux]

Most of the use of unsafe.Sizeof/unsafe.Alignof in the standard library, which means the simplification won't simplify a lot of normal programs. And consider that a lot of packages can't afford to be only compiled by Go 1.6 and above, I think even if this is accepted, pretty much only the standard library will use it. The benefit is not much but the disadvantage of using it -- losing support for all pre-Go 1.6 versions -- is high enough that I doubt people will use the new form. How many times do you actually want to know the size of a type without knowing whether it is primitive type or aggregate type?

[rsc]

As Minux said, I think this simplifies very few real programs. And I think doing this would only add to the confusion about the semantics, especially given the recent confusion in CL 16004.

I would like to leave things alone.

[adg]

As this hasn't been responded to since its original proposal, and there is significant objection to the proposal, I am going to close this.