"Concepts" should not be part of function headers

[H. S. Teoh]

On Thu, Oct 23, 2025 at 12:07:51AM +0000, Paul Backus via Digitalmars-d-learn wrote:
> On Wednesday, 22 October 2025 at 14:40:58 UTC, H. S. Teoh wrote:
> > 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.
> 
> In the specific case of `std.conv.to`, the user-facing template *is*
> unconstrained. Its signature is:
> 
>     template to(T)
> 
> However, the internal function that `to` forwards to, `toImpl`, does
> use template constraints to create an incomprehensible overload set.

So the problem wasn't solved, just moved from the public API to the
internal API.  Since it's no longer user-facing, those overloads really
should be separately-named functions instead IMNSHO. Not 50 overloads on
`toImpl`.


T

-- 
If blunt statements had a point, they wouldn't be blunt...