August 02, 2013
>
> Wrong. Specifying only types was perfectly legal in C and remains so in D. It would have been a major breaking change.

auto Add(a, b) {}

Is it feasible? "Specifying only types was perfectly legal in C and emains so in D"

Why don't we change our thinking way? Why we couldn't eliminate "PARAMTYPE _only_", make
"auto Add(a, b) {} " works?

August 02, 2013
On 2013-08-02 21:30:20 +0000, Dicebot said:

> On Friday, 2 August 2013 at 21:20:55 UTC, SteveGuo wrote:
>> We know that normal function parameter declaration is the form of "PARAMTYPE param"
> 
> Wrong. Specifying only types was perfectly legal in C and remains so in D. It would have been a major breaking change.

One variant discussed was:

auto fun(auto x, auto y) { … }

We concluded that's poor style anyway because most function should have constraints on types. Truth be told, at the time of that decision parameter names (viz. x and y) could not be used in template constraints. Now they could, so in a way that reopens the question.

Either way, this is not enabling something we couldn't do, so it's not high on the priority list.


Andrei

August 02, 2013
On Friday, 2 August 2013 at 21:29:12 UTC, SteveGuo wrote:
>>
>> Question is "should we"? It creates syntax ambiguity (a and b can be already existing types) and does not really improve language.
>
> Sorry for my pool English:p
>
> I think compiler can detect the difference.
> auto Add(a, b) {} // Compiler can detect "there is nothing in front of a and b, so a and b is template, not types defined in other modules"

auto Add(auto a, auto b) would be unambigious imo.

I don't see a need for that language change though.

My favourite colour of a bikeshed is blue.
August 02, 2013
On Friday, 2 August 2013 at 21:36:38 UTC, SteveGuo wrote:
>> Note that currently this is parsed as having _only_ PARAMTYPE.
>
> I just tested _only_
>
> void foo(_only_ a)
> {
> }
>
> but the compiler complaints "undefined identifier _only_"

<facepalm />

He meant that when you only have a single token it is parsed as PARAMTYPE and not varname.

EG:

void foo(int);
August 02, 2013
> He meant that when you only have a single token it is parsed as PARAMTYPE and not varname.
>
> EG:
>
> void foo(int);

Thanks for pointing out my misunderstanding.

But we can make a compiler which can "understand" what we want it understand.

void foo(int); // this is just a declaration, not a definition

auto foo(a) // this is a definition, with a function body, they are different
{
}


August 02, 2013
On Friday, 2 August 2013 at 22:00:44 UTC, SteveGuo wrote:
>
>> He meant that when you only have a single token it is parsed as PARAMTYPE and not varname.
>>
>> EG:
>>
>> void foo(int);
>
> Thanks for pointing out my misunderstanding.
>
> But we can make a compiler which can "understand" what we want it understand.
>
> void foo(int); // this is just a declaration, not a definition
>
> auto foo(a) // this is a definition, with a function body, they are different
> {
> }

No difference.

void foo(int)
{}

Is perfectly legal.
August 02, 2013
void foo(int); // function declaration

void foo(int a) {} // function definition

auto foo(a) {} // template function definition
August 02, 2013
On 8/2/13, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> auto fun(auto x, auto y) { … }
>
> Truth be told, at the time of that decision
> parameter names (viz. x and y) could not be used in template
> constraints. Now they could, so in a way that reopens the question.

You'd still have to use typeof(x) and typeof(y) to extract the types,
so even though you end up making the template declaration simpler you
also make the constraint more complicated.

Anyway after one uses templates for a longer while it becomes apparent that they're rather easy to use in D.
August 02, 2013
> void foo(int)
> {}
>
> Is perfectly legal.

But we can make a compiler which think its illegal.
August 02, 2013
> void foo(int)
> {}
>
> Is perfectly legal.

We could change the language definition, make things like "void foo(int) {}" illegal