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

unsafe: Sizeof() should use type as parameter #9815

Closed
tcurdt opened this issue Feb 9, 2015 · 10 comments
Closed

unsafe: Sizeof() should use type as parameter #9815

tcurdt opened this issue Feb 9, 2015 · 10 comments

Comments

@tcurdt
Copy link

tcurdt commented Feb 9, 2015

What version of Go are you using (go version)?
go version go1.4.1

What operating system and processor architecture are you using?
OSX 10.10.2 (darwin/amd64)

What did you do?
I am trying to get size of a type

var t T

What did you expect to see?

size := unsafe.Sizeof(T)

should compile

What did you see instead?
Instead I had to use

size := unsafe.Sizeof(t)
@ianlancetaylor
Copy link
Contributor

This is working as documented as intended.

Go is not C.

@bradfitz
Copy link
Contributor

bradfitz commented Feb 9, 2015

You can write:

size := unsafe.Sizeof(T{})

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

@tcurdt
Copy link
Author

tcurdt commented Feb 9, 2015

@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.

@ianlancetaylor
Copy link
Contributor

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.

@tcurdt
Copy link
Author

tcurdt commented Feb 9, 2015

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.

@griesemer
Copy link
Contributor

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.

@stephenmw
Copy link
Contributor

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.

@ianlancetaylor
Copy link
Contributor

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/

@tcurdt
Copy link
Author

tcurdt commented Feb 9, 2015

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.

@rjeczalik
Copy link

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

@mikioh mikioh changed the title unsafe.Sizeof() should use type as parameter unsafe: Sizeof() should use type as parameter Feb 9, 2015
@golang golang locked and limited conversation to collaborators Jun 25, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

7 participants