P0870 A proposal for a type trait to detect narrowing conversions

wg21bot commented 4 years ago

P0870R1 A proposal for a type trait to detect narrowing conversions (Giuseppe D'Angelo)

erichkeane commented 4 years ago

Forward D0870R2 to EWG, as we believe that EWGI cannot provide any further useful feedback to the author.	SF	F	N	A	SA
5	4	0	0	0

jfbastien commented 4 years ago

EWG Prague Friday afternoon:

D0870R2 A proposal for a type trait to detect narrowing conversions

Send to SG6 Numerics for input.	SF	F	N	A	SA
4	4	6	3	0

We have no concerns with this, only send this paper back to us if SG6 or LEWG / LWG / CWG ask.	SF	F	N	A	SA
3	13	2	0	0

brycelelbach commented 4 years ago

Prague 2020-02 LEWGI Minutes

P0870R1 std::is_narrowing_conversion: Direction Review

Chair: Billy Baker

Champion: Marc Mutz

Minute Taker: David Olsen

Start Review: 2020-02-11 08:39

You mentioned that there are proposed changes to what are narrowing conversions in flight? Do we expect the definition to change again in the future?

Does EWG(I) need to see this?

Start Polling: 9:14

POLL: We should promise more committee time to pursuing P0870, knowing that our time is scarce and this will leave less time for other work.

Strongly For	Weakly For	Neutral	Weakly Against	Strongly Against
2	10	2	1	0

Attendance: 20

# of Authors: 1

Author Position: SF

End: 9:16

CONSENSUS: Bring a revision of P0870R1 (std::is_narrowing_conversion) to EWGI for review, and then revise, with the guidance below, and return to LEWGI for further design review.

Paper authors are encouraged to provide a better example of an implementation.
Paper authors are encouraged to provide a revision history.
Paper authors are encouraged to provide additional references in P0870 to papers related to narrowing conversions that were mentioned during the discussion such as P1818.

wg21bot commented 4 years ago

P0870R2 A proposal for a type trait to detect narrowing conversions (Giuseppe D'Angelo)

wg21bot commented 4 years ago

P0870R3 A proposal for a type trait to detect narrowing conversions (Giuseppe D'Angelo)

inbal2l commented 4 years ago

Under LEWG ML review (started: 24 Aug 2020)

cor3ntin commented 4 years ago

Mailing list review: 24 August - 7 September 2020
10 participants:

General positive feedback: We think this feature is useful and should be added to the standard. No comments on the proposed mechanism, but some concerns about the name which is not consistent with the language ( which has no narrowing convertible" notion, and the fact that the current name would be almost always negated. Slight preference for is_convertible_without_narrowing among the names offered by the author

1) is_narrowing_convertible 2) is_convertible_with_narrowing 3) is_narrowing 4) is_non_narrowing_convertible 5) is_nonarrowing_convertible 6) is_convertible_without_narrowing 7) is_convertible_no_narrowing 8) is_non_narrowing

The author is encouraged to add tony tables and more example and propose more names for further bikeshedding on the mailing list. I think it should then go to a LEWG telecon next.

brycelelbach commented 4 years ago

Marked for LEWG telecon review next.

dangelog commented 4 years ago

There's a typo in the October 2020 mailing, P0870R4 is indeed targeting LEWG and SG6, not just SG6. (The paper itself has the correct targets.)

brycelelbach commented 4 years ago

The label in the mailing and on the paper is of no concern; only the label here is normative, and is correct.

wg21bot commented 4 years ago

P0870R4 A proposal for a type trait to detect narrowing conversions (Giuseppe D'Angelo)

ben-craig commented 3 years ago

P0870R4: A proposal for a type trait to detect narrowing conversions, remaining

2021-03-16 Library Evolution Telecon Minutes

Chair: Ben Craig

Champion: Giuseppe D'Angelo

Minute Taker: Inbal Levi

SUMMARY: Unsure if this does specifically what users want in the face of user defined conversions. What it actually does is precisely specified though.

We did not have time to drive this discussion to conclusion.

OUTCOME:

__POLL: is_convertible_without_narrowing is an acceptable name for this facility.__

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
14	7	0	0	0

Attendance: 26

# of Authors: 1

Author Position: SF

Outcome: Unanimous Consent

ACTION: none... leaving in the ready-for-library-evolution-meeting-review state. Hopefully we can get a joint Numerics + LEWG meeting to conclude this.

brycelelbach commented 3 years ago

SG6 will look at this first, and they can send it to Library Evolution when they feel it is ready.

dangelog commented 3 years ago

Is SG6 going to reconvene anytime soon?

jensmaurer commented 3 years ago

@dangelog , please contact the chair of SG6 directly via e-mail; it is not at all obvious whether messages in this issue tracker reach anyone in particular.

dangelog commented 3 years ago

Will do; thanks!

mattkretz commented 2 years ago

Up for SG6 review on 2022-02-17.

mattkretz commented 2 years ago

P0870R4: A proposal for a type trait to detect narrowing conversions

2022-02-17 SG6 Telecon Minutes

Chair: Matthias Kretz

Champion: Giuseppe D'Angelo

Minute Taker: Dietmar Kühl

SUMMARY: Consistency with the core language is more important than any numeric concern for P0870. SG6 approves the paper.

POLL: Consistency with the core language is more important than any numeric concern for P0870R4. SG6 approves the paper.

no objection to unanimous consent

# of Authors: 1 # of Participants: 8

mattkretz commented 2 years ago

The SG6 label can be removed (I don't have permission to do so).

dangelog commented 2 years ago

Hi all,

With SG6 having approved the paper, may I kindly ask to have it moved back into LEWG's queue?

During SG6's meeting there has been a request for better wording. I am afraid I don't have the necessary skills to improve on the existing one; if this matters for LEWG, just let me know, I'll try to find some help and produce a revised paper.

Thank you,

brycelelbach commented 2 years ago

LEWG will take a look at this.

brycelelbach commented 2 years ago

Is this still targeted for a TS?

brycelelbach commented 2 years ago

Deferring until we have a broader discussion about the status of the numerics TS.

dangelog commented 2 years ago

Hello,

To be honest I never had the intention of targeting the numeric TS, but the IS. I'm not sure how/when this got "redirected". I'll obviously trust your judgement if you think that the TS is a more appropriate shipping vehicle. :)

mattkretz commented 2 years ago

I don't think the shipping vehicle discussion came up in SG6. I believe the assumption was to go straight for the IS. At least SG6 has raised no questions that would require a TS process to answer. Let's have the TS discussion. But I believe LEWG can look at this paper independently and determine whether it could profit from a TS cycle or not.

brycelelbach commented 2 years ago

We'll look at it and assume we're looking at it for the IS.

brycelelbach commented 2 years ago

2022-09-13 Joint Library Evolution and Numerics Telecon

P0870R4: Type trait to detect narrowing conversions

2022-09-13 Joint Library Evolution and Numerics Telecon Minutes

Chair: Bryce Adelstein Lelbach

Minute Taker: Mark Hoemmen

Champion: Giuseppe D'Angelo

Start: 2022-09-13 11:05 Eastern

Does this paper have:

Examples?
- Yes.
Field experience?
- Implementation experience?
  - Yes, within Qt and as a patch to libstdc++.
- Usage experience?
  - Yes, within Qt and as a patch to libstdc++.
- Deployment experience?
  - Yes, within Qt and as a patch to libstdc++.
Discussion of prior art?
- Yes.
Changes Library Evolution previously requested?
- Yes.
Wording?
- Yes, but the Numerics group has suggested it could be improved.
Feature test macro?
- Yes.
Freestanding?
- The intention is yes.

Should future things like optional use is_convertible_without_narrowing?

Changing optional to use is_convertible_without_narrowing would be a breaking change - for example you can construct an optional<int> from a double today.

A variant<int> can't be constructed from a double, because it doesn't allow construction from things that narrow. Same for expected.

Related: P2509R0 (Type trait to detect value-preserving conversions).

POLL: Send P0870R4 (Type trait to detect narrowing conversions) to Library for C++26 classified as B3 - addition, to be confirmed with a Library Evolution electronic poll.

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
7	6	1	0	0

Attendance: 18

# of Authors: 1

Author Position: SF

Outcome: Strong consensus in favor.

End: 11:38

Summary

This is a proposal for a new trait to detect narrowing conversions. As narrowing conversions themselves are not extensible to user-defined arithmetic types, the author's intent is for this proposal to just cover builtin types.

There was some discussion about how we might use this trait within the Standard Library, both for existing features and future features. Some proposed that we could change existing types, like optional and variant, to use this trait, but others pointed out this would be a breaking change in semantics.

We also briefly talked about a related proposal, P2509 (Type trait to detect value-preserving conversions).

Library Evolution feels this feature is useful and we believe the proposal is well-baked.

Next Steps

Take a Library Evolution electronic poll to send P0870R4 (Type trait to detect narrowing conversions) to Library for C++26 classified as B3 - addition.

cor3ntin commented 2 years ago

2022-10 Library Evolution Electronic Poll Outcomes

__Send [P0870R4] is_convertible_without_narrowing to Library Working Group for C++26, classified as an addition ([P0592R4] bucket 3 item).__

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
9	6	1	0	0

Outcome: Strong consensus in favor.

dangelog commented 2 years ago

@cor3ntin I believe the above is a C&P mistake? I've got 9/6/1/0/0 (the outcomes paper isn't published yet, so I can't check against an authoritative reference...)

cor3ntin commented 2 years ago

Indeed, thanks for noticing.

wg21bot commented 1 year ago

P0870R5 A proposal for a type trait to detect narrowing conversions (Giuseppe D'Angelo)

dangelog commented 1 year ago

Hi @brycelelbach @cor3ntin ; during the review of this paper in Issaquah it's been requested whether LEWG could confirm a design choice.

To this end, I've uploaded R5. It does not change any design / behavior from R4, but it adds a paragraph that elaborates on the design choice mentioned above: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p0870r5.html#ch5.9

I guess this paper should go back to LWG only if LEWG can confirm that the choice was the intended one.

brycelelbach commented 1 year ago

This paper is now in the custody of Library Evolution.

brycelelbach commented 1 year ago

@inbal2l and @cor3ntin this can be handled with a mailing list review. It should get higher priority than others, as it's just a design clarification.

inbal2l commented 10 months ago

As P2280 was approved for C++26, the author would like to make design adjustments accordingly. P0870R6 will be seen by LEWG when published.

inbal2l commented 8 months ago

P3146 (#1797) Proposes a change to support this paper.

cor3ntin commented 2 months ago

@inbal2l FYI, P3146 does not actually propose any change.

dangelog commented 3 weeks ago

Hi,

@inbal2l FYI, P3146 does not actually propose any change.

That's not entirely true -- P3146 aims at clarifying the existing wording for variant's constructor, while claiming that none of the existing implementations actually follow it. If the clarifications are accepted, then implementations will need to change.

These clarifications also have an impact on P0870. If P3146 is accepted, then P0870 needs to update its wording. If P3146 is rejected, then P0870 is already correct. (It's following the current behavior of implementations for variant, but P3146 claims that the behavior is wrong.). Yes, I know that I've authored both papers :)

cplusplus / papers