[linalg.conj.conjugated] Rearrange to match P3050R3

[jwakely]

This was the wording requested by LWG and approved in P3050R3, but I mistakenly put P3050R2 in the straw polls.

[jwakely]

@mhoemmen another fix for an incorrect straw poll

[mhoemmen]

I compared this against P3050R3; it looks good! Thanks! : - )

[jensmaurer]

How is this editorially-obviously related to the struck text talking about conj(E) ?

[jwakely]

You need to read the preceding paragraph too. In R2 (as applied to the draft) the text in p2 talking about conj(E) was duplicating exactly the condition in 1.3, which was just unnecessarily verbose and repetitive.

We don't need to repeat exactly the two conditions in 1.2 and 1.3 as 2.2 and 2.3, we can just say that if the type A determined in p2 is Accessor, then we return a.

So this is replacing everything in p2 that repeats conditions from p1 by specifying the return value in terms of what was determined in p1.

[jwakely]

In other words, previously we had:

• (1.2) Accessor if remove_cvref_t<ElementType> is an arithmetic type; otherwise,

• (1.3) Accessor if the expression conj(E) is not valid for any subexpression E whose type T is expression-equivalent to remove_cvref_t<ElementType> with overload resolution performed in a context that includes the declaration template<class T> conj(const T&) = delete;; otherwise,

and

• (2.2) a if remove_cvref_t<ElementType> is an arithmetic type; otherwise,

• (2.3) a if the expression conj(E) is not valid for any subexpression E whose type T is expression-equivalent to remove_cvref_t<ElementType> with overload resolution performed in a context that includes the declaration template<class T> conj(const T&) = delete;; otherwise,

But now p2 just says we return a if it's already the right type and doesn't need to be transformed.

[jensmaurer]

Thanks for the explanation.