On 02/06/2013 06:12 AM, deadalnix wrote:
On Wednesday, 6 February 2013 at 03:43:28 UTC, Timon Gehr wrote:
For the optional () part, I want to raise concern about point 2 (the
others make sense).
In all other points, foo is either a call to function foo or the
function foo itself. In point 2, we introduce a 3rd meaning of foo,
identical to weird stuff we have in C/C++ (as we obviously aren't taking
the address either of the function or of its result when executed). This
object is an error of C and C++ we must get rid of.
1. This would break a lot of code.
2. How to get a first-class function value (function pointer,
delegate) from a function name otherwise?
2. I see no point in not making foo a first class function value.
Not having it does complicate things for no benefit. Any
complication should be properly motivated.
This does not imply that optional () should be removed, as it is
a mostly orthogonal problems (as scala shows).
So you would prefer Scala-like syntax? Scala uses suffix _ for what we
use prefix &. Without something like that, type deduction is crippled.
1. As of backward compat, & can be kept and follow the usual
deprecation process.
I think this language change is not part of the DIP that fixes optional
parens and @property, but a separate improvement.
...
Point 3 is nonsensial if we want to really be rigorous as :
returnType foo(TemplateArgs)(args) {}
is equivalent to
template foo(TemplateArgs) {
returnType foo(args) {}
}
In this case foo is a template,
Yes, a function template. Note that functions overload against
function templates.
not a function. foo!args is the function
hen eponymous trick is used.
I think you misunderstand.
If we have eg:
void foo(){ return 2; }
void foo(int x)(){ return 2; }
then we want:
static assert(foo!2==2);
Without rule 3, the code would be rewritten to
static assert(foo()!2==2);
And this would fail.
Well the thing that a function CANNOT be used before template parameter
(so function will be removed from overload set and only template will
remains).
foo _is_ the overload set. In order to decide whether to rewrite it to
foo() or not, it is necessary to look at the context ("before template
parameter"), which is what rule 3 states.
My example is still valid if you make the first overload templated. The
rewrites must happen before overload resolution. In fact, they may
decide which overload is ultimately chosen. (You can be certain that my
working implementation of optional parens would cease to work if I
removed rule 3.)
