Expose more methods from mapped guards

[katietheqt-old]

While very useful, mapped guards do not currently expose methods such as raw and force_unlock, which makes using them in certain contexts quite difficult. From what I can tell, there's no soundness reason why they haven't been exposed. Would a PR adding the same APIs to them as the other guards be accepted?

[Amanieu]

Yes, I would I accept a PR for these. Fundamentally these are unsafe functions so it's fine to expose them with appropriate warnings.

[Earthcomputer]

I also came across a situation where I needed to downgrade a write mapped guard to a read mapped guard. So there are a few APIs missing.

[grantslatton]

@Amanieu is there any fundamental reason why a mapped guard can't have unlocked(f)? I find myself wanting it right now.

It's maybe slightly weird since you'd actually be unlocking the parent object, not the mapped result, but that's what I want to do.

Open to workarounds too.

[Amanieu]

That's fundamentally unsound because while the mutex is a unlocked, another thread can lock it and then invalidate the mapping. For example, if the mutex contains an enum which has been mapped to one variant, another thread can lock the mutex and switch the enum to the other variant.

[grantslatton]

@Amanieu would it be sound if MappedMutexGuard didn't have a pointer to the mapped data, but rather the original data, and then an impl Fn(&Original) -> &Mapped that it called whenever dereferencing?

(obviously you probably don't want to do this for many reasons, just curious for my own education on soundness here)

[Amanieu]

Yes that would be sound, but then you would lose the type erasure since Original still needs to be in the guard type.

[grantslatton]

That makes sense

If anyone is googling this and trying to do the same thing, I worked around this by making a trait like WriteGuard: DerefMut that has unlocked and map methods, so I can simulate type erasure by using impl WriteGuard<Target = MappedType> all over