This is neat, but I admit I find the MutexGuard example to be uncompelling. The article says:
> For example, how to turn (the handle for) a MutexGuard<RenderState> into a MutexGuard<String> when the programmer writes state.template.
Please don’t. In the examples later in the article, maybe an Option<&A> can be dereferenced and projected to get an optional reference to something inside the A. Fine — Option is logically a value, and you either have a reference or don’t have a reference.
But a MutexGuard is not just a value. It’s a representation of a lock held on a particular mutex. Dropping it has side effects! If I have a MutexGuard<RenderState>, this means that there is a Mutex<RenderState> and that, when the guard drops, the mutex unlocked. A field in the RenderState should not have a guard unless it has its own mutex!
ISTM what’s actually wanted for mutex guard field projections is one of two things:
1. Nicer syntax. The article points out that this works today:
let state: &mut RenderState = &mut *state.lock().unwrap();
Great! Improve the syntax! Or:
2. Use the new machinery to make the actual motivating example work without making up a MutexGuard where none should exist. Have the field projection return an ordinary reference. Is this harder for some reason that having it return MutexGuard?
> For example, how to turn (the handle for) a MutexGuard<RenderState> into a MutexGuard<String> when the programmer writes state.template.
Please don’t. In the examples later in the article, maybe an Option<&A> can be dereferenced and projected to get an optional reference to something inside the A. Fine — Option is logically a value, and you either have a reference or don’t have a reference.
But a MutexGuard is not just a value. It’s a representation of a lock held on a particular mutex. Dropping it has side effects! If I have a MutexGuard<RenderState>, this means that there is a Mutex<RenderState> and that, when the guard drops, the mutex unlocked. A field in the RenderState should not have a guard unless it has its own mutex!
ISTM what’s actually wanted for mutex guard field projections is one of two things:
1. Nicer syntax. The article points out that this works today:
Great! Improve the syntax! Or:2. Use the new machinery to make the actual motivating example work without making up a MutexGuard where none should exist. Have the field projection return an ordinary reference. Is this harder for some reason that having it return MutexGuard?