Is there any real reason to use "const"?

[jmh530]

On Monday, 24 January 2022 at 20:09:46 UTC, H. S. Teoh wrote:
> [snip]
>
> Makes me curious: how feasible is it to have functions with 
> identical bodies merge together as well? This would help reduce 
> template bloat when you have e.g. a templated type where a 
> bunch of functions are identical because they either don't 
> depend on the type (e.g. a container method that doesn't care 
> about what type the payload is), or else depend on type traits 
> that are common across many types (e.g., int.sizeof which is 
> shared with uint.sizeof, float.sizeof, etc.).
>
>
> T

This reminds me of generics. In languages with generics, you can 
get one copy of a function over many different types. My 
(possibly incorrect) recollection is that it works like having 
the compiler cast the generic MyClass!T to MyClass. Ideally from 
D's perspective there would be a way to do this to minimize any 
overhead that you would get in Java from being forced to use 
classes.

Merging functions with identical bodies is basically the problem 
that inout is trying to solve. A way to express inout via the 
language would probably be good, though inout is rather 
complicated.  For instance, you have an Inout(T) with the 
property that if you have a function that takes an Inout(T), then 
calling it with Inout!int, Inout!(const(int)), and 
Inout!(immutable(int)) would all have only one version of a 
function at runtime. You would still need to be able to enforce 
that Inout(T) has the same unique behaviors as inout, such as 
that you can't modify the variable in the body of the function.

This would also be useful for reducing template bloat with 
allocators. For instance, if you have a templated function that 
takes an allocator as a parameter, then for every different 
allocator you use with it, you get an extra copy of the function, 
even if the body of the function may be the same across the 
different allocators used (since it may be jumping to the 
allocator to call that code).