Add is_convertible_without_narrowing

[yaito3014]

fixes #5

The array form To[] is specifically chosen over the simpler To{from} because the latter can accidentally select aggregate initialization of To itself (if To is an aggregate) or match a constructor taking std::initializer_list, both of
which would mask the actual narrowing behavior. Since To[] is always an aggregate regardless of what To is, the braced initialization applies uniformly to the element type and tests exactly what we want: whether From can be
copy-initialized into a To slot without narrowing.

[cppwarningnotifier]

Environment				C++23	C++26
iris	Clang	21	Debug	✅success	✅success
			Release	✅success	✅success
	GCC	14	Debug	✅success	✅success
			Release	✅success	✅success
	MSVC	2022	Debug	✅success	✅success
			Release	✅success	✅success
		2026	Debug	✅success	✅success
			Release	✅success	✅success

[saki7]

1. Please fix aggregate_initialize_overload to make it use is_convertible_without_narrowing.
2. Please add these test cases:
   • https://x.com/wx257osn2/status/1941957460463624223
   • https://x.com/zakkas783/status/1942114456814911681
   • https://x.com/zakkas783/status/1942114769017950462

[saki7]

I think is_assignable_without_narrowing should also be added here as a companion utility, not in X4. After that, I think it looks good to me.

[saki7]

For non-arithmetic Dest types, narrowing is not checked

Why? This doesn't make sense at all.

"—" is a very bad sign for vibe coded slop. Please, please double check both the description and code itself.

Do you really think "not is arithmetic" can be the constituent part for being "assignable without narrowing"?

Arithmeric types are just arithmeric types. There should be absolutely no direct relationship to the concept of "assignable", whatever the condition is.

Am I missing something?

I'm really disappointed to see this level of low quality code.

[yaito3014]

As noted in the clarification, is_assignable_without_narrowing itself was for detecting narrowing conversion, so it was just is_assignable for non-arithmetic types. The "mistake" was that the trait was used directly in X4 codebase, not the trait definition.
I admit that the clarification was missing, but before saying "vibe coded slop" or "low quality code", rethink about it.

[saki7]

I just realized that even the implementation for is_convertible_without_narrowing diverges from the original implementation described in the paper. Please (1) add test that correctly asserts the current (wrong) implementation to false-positive value, and (2) Fix the definition.

This mistake was not caught on my first review because I trusted your code initially. It seems like I have to be extra careful since you posted some AI coded crap!

[yaito3014]

add test that correctly asserts the current (wrong) implementation to false-positive value

The former implementation DID work except for void to void "conversion" BTW.
https://godbolt.org/z/cEcK3fW8j

The differences from original were:

• requires parameter vs declval
• existance of same_as<To[1]>

The first is just styling difference.
The second is a too verbose check, since we are passing only one initializer to To[].

The original reference implementation fails on void to void case too, so implementing the exact same trait is also wrong, yet the author already mentions about it.

[saki7]

I think the first parameter Ti can be omitted, as it existed for checking is_convertible by passing-by-value

[yaito3014]

No, the Ti parameter cannot be omitted, since we should consider overload resolution for Ti including implicit conversion sequence's priority.

For example, constructing rvariant<int, long> from int should be resolved to index() == 0 though both int and long are equally convertible from int without narrowing. This is because identity conversion should occur prior to integral promotion in standard conversion.