"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