On 14/01/2021 20.06, Brian Bi via Std-Discussion wrote:
> It sounds like the real problem here is that you have a situation where:
>
> - there are overloaded function templates, and
> - a hard error will occur if you attempt to instantiate one of their
> signatures, and
> - this problem can be avoided by simply not specifying a template
> argument list (so deduction will fail and the substitution step that causes
> the hard error will not occur), but for some reason you do need to
> explicitly specify a template argument list in order to call the desired
> overload
>
> If this is your situation, then I guess you are out of luck, but it's hard
> for me to imagine how you end up in this situation in the first place.

"Don't specify template arguments" seems to be the answer. I don't
recall why I originally thought I needed to do that; I have in my head
that something wasn't working without them, but it's working now.

> (Why would it be a good idea to have two overloads where one of them
> takes std::shared_ptr and the other takes std::atomic?)
Well, C++20 perhaps thinks it isn't, but this was happening specifically
with `std::atomic_store`, which has exactly those overloads.
Interestingly, the issue does *not* happen with `std::atomic_load`;
there is something about `std::atomic<T>::value_type` specifically and
not just `std::atomic<T>`, which leaves me still somewhat suspicious of
the "explicit instantiation" argument.

(Naturally, I am some years from being able to compile with C++20.)

-- 
Matthew