On 02/02/14 14:18, Daniel Micay wrote:
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
To add to this, a SizeOf bound would be essentially equivalent to the
Sized bound from DST, and I believe experimentation a while ago decided
that requiring Sized is the common case (or, at least, so common that it
would be extremely annoying to require it be explicit).
Huon
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
