This isn't talking about "the tag of a struct" though. It's a tag type as in "tag dispatching" https://www.fluentcpp.com/2018/04/27/tag-dispatching/

https://www.boost.org/community/generic_programming.html#tag_dispatching

Upon further reflection, I still believe this is a good change to make. I am also concerned by the sentence

In such cases, the type dangling is returned instead of an iterator or subrange.

which seems to conflate returning a type with returning an object of a certain type.

It seems to me that this would be better phrased as

In such cases, an object of type dangling is returned instead of an object whose type is an iterator or subrange.

There's no object involved in return dangling{};. See https://eel.is/c++draft/stmt.return#2.sentence-4 and https://wg21.link/LWG3805.

There's no object involved in return dangling{};. See https://eel.is/c++draft/stmt.return#2.sentence-4 and https://wg21.link/LWG3805.

It will be interesting to see the resolution to the issue that you have open!

I'm not sure. There's also the example of https://eel.is/c++draft/std.iterator.tags#1.sentence-2.

It already does. It says "tag type".

I am just trying to be helpful.

We all are. Obviously, the "something more" you meant wasn't the preexisting "tag". I shouldn't have taken it literally.

Now I'm questioning the use of "tag" standing for "tag dispatching". Unlike the iterator's tag dispatching, this one is on the way out. And the tag is actually "whether the range argument is an rvalue", whereas dangling is the result of the dispatch.

The

something more than just "type"

you suggest exists in the whole paragraph, which attempts to explain what "tag" alone couldn't. So I think just dropping "tag" is an improvement in face of the potential confusion with the C term and "tag" as an adjective being an undefined term for types.

I am just trying to be helpful.

We all are. Obviously, the "something more" you meant wasn't the preexisting "tag". I shouldn't have taken it literally.

No problem! I get nervous in these situations because everyone else is the expert!

Now I'm questioning the use of "tag" standing for "tag dispatching". Unlike the iterator's tag dispatching, this one is on the way out. And the tag is actually "whether the range argument is an rvalue", whereas dangling is the result of the dispatch.

The

something more than just "type"

you suggest exists in the whole paragraph, which attempts to explain what "tag" alone couldn't. So I think just dropping "tag" is an improvement in face of the potential confusion with the C term and "tag" as an adjective being an undefined term for types.

If I hear you correctly, then you think that the original PR (where we simply drop the tag word) is good?

Thanks again for engaging!

If I hear you correctly, then you think that the original PR (where we simply drop the tag word) is good?

I personally do. We'll have to see what the experts think.

If I hear you correctly, then you think that the original PR (where we simply drop the tag word) is good?

I personally do. We'll have to see what the experts think.

Fair enough, but I think you're an expert! :-)

"tag" really isn't contributing anything here.

Thank you @CaseyCarter !

And it's not an iterator category tag, either (for tag dispatching).

Iterator tags aren't the only kind of tags used for tag dispatching though. I'd prefer to keep it, but then we'd have to define tag dispatching (or tag types) in the standard. So I will let it go, somewhat reluctantly.

And it's not an iterator category tag, either (for tag dispatching).

Iterator tags aren't the only kind of tags used for tag dispatching though. I'd prefer to keep it, but then we'd have to define tag dispatching (or tag types) in the standard. So I will let it go, somewhat reluctantly.

I'd be willing to work with you on defining that phrase and introducing it, if you'd like!! @jwakely

(While I understand the type dangling may be used for tag dispatching, I thought its primary purpose for users is to make careless programs ill-formed.)

@tkoeppe , on to you.

its primary purpose for users is to make careless programs ill-formed.

Calling another algorithm with the result either dispatches to a function taking an iterator, or fails to compile (i.e. dispatches to nothing). Using the return type to select a valid overload or an invalid overload is a form of tag dispatching IMO.