On Jun 16, 2014, at 3:03 PM, Cameron Zwarich <zwar...@mozilla.com> wrote:

> On Jun 16, 2014, at 2:24 PM, Patrick Walton <pcwal...@mozilla.com> wrote:
> 
>> On 6/16/14 1:04 PM, Sebastian Gesemann wrote:
>>> Am 16.06.2014 19:36, schrieb Patrick Walton:
>>>> On 6/16/14 7:32 AM, Sebastian Gesemann wrote:
>>>>> Assuming this RFC is accepted: How would I have to implement Add for a
>>>>> custom type T where moving doesn't make much sense and I'd rather use
>>>>> immutable references to bind the operands?
>>>> 
>>>> You don't implement Add for those types.
>>> 
>>> As far as I'm concerned that's anything but a satisfactory answer. I
>>> really don't see the point of your RFC. If anything, it seems to make
>>> things worse from my perspective. That's why I asked you for some
>>> clarifications. Of course, you don't owe me anything. And I hope you
>>> don't take this personally.
>> 
>> I don't see much of a use case for `Add` without move semantics. Does anyone 
>> have any?
>> 
>> Strings and vectors, perhaps, but I would argue that having to call 
>> `.clone()` on the LHS or RHS (as appropriate) is an improvement, because 
>> cloning strings and vectors can be very expensive.
> 
> This applies to Mul rather than Add, but if you are multiplying matrices then 
> you want the destination to not alias either of the sources for vectorization 
> purposes, so passing by reference is preferred.

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.

Cameron
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Reply via email to