Function template literals - or "just" parameter type inference?
Jakob Ovrum
jakobovrum at gmail.com
Tue Nov 19 22:23:34 PST 2013
As I was preparing a pull request to fill in some documentation,
I became unsure of a couple of things.
It's clear that the Parameter[1] syntactic element does not
account for the form `InOut(opt) Identifier`, used when the
parameter type is left to inference. However, this form is only
allowed in function/delegate literal expressions, not in
declarations of named functions. So, perhaps adding this form to
Parameter is incorrect, as it's referenced for both. Do we need
to define a new kind of parameter list for FunctionLiteral[2] in
order to account for this extra form?
Further, parameter type inference is implemented in terms of
(anonymous) function templates. However, the documentation only
mentions parameter type inference once, in the following
sentence, under FunctionLiteral[2]:
> If the type of a function literal can be uniquely determined
> from its context, the[sic] parameter type inference is possible.
Followed by this example:
---
void foo(int function(int) fp);
void test() {
int function(int) fp = (n) { return n * 2; };
// The type of parameter n is inferred to int.
foo((n) { return n * 2; });
// The type of parameter n is inferred to int.
}
---
There is no mention of function templates; is it just an
implementation detail, or something we should document? If we
ever implemented it in some other way, would it not have
consequences for code that can take function templates by alias
and possibly call the same function template several times but
with completely different argument types, which is currently
valid and possibly useful?
[1] http://dlang.org/declaration.html#Parameter
[2] http://dlang.org/expression.html#FunctionLiteral
P.S.
The examples in the language documentation often use widely
inconsistent brace style, and I also found several examples using
capitalization that differs from the Phobos style. Maybe we
should aim to normalize them to use the Phobos style.
More information about the Digitalmars-d
mailing list