OT: Go go gadget templates

[H. S. Teoh via Digitalmars-d]

On Wed, Jul 05, 2017 at 05:04:40PM -0700, Ali Çehreli via Digitalmars-d wrote:
> On 07/05/2017 04:25 PM, Luís Marques wrote:
> > Funny...
> > 
> > <https://twitter.com/snoyberg/status/882255351382462464>
> 
> Creative! However, I'm offended that other people never appreciate D's
> syntax. Why did they go (argh!) for C++ and Java template syntax? :/
> 
> Speaking of which, I've just experimented with triple function
> parameter lists: for run time, for compile time, and for ... some
> other time...
> 
> Note how it allows foo() and bar() function template templates to
> share template template arguments (long and uint below):
> 
>     foo❗⎛long⎞!"hello"(42);
>     bar❗⎝uint⎠!"world"(43);
> 
> Ali
> "this is a joke"

You may have intended it as a joke, but lately I've been thinking about
algorithms with parameters that really shouldn't be fixed to runtime or
compile-time, but rather this decision should be postponed till later.
In other words, a kind of "some other time" parameter.  In particular,
from a higher-level POV, the decision about whether a parameter is baked
in at compile-time or left open till runtime really ought to be decided
by the compiler based on various factors.

If you have a library function f that takes two parameters, x and y, but
your program only ever calls it with x=10, say, then it benefits the
executable to have x as a compile-time parameter -- you save on the cost
of passing an extra parameter that's going to have the same value
anyway.  OTOH, as the library author, you don't know whether your users
will always call f with a compile-time known x, so you could either make
that decision for your users, which then leaves them stranded if you
decided x is better off as a compile-time parameter but they need to
pass a runtime parameter to it; or you could decide to make it a runtime
parameter, but then lose out on the use cases where x is already known
at compile-time.

Now consider the case if f has two runtime parameters, and the user
writes code like this:

	auto z = f(1, 2);

As part of the compiler's optimization pass, the compiler notices that
since both parameters are compile-time constants, it could simply
evaluate f in CTFE and fold its return value into z, completely, thus
effectively making the decision turning what was declared as runtime
parameters into compile-time parameters.

On the flip side, if f is declared to have x and y both compile-time
parameters, then you have the problem of template bloat if f is called
with a wide variety of arguments.

And in the "in-between" cases, sometimes f is called with arguments
known at compile-time, sometimes with arguments only known at runtime.

Arguably, it should be part of the compiler's optimizer that decides
whether it's "worth" turning some runtime parameters of f into
compile-time arguments, or, if it deems template bloat to be a problem,
turning some currently-compile-time parameters to be runtime parameters
instead. Ultimately, the library author shouldn't be forced to decide
either way, unless it's part of the API design to force certain
parameters to be compile-time or runtime.  At least there should be the
possibility of telling the compiler "this parameter could be either
compile-time or runtime, you decide later when user code calls this
function".

IOW, the parameter should be a "some other time" parameter. :-D


T

-- 
Freedom of speech: the whole world has no right *not* to hear my spouting off!