On Tue, Jan 20, 2026 at 7:02 AM Jan Schultke via Std-Proposals <
std-proposals_at_[hidden]> wrote:

>
> 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.
>

+1. The current paper's "int to double" is the skeleton of a *good*
example, but it's not a *real-world* example because

> int32_t i = runtime();
> double d{i};

is not *itself* code that a real programmer would write. We need more
"novelistic detail" in that example. Ideally, take an example from a real
codebase. Taking an example from a real codebase will necessarily mean also
showing *how people work around this today*, since the code you want to
write won't compile today. This will naturally lead to a Tony Table:
"today's workaround" on the left, "what I want to write" on the right. And
*that* will force you to explain why you *want* to write curly braces here:
why is the workaround (presumably `double d = i;` which is a perfectly
natural idiom as far back as K&R C) *not* attractive to you?

Important formatting nit: Please move "Proposed wording" to the bottom —
below "Why a library-only solution is inefficient" — and actually show the
diff, using <ins> and <del> markup (green and red), and showing all of
sentence 7 for context. Saying "Replace bullet 7.3 with..." is technically
unambiguous, but it's not reader-friendly. At the very very least, please
give a hyperlink to the current [dcl.init.list]
<https://eel.is/c++draft/dcl.init.list#7>!

Wording: The current wording uses the cumbersome phrase "will fit into the
target type and will produce the original value when converted back to the
original type." You add a bullet point using the shorter phrase "can
exactly represent." Are these two phrases supposed to be synonymous? If
they are synonymous, please pick one or the other and use it consistently.
If they are not synonymous, please explain the difference — and explain
what will break if we fail to capture that difference in the wording.

Wording: I wonder whether at this point you could just eliminate (7.3) and
add "or floating-point" to (7.4):

> [...] (7.4) from an integer type or unscoped enumeration type to an
> integer *or floating-point* type that cannot represent all the values of
> the original type, except where [...]


my $.02,
–Arthur