[jstimpfle]

In C++, in particular when restricting to a C like subset, I prefer looking at an expression like

    foo->bar.baz

instead of (in Rust and other modern languages that decided to get rid of the distinction)

    foo.bar.baz

For example, the former lets me easily see that I can copy foo->bar and I now have a copy of baz (and indeed bar). In a newer language, it's harder to see whether we are copying a value or a reference.

[saghm]

I see what you're saying but I'd argue that this is mostly an unnecessary thing to worry about because with the exception of types explicitly opted into being cheaply copyable, you're going to be moving it if you're not accessing it via a reference. The idea is that if you're worried about expensive copies, it shouldn't be possible to copy implicitly in the first place; you'd either explicitly `clone` or you wouldn't be copying it at all.

[jstimpfle]

I'm not worried about expensive copies. I'm worried about being able to understand my systems code. The solution isn't adding more abstractions (like move semantics on top). I don't want to move anything. I want to be clear about taking a reference or making an actual copy, these are deeply, semantically, different. This difference is important for single threaded code but also for concurrency -- not only with mutable data types but also with immutable ones.

Performance is mostly a consequence of clear and direct code. You mostly don't achieve performance by saving individual copies, but by being in control of the code and architecture.

[ibotty]

I don't think your run often into these things, because of Rust's ownership enforcement. But I might be misunderstanding you, because it's all pretty abstract and I might not have the whole context.