What's the point of the deduction guides for lock_guard and friends?

[T. C.]

P0433R2 added

template<class M> lock_guard(lock_guard<M>) -> lock_guard<M>;
template<class... M> scoped_lock(scoped_lock<M...>) -> scoped_lock<M...>;
template<class M> unique_lock(unique_lock<M>) -> unique_lock<M>;
template<class M> shared_lock(shared_lock<M>) -> shared_lock<M>;

After P0620R0's changes to the class template argument deduction rules, there does not appear to be any reason to have them: the function templates synthesized from those guides have the exact same form as the copy deduction candidate, and in the absence of other explicit guides, they are effectively equivalent in overload resolution (the copy-deduction-candidate tiebreaker being immediately below the explicit/implicit guide tiebreaker).

[Nicol Bolas]

Who says there is a point? The library feature was created due to the absence of the language feature, which was only written up last month.

Think of it as a race condition, with two separate groups of people using two separate tools to fix the same problem.

[Michael Spertus]

Exactly. I believe the deduction guides for lock_guard were rendered moot by the late core change. Ideally, we can remove them editorially. If not, I will write a paper or issue to try to clean up in a DR. 

Mike

Sent from my Verizon, Samsung Galaxy smartphone

[T. C.]

Fair enough. I just want to make sure that there isn't some extra subtle point I overlooked.

While we are talking about cleanup, reference_wrapper's guide is also moot, and lock_guard/unique_lock/shared_lock's constructors all use the mutex_type typedef, making the implicit guides not work, if I understand the newest revision of the rules correctly.

Also, the unordered_*map and unordered_*set guides use different wording for size_type ("of the type deduced by deduction guide" vs. "of the primary unordered_*set template"). I assume that the difference is unintentional?

[T. C.]

On Wednesday, April 12, 2017 at 6:38:02 PM UTC-4, T. C. wrote:

 lock_guard/unique_lock/shared_lock's constructors all use the mutex_type typedef, making the implicit guides not work, if I understand the newest revision of the rules correctly.

Apparently I didn't understand it correctly. Looks like the alias is immediately expanded before the overload set is formed so that the parameter remains deducible (per the "B" example in [over.match.class.deduct]/3), and basic_string::value_type's problem alluded to in P0433R2 is not using a member typedef per se but the fact that said member typedef goes through the traits parameter (which is no longer the case thanks to LWG 2861, also moved in Kona).

[Jonathan Wakely]

On Wednesday, 12 April 2017 23:38:02 UTC+1, T. C. wrote:

Fair enough. I just want to make sure that there isn't some extra subtle point I overlooked.

While we are talking about cleanup, reference_wrapper's guide is also moot, 

I think that and redundant guides for the lock types have all been mentioned on the LWG list (whether anyone made note of that is a different matter :-) I think Mike did).

 

Also, the unordered_*map and unordered_*set guides use different wording for size_type ("of the type deduced by deduction guide" vs. "of the primary unordered_*set template"). I assume that the difference is unintentional?

Dunno / don't remember. I'll let Mike answer that