On Jun 16, 2014, at 3:19 PM, Patrick Walton pcwal...@mozilla.com wrote:
On 6/16/14 3:17 PM, Cameron Zwarich wrote:
I stated the right case, but the wrong reason. It’s not for
vectorization, it’s because it’s not easy to reuse the storage of a
matrix while multiplying into it.
Wouldn't most
Can you elaborate a bit more on why/how exactly did the earlier language design
(implicitly clone by default if it's absolutely necessary and otherwise move,
instead of move by default) result in much more cloning? Because intuitively it
seems to me that if you try to use data that has been
On 2014-06-15, at 21:10, Isaac Dupree m...@isaac.cedarswampstudios.org wrote:
On 6/12/14 11:15 AM, Tommi wrote:
But I think it will be easy to make the error of writing the explicit
.clone() in places where it's not needed. For example:
[...]
Would a compiler warning for unnecessary clones
The manner in which the expression accomplishes this task is an
implementation detail.
You're welcome to draft a proposal if you think that you have an idea to
make this possible. Though all of the solutions that I can envision require
abandoning the idea of operators-as-traits and introducing a
On 2014-06-15, at 9:56, Benjamin Striegel ben.strie...@gmail.com wrote:
You're welcome to draft a proposal if you think that you have an idea to make
this possible.
The idea of the `stable` keyword was designed specifically as a bandage on the
current trait-system to allow a trait to say
I realized that, in my proposal, there's a potentially pretty confusing
asymmetry of what `stable` means. In the trait definition:
pub trait MulRHS, Result {
fn mul(stable self, rhs: RHS) - Result;
}
...the keyword `stable` means that however the type which implements this trait
decides to
On 6/12/14 11:15 AM, Tommi wrote:
But I think it will be easy to make the error of writing the explicit
.clone() in places where it's not needed. For example:
[...]
Would a compiler warning for unnecessary clones be feasible? useful?
Would it have false positives -- situations where a clone
I think that the deeper and larger language design issue here is that traits in
some cases force you to impose on the trait-implementing type some
implementation details that should remain hidden in the specification of the
trait and should be left to the trait-implementing type to specify.
The problem:
Chained calls to certain operators such as binary `*` and `+` may cause
unnecessary memory allocations. For example:
struct Vector {
coordinates: Vecint
}
impl Mulint, Vector for Vector {
fn mul(self, rhs: int) - Vector {
let mut new_coordinates =
On 2014-06-13, at 13:14, Tommi rusty.ga...@icloud.com wrote:
pub trait MulRHS, Result {
fn mul(stable self, rhs: RHS) - Result;
}
Note: any other syntax for marking `self` as `stable` would be illegal.
Although, I could see this kind of syntax being allowed as well:
pub trait MulRHS,
I have filed RFC #118 for this:
https://github.com/rust-lang/rfcs/pull/118
Patrick
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
On 2014-06-11, at 16:27, SiegeLord slab...@aim.com wrote:
So, I think the situation is pretty bad. What can be done to fix it?
I agree that this seems like a serious regression from C++. If it won't be
fixed, I think I'll rather stick with C++. Better the devil you know...
On 6/12/14 1:02 AM, Tommi wrote:
On 2014-06-11, at 16:27, SiegeLord slab...@aim.com
mailto:slab...@aim.com wrote:
So, I think the situation is pretty bad. What can be done to fix it?
I agree that this seems like a serious regression from C++. If it won't
be fixed, I think I'll rather stick
On 6/11/14 6:27 AM, SiegeLord wrote:
So, I think the situation is pretty bad. What can be done to fix it?
Seems to me we can just make the overloaded operator traits take
by-value self.
Patrick
___
Rust-dev mailing list
Rust-dev@mozilla.org
On 2014-06-12, at 19:08, Patrick Walton pcwal...@mozilla.com wrote:
On 6/11/14 6:27 AM, SiegeLord wrote:
So, I think the situation is pretty bad. What can be done to fix it?
Seems to me we can just make the overloaded operator traits take by-value
self.
I definitely wouldn't want to see
You could just clone the value to get around that error.
On June 12, 2014 10:03:40 AM PDT, Tommi rusty.ga...@icloud.com wrote:
On 2014-06-12, at 19:08, Patrick Walton pcwal...@mozilla.com wrote:
On 6/11/14 6:27 AM, SiegeLord wrote:
So, I think the situation is pretty bad. What can be done to
Or bound by Copy.
On Thu, Jun 12, 2014 at 10:17 AM, Patrick Walton pwal...@mozilla.com wrote:
You could just clone the value to get around that error.
On June 12, 2014 10:03:40 AM PDT, Tommi rusty.ga...@icloud.com wrote:
On 2014-06-12, at 19:08, Patrick Walton pcwal...@mozilla.com wrote:
I think a new keyword, something like `stable`, is needed for specifying that
an argument passed to a trait function is guaranteed to be logically unchanged
after the function call. For example:
trait Foo {
fn foo(stable self);
}
impl Foo for int {
fn foo(self) {} // OK
}
impl Foo for
It's called Copy. `trait Foo: Copy { ... }`.
On Thu, Jun 12, 2014 at 10:26 AM, Tommi rusty.ga...@icloud.com wrote:
I think a new keyword, something like `stable`, is needed for specifying that
an argument passed to a trait function is guaranteed to be logically
unchanged after the function
`Copy` types aren't really relevant to a discussion about adding to Rust the
C++ like optimization of moving rvalues (of non-Copy types) when they're passed
to certain functions.
On 2014-06-12, at 20:30, Corey Richardson co...@octayn.net wrote:
It's called Copy. `trait Foo: Copy { ... }`.
On 6/12/14 10:46 AM, Tommi wrote:
`Copy` types aren't really relevant to a discussion about adding to
Rust the C++ like optimization of moving rvalues (of non-Copy types)
when they're passed to certain functions.
There's nothing to add to Rust. Rust supports moves.
Patrick
Implicit cloning is a non-starter. Clones can be very expensive.
Hiding that cost is undesirable and would require adding Clone to the
language (it's currently a normal library feature).
On Thu, Jun 12, 2014 at 10:46 AM, Tommi rusty.ga...@icloud.com wrote:
`Copy` types aren't really relevant to
On 2014-06-12, at 20:51, Patrick Walton pcwal...@mozilla.com wrote:
On 6/12/14 10:46 AM, Tommi wrote:
`Copy` types aren't really relevant to a discussion about adding to
Rust the C++ like optimization of moving rvalues (of non-Copy types)
when they're passed to certain functions.
There's
Sorry, Im a little new to Rust, but I'm,as many, now considering moving
from c++ to Rust and the topic is really important for my tasks.
Could you give an Rust example for the concern listed above?
Thank you!
On Jun 12, 2014 9:51 PM, Patrick Walton pcwal...@mozilla.com wrote:
On 6/12/14 10:46
On 2014-06-12, at 20:59, Corey Richardson co...@octayn.net wrote:
Implicit cloning is a non-starter. Clones can be very expensive.
Hiding that cost is undesirable and would require adding Clone to the
language (it's currently a normal library feature).
But I think it will be easy to make the
On 6/12/14 11:15 AM, Tommi wrote:
On 2014-06-12, at 20:59, Corey Richardson co...@octayn.net
mailto:co...@octayn.net wrote:
Implicit cloning is a non-starter. Clones can be very expensive.
Hiding that cost is undesirable and would require adding Clone to the
language (it's currently a normal
On 2014-06-12, at 21:15, Patrick Walton pcwal...@mozilla.com wrote:
On 6/12/14 11:15 AM, Tommi wrote:
On 2014-06-12, at 20:59, Corey Richardson co...@octayn.net
mailto:co...@octayn.net wrote:
Implicit cloning is a non-starter. Clones can be very expensive.
Hiding that cost is undesirable
For some reason I got really side-tracked here. The whole point of that
`stable` keyword I proposed was not syntax sugar, but that it allows the
implementor of such a trait to pass by reference when the operator shouldn't
move the passed in argument(s). Like, when you multiply two matrices and
On Wed, Jun 11, 2014 at 3:27 PM, SiegeLord wrote:
[...] Along the same lines, it is not immediately obvious
to me how to extend this lazy evaluation idea to something like num::BigInt.
So far, it seems like lazy evaluation will force dynamic dispatch in that
case which is a big shame (i.e.
On 11/06/14 23:27, SiegeLord wrote:
Aside from somewhat more complicated impl's, are there any downsides
to never using anything but by value 'self' in traits?
Currently trait objects do not support `self` methods (#10672), and,
generally, the interactions with trait objects seem peculiar,
On 06/11/2014 10:10 AM, Sebastian Gesemann wrote:
On Wed, Jun 11, 2014 at 3:27 PM, SiegeLord wrote:
[...] Along the same lines, it is not immediately obvious
to me how to extend this lazy evaluation idea to something like num::BigInt.
So far, it seems like lazy evaluation will force dynamic
If the `Mul` trait and similar were changed to take `self` by value, perhaps
the following kind of language design would make more sense:
If a variable of a type that has a destructor is passed to a function by value
(moved), and the variable is used after the function call, the variable would
On 11/06/14 01:54 PM, Tommi wrote:
If the `Mul` trait and similar were changed to take `self` by value, perhaps
the following kind of language design would make more sense:
If a variable of a type that has a destructor is passed to a function by
value (moved), and the variable is used
On 2014-06-11, at 21:33, Daniel Micay danielmi...@gmail.com wrote:
Cloning big integers, rationals based on big integers or arbitrary
precision floating point values for every single operation has a high
cost.
I didn't say that all functions should start taking their arguments by value. I
Keeping in mind that the `self` value here can be a reference. Ie,
implementing the traits also for references to a type.
On Wed, Jun 11, 2014 at 11:47 AM, Tommi rusty.ga...@icloud.com wrote:
On 2014-06-11, at 21:33, Daniel Micay danielmi...@gmail.com wrote:
Cloning big integers, rationals
On 2014-06-11, at 21:47, Tommi rusty.ga...@icloud.com wrote:
I said `Mul` and similar should do it, i.e. functions that take a variable
and return a variable of that same type.
Although, a larger issue of genericity is that multiplication doesn't always
return the same type as one of its
36 matches
Mail list logo
