DIP23 Counter Proposal

[Timon Gehr]

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.)