On 6/13/12 8:06 PM, Bennie Kloosteman wrote:
In User programs in most cases you would just leave it as dynamic
vector ( or better yet some form of collection or enumerable
interface depending on whether it will be frequently changed by the
user). For hard core systems programming you
On 13/06/2012 4:15 PM, Niko Matsakis wrote:
*Implications for writing efficient Rust*
I figured I'd just start with the implications for writing Rust.
Currently, to build up a vector, we rely upon an idiom like:
let mut v = [];
for some loop { v += [elt]; }
Yeah. After we lost the
On 6/14/12 10:23 AM, Graydon Hoare wrote:
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
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...That's a bitter pill, but I guess it was true
before too, it was just unsafe code with an
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
On 12-06-14 11:03 AM, Patrick Walton wrote:
I think of it just like ports and channels; the implementation improved
quite rapidly once we moved it to the library.
Fair enough.
However, we nicely dodged that bullet by not supporting ++ and -- at
all. Very prescient :)
Not really. Reoccurs
On 6/14/12 1:41 PM, Graydon Hoare wrote:
However, we nicely dodged that bullet by not supporting ++ and -- at
all. Very prescient :)
Not really. Reoccurs with foo[bar] += 1;
Well, there's a fairly straightforward desugaring: foo[bar] =
foo[bar] + 1; For ++ it's less certain (you have to
On Jun 14, 2012, at 1:41 PM, Graydon Hoare wrote:
On 12-06-14 11:03 AM, Patrick Walton wrote:
I think of it just like ports and channels; the implementation improved
quite rapidly once we moved it to the library.
Fair enough.
For what it's worth, I've been working on moving vector
On 12-06-14 1:45 PM, Patrick Walton wrote:
On 6/14/12 1:41 PM, Graydon Hoare wrote:
However, we nicely dodged that bullet by not supporting ++ and -- at
all. Very prescient :)
Not really. Reoccurs with foo[bar] += 1;
Well, there's a fairly straightforward desugaring: foo[bar] =
foo[bar] +
On 12-06-13 6:43 PM, Patrick Walton wrote:
+1 for ^T. There's also precedent in Managed C++ (although ^ is a
managed pointer there, while we'd be using it for the opposite).
^ is somewhat ugly, but unsafe pointers are by their very nature ugly
and it's at least a lightweight-looking sigil.
On 6/14/12 4:01 PM, Graydon Hoare wrote:
I actually think if you're going to go down that road you want * to be
unsafe as it is now, and ^ to be your region pointer. That has both more
precedent in other languages and, looking at the above examples, is a
bit less visually noisy.
Bonus
On 06/14/2012 06:06 PM, Patrick Walton wrote:
Well, I'm concerned that Rust code will be littered with ^
everywhere, which doesn't look like a pointer to most programmers.
It'd be nice if, when a programmer looks at a glance at typical Rust
code, the meaning of the pointer sigil were obvious. ^
12 matches
Mail list logo
