Bug 2733 – Unclear semantics of template value parameters

The following code compiles but the generated binary is not correct. import std.stdio; void foo(string s)() { writefln(s); } void main() { string s = "test"; foo!(s); } ---- Prints nothing. In less trivial cases, passing non-const arguments to value parameters causes data corruption/access violations. It is not defined whether the argument should be passed by alias or the code should fail to compile complaining about the argument not being evaluatable at compile time.

Non-alias template arguments are, by definition, compile-time constants. s isn't a compile-time constant - it's a mutable reference to immutable data. So this shouldn't compile.

I'm not that sure anymore. Actually, I wouldn't mind if they were passed by alias. Then, I could write simply template foo(string s) {} instead of template foo(alias s) if (isString!(s)) {} If I want to restrict template arguments to statically known values, I can use a isCompileTime constraint template foo(string s) if (isCompileTime!(s)) { }

(In reply to comment #2) > If I want to restrict template arguments to statically known values, I can use > a isCompileTime constraint Templates with non-alias parameters are instantiated by value at compile-time in the first place. What you're proposing would be a radical change to this. You could try defining that such a template may be instantiated either by value or by alias. However, this is effectively creating two mutually incompatible templates, and it can be confusing to try to work out which is being instantiated. I can't think of a practical use case for passing a string by alias in a function template, but I'm guessing there's a use for it in templates of some kinds. The question is whether there are enough use cases for syntactic sugar to be worthwhile, but it could look something like template foo(string alias s) ....

I changed the version to a D1 one as it is also accepts-invalid there.

Not a spec issue - it's a D1 only bug where a template value parameter that is not a compile-time constant is allowed.

*** This issue has been marked as a duplicate of issue 2257 ***