Well there's only 260 uses of the string "size_of" in rustc's src/
according to grep and only 3 uses of "size_of" in servo according to
GitHub, so I think you may be overestimating its usage.
Either way, I'm not proposing we get rid of size_of. I just think we should
put it in an automatically derived trait instead of defining a function on
all types.
Literally the only thing that would change would be code like this:
fn foo<T>(t: T) {
let size = mem::size_of(t);
}
would have to be changed to:
fn foo<T: SizeOf>(t: T) {
let size = SizeOf::size_of(t); // or t.size_of()
}
Is that really so bad?
Now the function's type signature documents that the function's behavior
depends on the size of the type.
If you see a signature like `fn foo<T>(t: T)', then you know that it
doesn't.
There's no additional performance overhead and it makes size_of like other
intrinsic operators (+, ==, etc.).
I seriously don't see what downside this could possibly have.
On Sat, Feb 1, 2014 at 6:43 PM, Daniel Micay <[email protected]> wrote:
> On Sat, Feb 1, 2014 at 9:27 PM, Eric Reed <[email protected]>
> wrote:
> >
> > I wasn't aware of mem::size_of before, but I'm rather annoyed to find out
> > we've started adding bare A -> B functions since it breaks parametricity.
> > I'd much rather put size_of in a trait, at which point it's just a weaker
> > version of Any.
>
> You do realize how widely used size_of is, right? I don't this it
> makes sense to say we've *started* adding this stuff when being able
> to get the size/alignment has pretty much always been there.
>
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
