Qualify all calls to std::get

[cor3ntin]

There have been some discussions and confusion about whether std::get
can be specialized for user types.
It can't, it's not a customization point and the standard always
calls it qualified. As the issue has come around a few times,
the standard should make it clear that this calls is always
qualified, like it does for std::move and std::forward.

[cor3ntin]

@jwakely Does this needs an LWG issue or is it sufficiently editorial?

[jensmaurer]

Please review the failed checks: there are now some overfull \hboxes.

@jwakely , do you want to make this happen?

[jwakely]

I think Corentin's rationale is sound. I think some people might object on the basis that they want to see us not qualifying move and forward, so this goes in the wrong direction. But since we're not actually proposing to stop qualifying them at this time, I think adding get to the set makes sense. Let's give this five minutes in an LWG telecon and maybe discuss on the LWG reflector. If nobody has any reasonable objections, we should go ahead as an editorial change.

[JohelEGP]

\\ is novel. It seems to be a line break, rather than a hint (as with non-novel ways to fix an overfull \hbox), so the resulting text isn't justified:




And the last one ate the \ in \tcode{.

[CaseyCarter]

I think some people might object on the basis that they want to see us not qualifying move and forward, so this goes in the wrong direction.

"Some people" here, objecting as expected =) I'm not opposed to explicitly qualifying names, I'm opposed to explicitly qualifying some names explicitly while at the same time explicitly qualifying other names implicitly via blanket wording except for some other names that are implicitly not explicitly qualified so as to enable ADL. It's become nearly impossible to explain to people outside LWG (let alone outside WG21) when and why we qualify names in the library spec. We need to have fewer rules with no exceptions unless our intent is truly that only implementors who attend LWG need to understand.

[jensmaurer]

@cor3ntin , please address @JohelEGP 's comments.
In general, we don't want to break lines super-early; it's even ok to have hyphenation in C++ code snippets. (Breaking after an opn ( is fine, too.)

[cor3ntin]

@jensmaurer I was planning to wait for lwg to set a direction, but also, I'm afraid my latex is failing me - I tried and looked for different approaches and couldn't find how the standard deals with that in general) What solution do you recommend?

[JohelEGP]

how the standard deals with that in general

I know of \-, \brk{}, and turning a \tcode into a codeblock environment.

[JohelEGP]

Here's another, \linebreak: https://github.com/cplusplus/draft/pull/5626/files#diff-3b5851f7056b7c68cb3ba2ab51cf0b75a780c6a11e5e181770067700454ace7bR15081.