On Sat, Feb 1, 2014 at 10:12 PM, Eric Reed <ecr...@cs.washington.edu> wrote:
> 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.
The number of calls to `size_of` isn't a useful metric. It's the
building block required to allocate memory (vectors, unique pointers)
and in the slice iterators (to perform pointer arithmetic). If it
requires a bound, then so will any code using a slice iterator.
> 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?
Yes, it is.
> 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.).
The operators are not implemented for every type as they are for `size_of`.
> I seriously don't see what downside this could possibly have.
Using unique pointers, vectors and even slice iterators will require a
semantically irrelevant `SizeOf` bound. Whether or not you allocate a
unique pointer to store a value internally shouldn't be part of the
function signature.
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
