On Wed, Oct 22, 2025 at 09:10:03AM +0000, monkyyy via Digitalmars-d-learn wrote:
> https://youtu.be/1p6So6vE5WM?si=tEbeBOQ-xXjJawMY
> 
> "if its a subset it automagically picks the right one because of our clever overload rules"
> 
> No, No, just No; every overload set with >5 memebers is a big ball of bugs such as `to`
> 
> These are *type assertions*; `isComaparable!(T,U)`=>bool could be made
> with a reusable error code by as `template
> assertComaparable(T,U,string func=__FUNCTION__)` =>
> "max of int and string requires opCmp, consider:
>   1) .to!string of the first argument
>   2) .to!int of th 2nd argument
>   3) implementing int.opCmp(string)
>   4) implementing string.opCmp(int)
> "

I've argued this before: many instances of overload sets in Phobos should not be overload sets at all, but should be single functions (or perhaps a *much* smaller overload set) with static if's inside the function body to dispatch to the various implementations, along with static assert's that provide helpful error messages for when the arguments don't match any of the static if conditions.

The user-facing function signature should describe the *logical* API, rather than implementation details such as "if input is a float, if input is an enum, ..." ad nauseaum.  Logically, std.conv.to is supposed to accept *all* types (even if the current implementation may or may not accept *everything*), so the function signature should be:

	T to(T,U)(U data) { ... }

*without* any signature constraints.  All the stuff like "if U is floating-point, if U is enum, if U is struct, ...", etc., are implementation details, that should be left to static if's inside the function body rather than clutter the API with an incomprehensibly large overload set.


T

-- 
Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? -- Michael Beibl