[2018-06 LWG Motion 28] P0898R3 Standard library concepts

[jensmaurer]

P0898R3

[tkoeppe]

We should get the LaTeX sources from @CaseyCarter. I'd very much like to have an authoritative source for the stable labels that are used throughout the new wording.

[jensmaurer]

We still have to double-check the labels as per our current policy.

[CaseyCarter]

I plan to cleanup my latex sources and prepare the PR for P0898. Could someone please assign this issue to me so there's no confusion among the editors?

[jensmaurer]

Apparently, you can't assign to foreign people :-(

Assigning to myself to mark it as "taken" in the interim.

[zygoloid]

I've reconfigured GitHub so all editors can be assigned issues on this repository.

[CaseyCarter]

@timsong-cpp has pointed out to me that [meta.trans.other]/3.2:

[let] XREF(A) denote a unary class template T such that T<U> denotes the same type as U with the addition of A’s cv and reference qualifiers, for a type U such that is_same_v<U, remove_cvref_t<U>> is true

isn't possibly implementable with a class template, and that it should rather read "unary alias template". I'll file an issue to make this change after the merge.

[tkoeppe]

@CaseyCarter: is that editorial? If so, we could just tack that onto the motion application. Otherwise we'll wait for the LWG issue.

[CaseyCarter]

is that editorial?

By the strictest possible interpretation it is not editorial. It is certainly a borderline case: I would have made the change in the proposal had it been brought to my attention before the 20:00 deadline for the strawpolls page. I don't know where we draw the line for changes we consider to be "editorial-ish-enough" when incorporating motions, so I plan to precisely walk the line absent any direction otherwise from more experienced editors.

[tkoeppe]

@mclow: Maybe the LWG chair could weigh in on this border line?

[mclow]

I think we should err on the side of caution here - and open an issue.

[CaseyCarter]

@timsong-cpp again:

Hmm, where in CopyConstructible do we say that the construction must not change v?

This axiom used to be implicit via the "const operands are not modified by default" wording when CopyConstructible was defined in terms of required expressions; it was lost when we reformulated in terms of is_constructible. I need to open an issue to fix this as well.

[CaseyCarter]

I think we should err on the side of caution here - and open an issue.

This is LWG 3140.

Hmm, where in CopyConstructible do we say that the construction must not change v?

This is LWG 3141