On Wednesday, 22 October 2025 at 14:40:58 UTC, H. S. Teoh wrote:
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
This thread is probably more appropriate for the General forum
than this one.
Anyway, I haven't watched the Youtube video, but I'm not quite as
negative on C++ concepts as others.
I think you put this well, but I'm not so sure it is necessarily
a negative with respect to concepts, or otherwise putting
template constraints in the signature, provided there is a single
function. For instance, it makes sense for `to` to work with any
type, but maybe it makes sense to constrain a function that
should only work on floating point types to say that in the
signature (and then if integer types are added later, then it can
put a numeric type in the signature and have the
interger/floating point handling happen inside the function as an
implementation detail).
I think it's a question of best practices and making sure they
are widely understood.
The lingering issue is how to manage the organization of the code
and corresponding template bloat. If people follow your advice
and then have the `toImpl` helper functions within `static if`
blocks to improve organization, then that might increase template
bloat compared to having separate functions.
In one thing I was working on (that got really annoying to finish
off and my time got limited so I haven't had a chance to finish
it off), I was dealing with types that (basically) could be any
kind of floating point type, with different allocation
strategies, and (more-or-less) different ways to iterate through
them. And then passing this off to functions that only vary based
on floating point type. So you had to take the original types,
convert them slightly, and then pass them off to the downstream
function. But then you throw const/immutable into dealing with
it, which added another set of complexity. I think what I ended
up doing was a separate function signature depending on the
allocation type. But then since each function could take two
inputs, it ended up with like 6. And then those all ended up
calling down to one function.
Long story short, it was a real headache.
If it were possible to just have a one line function signature
with all the implementation complexity in the static if's, while
being well-organized and not too much template bloat, then that
would have been lovely.
