Hey Dmytro,

I think the idea of allowing some conversions to be non-narrowing is fine in principle; there are some parts that really need elaboration though.

I'm not really sure what the motivation here is for instance. The examples with your wrapper class templates are contrived because in generic code, you don't use list-initialization due other issues with narrowing conversions and due to std::initializer_list constructors. You list forwarding as a motivation, but perfect forwarding should never use list-initialization in the first place.

I also don't find the argument that a library solution cannot work convincing. List-initialization cannot cover loss of information between possible future standard library types like std::big_int, between existing types like std::complex, etc. There is no customization point to define certain constructors as narrowing or "list-init-deleted", so preventing information loss via list-initialization is incredibly half-baked. It may have been a mistake in hindsight.

What I would like to see in the paper above all else is a concrete real-world motivating example.

On Tue, 20 Jan 2026 at 12:08, Dmytro Ovdiienko via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
Hello,

I'd like to submit the proposal regarding relaxing the narrowing int -> floating conversion. 

Abstract

This paper proposes relaxing list-initialization narrowing rules so that an implicit conversion from an integer type to a floating-point type is not considered narrowing when the destination floating-point type adheres to ISO/IEC 60559, has a binary radix, and has sufficient precision to exactly represent all values of the source integer type.


The proposal is hosted on the GitHub. Following is a link:

https://github.com/ujos/cplusplus-narrowing-cast/blob/draft_r0/PXXXXR0.md

Could you give it a read and let me know if you have any comments.


Kind regards
Dmytro

--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals