cplusplus / CWG

Core Working Group
23 stars 7 forks source link

[intro.defs] The term related types is not defined by the standard but used at multiple places #461

Closed ranaanoop closed 10 months ago

ranaanoop commented 11 months ago

Full name of submitter: Anoop Rana

Reference (section label): [intro.defs]

Link to reflector thread (if any):

Issue description:

The standard uses the term "related types" at multiple places in the document but the term has not been defined. Is it supposed to be the same as "reference related type" should be clarified.

Suggested resolution:

A definition for the same should be added or clarified if it is the same as reference related type in which case the full name "reference related type" should be used at all places.

jensmaurer commented 11 months ago

Could you add references to the occurrences of "related types" here? Thanks.

ranaanoop commented 11 months ago

Could you add references to the occurrences of "related types" here? Thanks.

@jensmaurer Sure, here are all 6 references/uses of the term that I could find.

1) temp.class.general 2) support.general 3) char.traits.general 4) re.req 5 & 6) dcl.init.ref The example given in dcl.init.ref#5.4.4 has 2 uses of the term related type

frederick-vs-ja commented 11 months ago

I can't see a defect. I don't think it's a term. It definitely means different things in different contexts, and the wording may become more awkward if we define it.

dcl.init.ref The example given in dcl.init.ref#5.4.4 has 2 uses of the term related type

The example should be fixed editorially, IMO.

AlanVoore commented 11 months ago

@frederick-vs-ja In the example given at [dcl.init.ref#5.4.4], int i3 = 2; double&& rrd3 = i3; isn't the initializer here also an lvalue of reference related type.

That is, the following is an error double d2 = 1.0; double&& rrd2 = d2; because here the initializer is an lvalue of related type but the same things also holds for int i3 = 2; double&& rrd3 = i3;. Kinda defect?

frederick-vs-ja commented 11 months ago

@frederick-vs-ja In the example given at [dcl.init.ref#5.4.4], int i3 = 2; double&& rrd3 = i3; isn't the initializer here also an lvalue of reference related type.

That is, the following is an error double d2 = 1.0; double&& rrd2 = d2; because here the initializer is an lvalue of related type but the same things also holds for int i3 = 2; double&& rrd3 = i3;. Kinda defect?

I have no idea why you said "the same things also holds". Anyway, I think comments in the example should be clarified or fixed editorially.

AlanVoore commented 11 months ago

@frederick-vs-ja I mean that in int i3 = 2; double&& rrd3 = i3; also we have i3(initializer) which is an lvalue of type int which is a "related type" to double. Just like in double d2 = 1.0; double&& rrd2 = d2; we had d2(initializer) which is an lvalue of type double which is a "related type" to double.

frederick-vs-ja commented 11 months ago

which is an lvalue of type int which is a "related type" to double

I failed to understand the reason why you thought they are related. But perhaps this doesn't matter. I think it's normatively meaningless to say whether two given types are "related". So while the divergence on this can be confusing, it shouldn't be considered as a defect.

t3nsor commented 11 months ago

Could you add references to the occurrences of "related types" here? Thanks.

@jensmaurer Sure, here are all 6 references/uses of the term that I could find.

1. [temp.class.general](https://eel.is/c++draft/temp.class.general#1.sentence-1)

The word "related" should be struck from this sentence.

2. [support.general](https://eel.is/c++draft/support.general#1.sentence-2)

3. [char.traits.general](https://eel.is/c++draft/char.traits.general#2.sentence-1)

4. [re.req](https://eel.is/c++draft/re.req#2.sentence-1)

These seem to be issues with library wording, not core wording.

   5 & 6) [dcl.init.ref](https://eel.is/c++draft/dcl.init.ref#5.4.4) The example given in [dcl.init.ref#5.4.4](https://eel.is/c++draft/dcl.init.ref#5.4.4) has 2 uses of the term related type

I agree with @frederick-vs-ja that this example should be fixed by the linked editorial issue.

t3nsor commented 11 months ago

And honestly, I think the first item is editorial as well.