[pointer.traits.types][allocator.traits.types] Replace undefined "Alias template" element with "Result"

[frederick-vs-ja]

The Alias template "element" is used twice in the library wording but not defined in [structure.specifications]. I think the Result element should used instead.

I'm not sure whether this is editorial. If not, this should resolved together with LWG3166.

[tkoeppe]

OK, I agree that "Alias template" is undefined, but why "Result" and not, say, "Type"?

[frederick-vs-ja]

OK, I agree that "Alias template" is undefined, but why "Result" and not, say, "Type"?

IIUC LWG decided to say Result but not Type in P2416R2.

[eisenwave]

Marking this P1 because the meaning of an Alias template: element is not defined, resulting in a meaningless specification.

[tkoeppe]

OK, I agree that "Alias template" is undefined, but why "Result" and not, say, "Type"?

IIUC LWG decided to say Result but not Type in P2416R2.

That was in the context of the requirements-tables-turned-paragraphs. But I think we're not in a "requirements" context here. The itemdecls just above use "Type:", too, don't they?

[eisenwave]

It seems like Type: and Return type: are two more exotic elements that don't exist in [structure.specifications].

This has me really confused ... why do we have so many different elements that all specify a type and most of them are just vibes? Or perhaps "Type:" is just considered self-evident and wouldn't require a specification, or I just don't know where it is?

[tkoeppe]

The "elements" "Type:" and "Template alias:" have existed since before GitHub, and I don't have access to any rationale.

That said, I'm also not sure that there's any tension with [structure.specifications], esp. paragraph 3, which only concerns itself with function semantics. Here we're not describing functions, but member types and aliases.

This entire subclause is a bit weird in that the class synopsis just says "see below" for the members, and then the members are only described in this expanded prose. This could probably be rewritten to spell out the members individually (with "see below") in the synopsis, and then explain their definition in regular paragraphs of text.

But I'm not sure that this is a pressing issue or that anything is unclear here.

[tkoeppe]

Hm, we do seem to intend for "Result:" to be used for types: https://eel.is/c++draft/structure.specifications#3.9

Perhaps the description of what those elements are for should itself be revised.

For now, I've noticed a few other uses of \ctype in [utilities] that could clearly be improved to be "Result:". Moreover, there are cases where an \itemdecl describes a type or type alias, and the description is either rolled into an unrelated element or just appears in a naked paragraph inside its \itemdescr. Those could certainly be fixed to use Result:. I'll make a PR for those.

[Dani-Hub]

Hm, we do seem to intend for "Result:" to be used for types: https://eel.is/c++draft/structure.specifications#3.9

That has been my understanding as well, see note and current P/R of LWG 2819

[tkoeppe]

It's still a mess, since most of p3 talks about functions, and only the "Result:" element is weirdly about a other things, too.

I think the motivation came from dismantling the requirement tables, where we don't itemdescribe functions, but have something quite different, and there it is reasonable to use "Results:" for requirements that describe types. It's just that describing the "Results:" element as part of p3 is now a bit weird.

That said, I suppose we can remove \ctype and \returntype (and \templalias) and use \result for all of them. Maybe we can clean up p3 first to make that completely clear.

[frederick-vs-ja]

That was in the context of the requirements-tables-turned-paragraphs. But I think we're not in a "requirements" context here. The itemdecls just above use "Type:", too, don't they?

Yeah. This seems already tracked in LWG3166.

It's still a mess, since most of p3 talks about functions, and only the "Result:" element is weirdly about a other things, too.

This is tracked in LWG3193.