"Concepts" should not be part of function headers
jmh530
john.michael.hall at gmail.com
Thu Oct 23 15:11:35 UTC 2025
On Thursday, 23 October 2025 at 13:51:40 UTC, An Pham wrote:
> On Thursday, 23 October 2025 at 12:38:08 UTC, jmh530 wrote:
>> On Thursday, 23 October 2025 at 02:06:44 UTC, H. S. Teoh wrote:
>>> [snip]
>>>
>>> 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
>>
>> What's the advantage of making them separately-named functions?
>
> 1. Easy to search for/jump to implementation
> 2. No need template constraint(s) -> faster compile
>
> Happy coding
I get 1, that's a good point, but not sure on 2.
Just looking at `toImpl` functions in std.conv, they all have
template constraints. Let's suppose you convert them all to
functions with separate names but no template constraints. But
they're still all templated functions, so anyone working on the
code base needs to make sure not to use those functions
improperly (working in the module that is, they're all private
functions). So I'd wonder, why get rid of the template
constraints even if you change the name? Just sets yourself for
potential future bugs. The speed up for compilation is probably
more related to a smaller set for overload resolution. Might be a
bit better for error messages, but not sure offhand.
Speaking of error messages, I think that's really the one place
where concepts really are supposed to shine.
More information about the Digitalmars-d-learn
mailing list