On 6/14/12 10:23 AM, Graydon Hoare wrote:
What disappoints me about all this is that the language is now dependent
on unsafe library code in order to do asymptotically fast aggregate
types at all. The += optimization and vec doubling-allocation was the
"one primitive" related to aggregate types that the compiler was filling
in for us safely, before, for the sake of building more-efficient
containers on top. Now pretty much every primitive container that has a
doubling-store growth pattern is going to involve unsafe code. That's a
bitter pill, but I guess it was true before too, it was just unsafe code
with an interface curated by the compiler and runtime, not core library :(
Actually, I think it'd be great if we moved that stuff out of the
language itself. I think that, ceteris paribus, code in core is easier
to debug and get right than code in trans.
I think of it just like ports and channels; the implementation improved
quite rapidly once we moved it to the library.
But this general move feels like obscuring a pretty important bug, that
I'm inclined to point out: we need to expand operator overloading to
have op= forms, in general, such that a user could _define_ a version of
+= that does what the compiler currently does, when that's reasonable
(overload arg-type symmetry aside). Operator overloading is simply
incomplete here; likewise, fn [](...) needs to have a 3-arg lval form,
not try to "return a mutable ref" or something.
Yes, I've thought this for a while. D is good precedent here, with its
opIndexAssign. Note that D got in trouble here, though; in a custom
user-defined dictionary type, this can be made to work:
foo["bar"] = 3;
But this doesn't:
foo["bar"]++;
However, we nicely dodged that bullet by not supporting ++ and -- at
all. Very prescient :)
Patrick
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
