This is working as documented as intended.

Go is not C.

You can write:

size := unsafe.Sizeof(T{})

... if you don't want a variable.

@bradfitz Thanks, that's a little better.

@ianlancetaylor Could you elaborate on the "why" or point me to an explanation? Because I am after the size of the type - not the instance. Hence it's a little counter intuitive.

Two reasons. The first is that unsafe.Sizeof matches unsafe.Offsetof and unsafe.Alignof, and unsafe.Offsetof in particular can't take a type parameter, since it has to take a selector expression. The second is that unsafe.Sizeof looks and acts like a function call (except that the result is a constant), and function calls in Go can not take type arguments. The predeclared functions make and new are exceptions and as they are predeclared they look clearly distinct from other function calls. Adding an exception for unsafe.Sizeof to take a type parameter means adding another exception that people have to learn, in this case for no useful purpose.

You say you are after the size of the type, not the instance, but that is a distinction without a difference. I could just as easily reply by saying that types have no sizes; only instances of types have sizes.

An uint8 is 1 byte. I don't need an instance of it to figure that out.

Just the fact that unsafe.Sizeof already has an exception ("result is a constant") already shows that something isn't right here (IMO).

Just my 2 cents.

Just the fact that C has a different definition of sizeof than Go doesn't mean that Go is doing something "wrong".

As an aside, unsafe.Sizeof works on general expressions, not just variables. That's useful when you don't have a named type at your hand, for instance.

There are many exceptions in the unsafe package for pragmatic reasons - having a Sizeof return a constant makes it more useful because it can be used in array declarations and constant expressions.

You may want a different Sizeof, but that's not the definition of unsafe.Sizeof.

I don't think saying it looks like a function call and therefore can't take a type is fair. Make and new are both "functions" that take types as parameters. Sizeof already isn't a normal function since it accepts a value of any type (including interface types) and returns a constant. Adding new like support for types would not be very inconsistent.

OK, turn it around. Why should we make such a change?

Clearly the change makes the language more complex, because it introduces additional exceptions, exceptions that all Go programmers must learn. The change makes the implementations more complex, because the various compilers must now accept additional parse trees. The change is not necessary, because it adds no expressive power to the language.

Every language change is a cost/benefit decision. The current status can be justified, however weak you consider the justifications to be. Changing would introduce costs. What are the benefits that justify the costs/

C has really nothing to do with me opening this issue. (Not sure why this is being brought up.)

I just found it very ackward when I encountered it - I asked on IRC and as people agreed and so I opened the issue. I guess the title is a little misleading as it doesn't really have to be solved that way. It just expresses the expectations I had. If there is another way of making it more seamless I would be all for it.

The cost/benefit decision. Well, right now I had to learn that I cannot use types as parameters (for the sizeof). I am not sure that the learning is really an argument (in this case). The intend to not increase the language complexity to keep the implementation simpler I can relate to.

But anyway - all I am saying: it feels off like it is. Maybe think of this when working on go 2.x.

@tcurdt unsafe.Sizeof evaluates expression, changing it to work on type instead would be backward-incompatible.