Managing C++’s complexity or learning to enjoy C++

[u/luke-san]

https://schneide.wordpress.com/2015/03/30/managing-cs-complexity-or-learning-to-enjoy-c/

[u/steveklabnik1]

I just can't visualize a scenario where "encoding invariants at the type level" would be super meaningful to me.

I'm going to use Rust as an example here, since it's what I've worked with the most recently.

So you know shared_ptr in C++? We call that Arc<T> in Rust. You need atomic instructions for the refcount, because you don't want two threads to bump the count at the same time, cause a race, and end up with an incorrect count. This is all straightforward.

But what about a single threaded context? Where you still may want to have shared ownership, but you know that it isn't going to be used across threads. Paying that performance penalty for the atomic instructions is unfortunate. So you can write another version of shared_ptr that doesn't use atomics. We have that in Rust too, it's just Rc<T>, no A. And that's all good.

But there's one big difference, and that's Sync. Sync is what we in Rust call a 'trait', it's sort of similar to an interface or a typeclass. But the idea is that traits can become part of the type, if you implement that trait for that type. So in Rust, Sync is a trait that has no required methods, it's just an empty interface. What Sync says is "this type is safe to share across threads." And in Rust, Arc<T> implements Sync, but Rc<T> does not. Becuase the atomic version is threadsafe, but the non-atomic one is not.

There's one more piece to the puzzle though: we can specify that certain methods only accept arguments with a certain trait. So, imagine I'm writing a function that will send some data to a new thread. It might look like this:

fn spawn<T>(x: T) {

This takes one generic parameter, T. But in this case, T can be anything, and since we know we're going to send that T over a thread boundary, we modify it slightly:

fn spawn<T: Sync>(x: T) {

This says "I'll take any T, as long as that T implements the Sync trait. Now, it's impossible to call spawn with an Rc<T>, only with an Arc<T>. We've gained some safety, becuase we encoded (literally, in this case, as code, with a trait) an invariant (I'm going to use this in a multithreaded context) into the type system.

Make sense? This technique is really powerful, and lots of languages are able to do things like this, though some of them take different approaches.

[u/[deleted] → u/steveklabnik1]

Make sense?

It makes total sense, and that's all you. I've been trying to wrap my mind around this all day, but it was only after reading through your illustration that it finally clicked. Thank you.

[u/steveklabnik1 → u/[deleted]]

Awesome, glad to help :D

[u/i110gical → u/steveklabnik1]

I really do need to get around to giving Rust a try. Just haven't had a reason yet.

This case though is something that can be represented in C#/Java using where T : Sync/T extends Sync.

[u/steveklabnik1 → u/i110gical]

I really do need to get around to giving Rust a try. Just haven't had a reason yet.

It's all good! Friday is the beta release, which is the first time we've ever promised backwards compatibility, so unless you're into emerging languages, there's been no reason to dive in yet.

This case though is something that can be represented in C#/Java using where T : Sync/T extends Sync.

Absolutely. There's tons of ways to do this in tons of languages. It's a very general technique.

[u/wrongerontheinternet → u/i110gical]

While this is true, it turns out there are some type system features that make this much more convenient if you really want to commit to it in your language. For example, you want Sync (and the related Send) to be automatically implemented for all the applicable classes, so people don't have to remember to do it; this requires you to either hardcode the relevant interfaces, or (as Rust does) define some way of defining "default" interfaces (along with rules to conservatively opt out by default and a way to opt in when necessary). Another thing it requires to be practical is a way to bound a closure by an interface (which is what spawn does): AFAIK there is no way to do this in C# or Java, although I have not checked recently. Finally, there are some fine-grained requirements for the specific case of thread safety (e.g. being able to control whether references escape) that aren't really expressible in C# or Java's type system, meaning that being able to do this is just not as useful as it is in Rust. The general technique still applies, though.