Skip to content

CWG2836 Conversion rank of long double and extended floating-point types #1699

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
jensmaurer opened this issue Dec 3, 2023 · 4 comments · Fixed by cplusplus/draft#7099
Closed
Labels
CWG Core plenary-approved Papers approved for inclusion in their target vehicle by plenary vote.

Comments

@jensmaurer
Copy link
Member

A case was found where the outcome of the C++ implicit conversions is not aligned with the outcome of C, despite P1467's documented goal.

One of the authors of P1467 asserts the deviation from C is intentional.

CWG asks EWG to confirm, thus closing CWG2836 as NAD.

@jensmaurer jensmaurer added the EWG Evolution label Dec 3, 2023
@jfbastien
Copy link
Collaborator

From Jim Thomas:

This particular issue was discussed at the 2021-12-22 CFP meeting. The following is extracted from the meeting minutes (N2910):

  1. [2302] C++ liaison issue from David Olsen
    Relates to arith conversions occurring between long double and _Float64.
    David Olsen says an expression converting to long double is more consistent.
    But, the current draft says that such an expression converts to _Float64.
    It was noted that a standard type may have lesser quality arithmetic than
    an interchange type which is at odds with the fact that we really want to
    lean towards better quality arithmetic
    Jim proposed some text if we decide to change.
    It was also noted that such a change also
  • affects tgmath rules for which examples need to be checked, and
  • adds another special case to an already complicated set of rules.
    Motivated by Microsoft Visual C++ where long double is the same as double.

Conclusion: Recommend no change - change does not justify added complexity.

@NinaRanns
Copy link
Collaborator

NinaRanns commented Feb 4, 2024

WG14 already made a decision, no need for SG22 to see this issue.
From the email thread : "Given the rationale linked above, the previous SG22 discussion and related polls recorded in WG14 N2835, and the subsequent reconfirmation by the WG14 CFP SG recorded in WG14 N2910, I no longer see a reason for SG22 to discuss this CWG issue. I agree with the direction currently indicated in the CWG issue to add an annex C entry."

@erichkeane
Copy link
Collaborator

EWG discussed this during the Monday AM session in Tokyo. No poll was taken, but we expect to see this again later in the week after offline discussions.

@hanickadot
Copy link
Collaborator

Close CWG2836 as not a defect.

SF F N A SA
3 10 3 0 1

Consensus

@jensmaurer jensmaurer added CWG Core and removed EWG Evolution labels Mar 18, 2024
@jensmaurer jensmaurer added this to CWG Jul 15, 2024
@jensmaurer jensmaurer moved this to Approved for plenary vote in CWG Jul 15, 2024
@jensmaurer jensmaurer added the plenary-approved Papers approved for inclusion in their target vehicle by plenary vote. label Jul 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CWG Core plenary-approved Papers approved for inclusion in their target vehicle by plenary vote.
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

5 participants