[rust-dev] Fwd: &self/&mut self in traits considered harmful(?)
pcwalton at mozilla.com
Mon Jun 16 10:32:18 PDT 2014
On 6/16/14 7:32 AM, Sebastian Gesemann wrote:
> I think one aspect of the issue is Rust's Trait system itself. It
> tries to kill two birds with one stone: (1) Having "Interfaces" with
> runtime dispatching where Traits are used as dynamically-sized types
> and (2) as type bound for generics. Initially, I found this to be a
> very cool Rust feature. But now, I'm not so sure about that anymore.
> Back in 2009 when "concepts" were considered for C++ standardization,
> I spent much time on understanding the intricacies of that C++ topic.
> This initial "concepts" design also tried to define some type
> requirements in terms of function signatures. But this actually
> interacted somewhat badly with rvalue references (among other things)
> and I think this is one of the reasons why "concepts lite" (a new and
> simplified incarnation of the concepts design, expected to augment
> C++1y standard in form of a technical report) replaced the function
> signatures with "usage patterns". As a user of some well-behaved type,
> I don't really care about what kind of optimizations it offers for +
> or * and how they work. I'm just glad that I can "use" the "pattern"
> x*y where x and y refer to instances of some type. Whether the
> implementer of that type distinguishes between lvalues and rvalues via
> overloading or not is kind of an implementation detail that does not
> affect how the type is being used syntactically. So, I expect "C++
> concepts lite" to be able to specify type requirements in terms of
> "usage patters" in a way that it allows "models" of these "concepts"
> to satisfy the requirements in a number of ways (with move
> optimizations being optional but possible).
> Another thing I'm not 100% comfortable with (yet?) is the funky way
> references are used in Rust in combination with auto-borrowing (for
> operators and self at least) and auto-deref'ing while at the same
> time, they are used as "values" (like C++ pointers as opposed to C++
> references). I've trouble putting this into words. But it feels to me
> like the lines are blurred which could cause some trouble or bad
I don't really want to debate the entire Rust generics system here.
More information about the Rust-dev