Thoughts about "Compile-time types" talk

H. S. Teoh hsteoh at quickfur.ath.cx
Tue May 14 17:44:17 UTC 2019


On Mon, May 13, 2019 at 08:35:39AM +0000, Martin Tschierschke via Digitalmars-d wrote:
> On Friday, 10 May 2019 at 00:33:04 UTC, H. S. Teoh wrote:
> [...]
> > I haven't fully thought through this yet, but the basic concept is
> > that there should be *no need* to distinguish between compile-time
> > and runtime in the general case, barring a small number of
> > situations where a decision has to be made.
> [...]
> I was thinking and working in the same direction,
> when using regEx you can use the runtime (RT) or the compile time (CT)
> version, but why not let the compiler make the decisions?

It would be great if the compiler could make all of the decisions, but I
think at some point, some level of control would be nice or even
necessary.

What I envision is this:

- Most parameters are not specifically designated compile-time or
  runtime; they are just general parameters. So your function fun(x,y,z)
  has 3 parameters that could be runtime, or compile-time, or a mix of
  either. Which, exactly, is not decided at the declaration of the
  function.

- At some higher level along the call chain, perhaps in main() but
  likely in some subordinate but still high-level function, a decision
  will be made to, for example, call fun() with a literal argument, a
  compile-time known value, and a runtime argument obtained from user
  input. This then causes a percolation of CT/RT designations down the
  call chain: if x is bound to a literal, the compiler can pass it as a
  compile-time argument. Then inside fun(), it may pass x to another
  function gun(p,q,r).  That in turn fixes one or more parameters of
  gun() as compile-time or runtime, and so on. Similarly, if y as a
  parameter of fun() is bound to a runtime value, then if y is also
  passed to gun() inside fun()'s body, then that "forces" the
  corresponding parameter to be bound to runtime value.

You could think of it as all functions being templates by default, and
they get instantiated when called with a specific combination of
runtime/compile-time arguments. With the added bonus that you don't have
to decide which parameters are template parameters and which are runtime
parameters; the compiler infers that for you based on what kind of
arguments were passed to it.

Of course, sometimes you want to force a certain parameter to be either
runtime or compile-time, e.g., to control template bloat. So perhaps
some kind of designation like @ct or @rt on a parameter:

	// Tentative syntax
	auto fun(@ct int x, @rt int y) { ... }

This would force x to always be known at compile-time, whereas y can
accept either (you can think of it as @ct "implicitly converts to" @rt,
but not the other way round).

If a parameter is not designated either way, then the compiler is free
to choose how it will be implemented.


T

-- 
If it tastes good, it's probably bad for you.


More information about the Digitalmars-d mailing list