Could you point to the location in the incoming paper where authorization is given to make this change? The paper says "prepend the prefix 'Cpp98' to uses of the named requirement sets below", but "input iterator" is not a CamelCase fixed-width requirement, it's a prose plain-text requirement, and does not appear in the list in subclause 1.3 of the paper.

Subclause 1.3 is woefully incomplete: I missed the Iterator requirements tables and some more obscure sets of named requirements. The design intent - as discussed in LEWG and I believe LWG as well - was to rename all of the old named requirements tables to make way for current and future concepts.

It's also important that all references to the requirements use the proper name. The colloquialism "input iterators", for example, can now be interpreted to mean either types that meet the Cpp98InputIterator requirements or types that model the InputIterator concept. We need to very clearly define for users exactly to which set of requirements each such usage is intended to refer.

I understand the desires, but the paper as moved doesn't say so, and there isn't even a trace of a hint in the paper that this might be the intent, given that only CamelCased requirements are quoted in 1.3. (I'd be happy to be shown otherwise.)

@zygoloid, are we overstepping our editorial leeway here by changing such phrases, in particular since the result could be incorrectly interpreted as referring to the table only, not the entire set of requirements? (I think we had an editorial issue a few months ago where exactly that point was a concern.)

I think that was me, and the issue was an edit that changed a cross-reference to the NullablePointer requirements section to point to the table instead.

The issue here is that a reference to "forward iterator" (plain text) refers to the entire section [forward.iterators], including (for example) the multi-pass guarantee. In contrast, Cpp98ForwardIterator appears to refer to the table only (which just gives a bit of syntax). That feels like a regression to me.

"forward iterators" will be ambiguous once Ranges are merged. I understand your point about the distinction between the table and the additional requirements outside the table, though. Do you agree it would be clearer if I retitle the existing sections e.g. "Cpp98ForwardIterator requirements"?

Yes, I think so. I fear there are Cpp98 concepts definitions that don't have a section of their own, though, so this strategy might fail here and there. Before you subscribe for more work, @zygoloid should really chime in how he wants to proceed here.
In any case, make sure all those changes are a (one) separate commit so that they can be messed with easily.

Going forward, we really need to find standardized wording to say "satisfies the syntax constraints" vs. "syntax + semantics", and apply such phrasing uniformly.

I'm working on that. My current plan is to uniformly use "T meets the CppXXX requirements" for "old" concepts (which is the prevalent library usage, this occurrence is aberrant), "T satisfies Concept" to mean purely syntactic conformance (which is the proper core language meaning of :"satisfy"), and "T models Concept" to mean that T must both satisfy Concept and must further meet the semantic requirements or the program is ill-formed NDR.

I'm working on rewording the combined Ranges paper to use that style, and plan to submit future editorial changes to the rest of the library specification to make everything uniform.

See also some earlier discussion in #1263. I understand some decisions are obsolete now.

I'm wondering whether we can find a slightly less awkward spelling than "Cpp98Blah" for these old-style concepts. Maybe even something innovative such as OutputIterator₉₈ would work.

I'm certainly not married to "Cpp98Blah". It's better than LEWG's suggestion "STL1Blah", but that wasn't a high bar to meet. Now that the styling is macro-ized, we can change it with a one-liner.

Cpp98MoveConstructible certainly feels anachronistic.

Cpp98MoveConstructible certainly feels anachronistic.

We specifically pointed out that example in both LEWG discussion of the Ranges proposal and LWG discussion of this proposal, and both subgroups found the confusion level acceptable.

ISO wants us to phrase definitions of such terms in a way so that you can macro-expand the definition into the point-of-use and the sentence stays intact (modulo semantic parentheses implied by the macro). I think this wouldn't work here.

I'll fix this.

"additional" is great, but which ones in particular? Maybe the semantic requirements explained in the subclause that defines the concept?

How about "When the associated constraints refer to a concept\iref{temp.concept}, the semantic constraints specified for that concept are additionally imposed on the use of the declaration."?

Yes, seems to be an improvement. (Make sure to keep those rephrasings separate from the original commit with the as-moved paper.)

The [forward.iterators] section is not so named, and the table of that name doesn't show semantics.

Repeating my reply to your original comment (that Github will likely bury after the \oldconcept push):

"forward iterators" will be ambiguous once Ranges are merged. I understand your point about the distinction between the table and the additional requirements outside the table, though. Do you agree it would be clearer if I retitle the existing sections e.g. "Cpp98ForwardIterator requirements"?

I'm ok with that, although that doesn't really remove the ambiguity if the table continues to be labeled the same as the section. @zygoloid?

Yes, I'd thought about the ambiguity of both subclauses and tables titled "Foo requirements," although that's pre-existing, for example, [allocator.requirements] is titled "Allocator requirements" and contains Table 31 "Allocator requirements". We should retitle those tables to something generic like "Allocator valid expressions with semantics" - [structure.requirements]/4 says they are "a
table that specifies an initial set of the valid expressions and their semantics." Which is also a misnomer.

I'm waiting for Richard's nod to enact these changes. I have more work to do on the merged Ranges proposal than time before the mailing deadline to do it in, so I don't want to walk down any blind alleys.

Where in the incoming paper is authorization given for this change? InputIterator is not in the list of CamelCase concepts in section 1.3 of the paper.

Repeating my reply to your original comment (that Github will likely bury after the \oldconcept push):

Subclause 1.3 is woefully incomplete: I missed the Iterator requirements tables and some more obscure sets of named requirements. The design intent - as discussed in LEWG and I believe LWG as well - was to rename all of the old named requirements tables to make way for current and future concepts.

It's also important that all references to the requirements use the proper name. The colloquialism "input iterators", for example, can now be interpreted to mean either types that meet the Cpp98InputIterator requirements or types that model the InputIterator concept. We need to very clearly define for users exactly to which set of requirements each such usage is intended to refer.

@zygoloid, what's your guidance here?

"more constrained" is a special case of "more specialized".

[temp.constr.order]/3 defines "more constrained" as an orthogonal notion to "more specialized." The two notions interact in overload resolution where "more constrained" is used to discriminate between overloads neither of which is more specialized, but "more constrained" is not otherwise a special case.

Agreed, sorry for the noise.

(Not editorial) I find it odd that an incomplete type would cause undefined behavior; it's a compile-time failure and should be ill-formed (possibly no diagnostic required).

LWG has been addressing a similar problem with the type traits to require implementations to diagnose precondition violations. There's currently no technology to do so with concepts, but this at least leaves the avenue open for future changes.

I'm complaining about the fact that this situation is in the "undefined behavior" category, not in a (separate) category "ill-formed, no diagnostic required". The latter would leave avenues open, too, but would also permit implementations to diagnose and refuse e.g. incomplete types today. And, maybe there is even a conflict here if some preconditions says "shall be a complete type" (i.e. compile-time diagnostic), yet this section says "undefined behavior" (i.e. only bad if you actually evaluate it, which seems a misguided idea for a compile-time violation).

I agree. I've made a note to file an LWG issue to adjust this wording to IFNDR.

Thank you.

This is LWG 3142.

LWG 2139 (to be applied in #2193) now uses "program-defined type" here.

I'll update uses of "user-defined type" accordingly.

(not editorial) This seems an overspecification; certainly a user could define the member "type" as a nested class (which is not a typedef-name). The difference is, I believe, unobservable.

Technically, it's observable in some cases with an elaborated-type-specifier.

I'd be happy to change this to "If there is a member \tcode{type}, it shall denote a type." if we're willing to call that change editorial-ish.

@timsong-cpp is right, such a change would be observable so can't be done editorially. @CaseyCarter, could you please check whether there is already an LWG issue for that, and file one if not?

Yes I will. I have a set of notes on all the comments here so I can track which changes I've accomplished. There are six entries now for issues to file post-merge.

We usually do \placeholder here (cf. INVOKE), because CREF(A) is not valid C++ source code; it's a funny abstract-level meta-type-function.

Why are we creating two invented function types here, just to call them and look at their result values? What's the net difference vs. omitting the indirection via the function references? What's the net difference vs. common_type_t<X,Y>?

This is a truly disgusting hack to avoid declval's add_rvalue_reference_t on the return type. decltype(declval<X>()) is add_rvalue_reference_t<X>, decltype(declval<X(&)()>()() is exactly X. We discussed at length in LWG that this is abominable, and that no one had an idea for an improvement.

... and common_type_t<X,Y> doesn't work because?

Because X and Y may be cv-qualified or reference types, and common_type decays its arguments: that's the entire motivation for adding common_reference.

For cppreference, I just invented a declval substitute that returns T instead and used that, FWIW.

(decltype(declval<X(&)()>()()) is also not exactly X; it's subject to the usual prvalue cv-qualification adjustment rules and the rvalue-reference-to-function-is-lvalue rule.)

I'd hate to define yet another exposition-only helper here that's only going to be used in this one place; COMMON_REF is overrun with them. Do we agree that template <class T> T __val() noexcept; // \expos ... decltype(false ? __val<X>() : __val<Y>()) is an improvement?

I'd hate to define yet another exposition-only helper here

I thought this discussion was familiar: ericniebler/stl2#338 (comment).

Maybe we shouldn't change anything here and go with the formulation in the paper. These nuances are important, but the code snippets for the meta-functions are way too obtuse to communicate that effectively. Can we maybe add a few notes or examples explaining what the intent is (in particular involving subtleties of prvalues vs. xvalues)? (As a matter of principle, I'm wondering whether some prose relying on the core language mechanics of the ?: operator or "common type" would be shorter and easier to understand. Not now.)

Good, you already changed "its type" to "that type" here.

Both \iref's should be \ref's (with a space in front); the \iref automatically adds parens that we don't want here (compare to the parallel phrasing for common_type two paragraphs above).

I somewhat blindingly replaced refs with irefs - I'll audit them all.

What does that mean? Are you talking about partial specialization here? Then you should say so at the start of this paragraph. (A specialization is a non-template; a partial specialization is a template: two fundamentally different things.)

Yes, the intent here is that users partially specialize basic_common_reference. I admit that I can't see a reason now for "A program shall not specialize \tcode{basic_common_reference} on the third or fourth parameters, \tcode{TQual} or \tcode{UQual}." I believe the intent is to make it harder for users to do something stupid and violate the other requirements and/or point them more directly down the intended path.

@ericniebler, can you clarify the intent of this particular requirement?

Yes, the intent here is to disallow specifying the third or fourth template parameters in either a partial or explicit specialization. Those parameters are specified by the common_reference trait. The exact unary templates used as template arguments to the (possibly user-specialized) basic_common_reference instantiation are unspecified, and implementors are free to change them between releases. Any code that specializes on those parameters (either partial or explicit) is de facto wrong.

Does a program with such a specialization need to be IFNDR? IMO it's sufficient that common_reference specifies how and when it works, and users shouldn't be surprised when their broken specializations are never selected.

I suppose not. Striketh the sentence if it offendeth thee.

An alternative which I hadn't considered until just now is to redesign the trait to make it impossible to misuse:

template <class A, class B>
struct basic_common_reference {
  template <template <class> class AQual, template <class> class BQual>
  using type = ...;
};

EDIT: That is obviously not editorial. :-)

I don't know that I buy "impossible to misuse", but I'll make a note to possibly file an issue to make this design change after we investigate it more thoroughly.

...and strike the requirement for now, since we think it adds no useful normative effect.

My original concern here was the use of the word "specialization" for a case where only partial specializations should ever appear in user programs (because the arguments for AQual and BQual are controlled from the outside, so specializing on them doesn't make sense). I'd appreciate an LWG issue for at least that part.

I did change the first sentence of what is now "Note D" to read:

Notwithstanding the provisions of \ref{meta.type.synop}, and pursuant to \ref{namespace.std}, a program may partially specialize \tcode{basic_common_reference<T, U, TQual, UQual>} for types \tcode{T} and \tcode{U} such that \tcode{is_same_v<T, decay_t{>}} and \tcode{is_same_v<U, decay_t{>}} are each \tcode{true}.

which I consider to be an editorial clarification. If you feel that change is insufficient or not editorial, I'll revert it and file an issue.

Not done: "[Editor’s note: Relocate "Header /tcode synopsis" [rand.synopsis] before 29.6.1 "Requirements"
[rand.req]]"

I must have ignored this directive upon finding no header named /tcode<random> in the library ;)

Please add line breaks after at most 79 chars, preferably "semantic line breaks", i.e. do not break in the middle of a phrase or term.

The presentation seems suboptimal and redundant here. It seems more compact to introduce \concept{UniformRandomBitGenerator} first (which is the more relaxed concept) and then define "uniform random bit generator" in terms of that, adding the result_type requirement.

You mean something like urbg.pdf? That seems to go a bit past "editorial", but I'm game if you folks are.

It also relaxes the rules by only requiring the result type to model UnsignedIntegral instead of being an unsigned integer type. The former permits bool and character types that are unsigned.

@CaseyCarter: Yes, that looks like an improvement. Do consider @timsong-cpp's comment, though, "char" (if it happens to be unsigned on a particular platform) seems to be an UnsignedIntegral type (but is not an unsigned integral type per the core language). Similar for "bool". Keep this rewording in a separate commit so that it can be reviewed extra-carefully. (In my view, doing this rewording editorially is fine as long as the normative outcome is exactly the same as before. The larger the rewording, the more danger to introduce inadvertent differences, though, so @zygoloid may want to eventually drop the patch when merging.)

I'll reword to:

A class \tcode{G} meets the \term{uniform random bit generator} requirements if
\tcode{G} models \libconcept{UniformRandomBitGenerator},
\tcode{invoke_result_t<G\&>} is an unsigned integer type\iref{basic.fundamental},
and
\tcode{G} provides a nested \grammarterm{typedef-name} \tcode{result_type}
that denotes the same type as \tcode{invoke_result_t<G\&>}.

to fix the normative difference between "unsigned integer type" and UnsignedIntegral and add this in a separate commit.

This needs to become a defined term with an index entry. Use \defnx{equality preserving}{expression!equality preserving} .

I have a hard time associating "declared" with expressions. We declare names and functions and variables and whatnot, but not expressions. Also, a requires-expression may also appear in non-declaration contexts (e.g. as an expression-statement).
Also, in which situation could a requires-expression not be equality preserving? It seems to be a totally compile-time concepts-checking expression that never modifies any object at all.

So, this is intended to refer to the expression inside a simple-requirement and inside a compound-requirement.
Maybe the phrasing is missing a crucial "were they evaluated" or similar, because requires-expressions are unevaluated operands and thus never actually evaluated (and thus, talking about equality preserving doesn't really make sense). (This ventures beyond editorial.)

Follow-on question: We're only talking about "expression" here, but what about the implicit conversion to the specified type in a compound-requirement? That is syntactically not part of the expression, yet could affect "equality preserving".

We always want explicit convertibility as well when we require implicit convertibility, which means that we'd use ConvertibleTo instead. (But perhaps ConvertibleTo is missing a requirement that the conversion is equality-preserving?)

Hm... ConvertibleTo has a simple-requirement, which contains a static_cast<> expression, which we're instructed needs to be equality preserving. Ah, but... see below.

I wonder if in the library preamble we can handwave that when the library uses an implicit conversion constrain we also require explicit conversion (with the same semantics) and equality preservation. And then stump for more help from the core language regarding conversion constraints.

I'd prefer to be explicit about conversions. I don't think writing { E } -> ConvertibleTo<T>; is a significant burden over { E } -> T; - not enough so to have the same syntax implicitly result in different checked constraints, anyway. I'll file an issue to deal with the interaction of equality-preservation and implicit conversion constraints. It doesn't really matter to Ranges, but I suspect someone will eventually want to specify a library component with such a constraint and it needs to have a well-defined meaning rather than us simply telling them to not do that bad thing.

Clarification: today we have to write E; requires ConvertibleTo<decltype((E)), T>; to express that constraint properly in terms of the exact type and value category of E. Once P1084 is adopted, it can be simplified to { E } -> ConvertibleTo<T>;.