[rust-dev] Fwd: &self/&mut self in traits considered harmful(?)

Sebastian Gesemann s.gesemann at gmail.com
Thu Jun 19 04:08:44 PDT 2014


On Tue, Jun 17, 2014 at 1:26 PM, SiegeLord wrote:
> On 06/16/2014 07:03 PM, Sebastian Gesemann wrote:
>>
>> Good example! I think even with scalar multiplication/division for
>> bignum it's hard to do the calculation in-place of one operand.
>
> Each bignum can carry with it some extra space for this purpose.
>
>> Suppose I want to evaluate a polynomial over "BigRationals" using
>> Horner's method:
>>
>>    a + x * (b + x * (c + x * d))
>>
>> What I DON'T want to type is
>>
>>    a + x.clone() * (b + x.clone() * (c + x.clone() * d))
>
> But apparently you want to type
> a.inplace_add(x.clone().inplace_mul(b.inplace_add(x.clone().inplace_mul(c.inplace_add(x.clone().inplace_mul(d))))))

No, it's more like

  a + x * (b + x * (c + x * d)))

At least when a,b,c,d are parameters I continue to use and want not
moved from. And even if I want to use a,b,c,d only once, I don't need
to clone x all the time. No idea what made you write this.

> Because that's the alternative you are suggesting to people who want to
> benefit from move semantics.

The difference is that the short operator-based expression *works*
right now whereas forcing a "moving self type" on to people makes this
expression not compile for types that are not Copy. So, given the two
options, I actually prefer the way things are right now.

Of course, I'm not really 100% happy with it. But it's simple. And there is
only so much you can do without overloading.

I think, to convince people (either way) a deeper analysis is needed.
What implementation techniques are possible? (e.g. extra buffers)
What's the distribution of the different use cases? (How often does
one need a single value more than once?). If we can believe the guys
who invented the Mill CPU architechture, about 90% of the values
computed are only consumed once (I think this was mentioned in the
"Belt" talk). This, for example, does not make the "moving self
parameter" look that bad.

> Why would you deliberately set up a situation
> where less efficient code is much cleaner to write?

Because it's simple and allows the short expression to compile in
*every* use case (even for non-Copy types).

> This hasn't been the
> choice made by Rust in the past (consider the overflowing arithmetic getting
> sugar, but the non-overflowing one not).

Rust also tries to stay simple and does not try to support every
feature C++ has (e.g. overloading on different kinds of references).

Cheers!

On Tue, Jun 17, 2014 at 1:26 PM, SiegeLord <slabode at aim.com> wrote:
> On 06/16/2014 07:03 PM, Sebastian Gesemann wrote:
>>
>> Good example! I think even with scalar multiplication/division for
>> bignum it's hard to do the calculation in-place of one operand.
>
>
> Each bignum can carry with it some extra space for this purpose.
>
>
>>
>> Suppose I want to evaluate a polynomial over "BigRationals" using
>> Horner's method:
>>
>>    a + x * (b + x * (c + x * d))
>>
>> What I DON'T want to type is
>>
>>    a + x.clone() * (b + x.clone() * (c + x.clone() * d))
>
>
> But apparently you want to type
>
> a.inplace_add(x.clone().inplace_mul(b.inplace_add(x.clone().inplace_mul(c.inplace_add(x.clone().inplace_mul(d))))))
>
> Because that's the alternative you are suggesting to people who want to
> benefit from move semantics. Why would you deliberately set up a situation
> where less efficient code is much cleaner to write? This hasn't been the
> choice made by Rust in the past (consider the overflowing arithmetic getting
> sugar, but the non-overflowing one not).
>
> -SL
>
>
> _______________________________________________
> Rust-dev mailing list
> Rust-dev at mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev


More information about the Rust-dev mailing list