As decided in #2656, return types from the sub-namespace were qualified as well.

That sounds as if you qualified all those actually in ranges::. But you only did it for the *_result templates. Granted, the editorial meeting decision in the linked issue says

• If there is a possibility of confusion, qualify declarator-id and return type etc.

Are the *_result more confusing than borrowed_*_t, which weren't qualified?

Although consistent with the second decision

• Otherwise, no change.

I noticed that range_*_t remain unqualified too.

There's also the case for

ranges::uninitialized_copy_result<borrowed_iterator_t<IR>, borrowed_iterator_t<OR>>

If you decide you qualify borrowed_*_t in the return type too, would you do it here too? Even though they're template arguments to the return type? If so, then you'd wonder what'd make range_*_t so special to remain unqualified.

I think what I did is consistent with the changes done elsewhere in [algorithms] by the other pull request(s) linked in #2512.

The \itemdecls are not exactly intended to be valid freestanding declarations (for example, we regularly show member functions referring to other class members). Instead, we want to uniquely identify the declaration (from the header synopsis) we're talking about.

Thus, I think the most important aspect is qualifying the declarator-id. I have qualified the *_result return types because we apparently did that for the other ranges algorithms as well, and it is at least conceivable that non-ranges algorithms would also yield similar *_return values (but not in namespace ranges, of course). The confusion potential seems much less for the "borrowed" and "ranges" parts, which only make sense in a ranges ecosystem.

I think the presentation would deteriorate if we attempted to qualify everything. Maybe a valid fallback position is to say that names in the return type are interpreted as-if they were in a trailing return type, and thus don't really need qualification at all. (Such an as-if approach breaks down for names (e.g. concept-ids) in template-parameter-lists and requires-clauses, though, so maybe a better conceptual approach would be to say that the qualification of the declarator-id is instead considered to be turned into a namespace X { ... } wrapper for the entire declaration.

@tkoeppe , do you think we need more discussion in a wider forum here, or does #2512 establish sufficient precedent?

This seems like an improvement. @jwakely, @CaseyCarter: any final thoughts?

I like it, but it does seem strange that borrowed_iterator_t is not qualified.

Well, but that seems to be how we do things, all the other uses of borrowed_iterator_t are also unqualified even if they appear as part of a declaration that uses ranges:: elsewhere.

Yes, and that seems strange 🙂

Yeah. I'd be happy to entertain suggestions!

Yes, and that seems strange

You can't have std::range without strange!

So... I sense general approval, or at least lack of sustained opposition? @CaseyCarter, final chance to veto?

@CaseyCarter Going once, twice, ...

@CaseyCarter Going once, twice, ...

I've been avoiding comment on this change because it seems like utter chaos to qualify some of the names but not all of the names from a particular namespace. I was perfectly happy with wrapping these declarations in namespace ranges { ... }.

That said, I haven't participated in the editorial discussions that led to this new style so I feel I should keep my uninformed opinions to myself.

@CaseyCarter, the status quo is all of the other algorithms use the style this change wants to achieve, i.e. showing a qualified declarator-id. This approach solved #2512, where it was observed that (without any qualification at all) our \itemdecls are really ambiguous.

In general, the standard does not use namespace wrappings in \itemdecls at all, so I think nobody considered using this style throughout [algorithms]. And the specialized algorithms are the odd one out currently.

I suggest to apply this patch regardless as a consistency improvement, and discussing a whoiesale change to a namespace wrapping approach as a separate issue.

@CaseyCarter, the status quo is all of the other algorithms use the style this change wants to achieve, i.e. showing a qualified declarator-id. This approach solved #2512, where it was observed that (without any qualification at all) our \itemdecls are really ambiguous.

I'm aware it's the status quo, and I'm aware of #2512, I'm simply uncertain that the fix is an improvement.

In general, the standard does not use namespace wrappings in \itemdecls at all, so I think nobody considered using this style throughout [algorithms]. And the specialized algorithms are the odd one out currently.

I suggest to apply this patch regardless as a consistency improvement, and discussing a whoiesale change to a namespace wrapping approach as a separate issue.

I'm not opposed to this change , I just don't like it =)

I'm not opposed to this change , I just don't like it =)

Understood. There's no need to rush this. Do you have any other ideas how one could disambiguate the itemdecls? Or if not, which do you prefer between the status quo and this proposed style? Or do you dislike both equally much?