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
