On Friday, 2 August 2013 at 22:12:29 UTC, SteveGuo wrote:
>> void foo(int)
>> {}
>>
>> Is perfectly legal.
>
> We could change the language definition, make things like "void foo(int) {}" illegal

No. Useless breaking change.

On 08/03/2013 12:06 AM, Andrej Mitrovic wrote:
> 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.
> ...

bool compare(a,b) if(__traits(compiles,a<b)) { return a<b; }

On 8/2/13 3:17 PM, Timon Gehr wrote:
> On 08/03/2013 12:06 AM, Andrej Mitrovic wrote:
>> 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.
>> ...
>
> bool compare(a,b) if(__traits(compiles,a<b)) { return a<b; }

Direct use of __traits is unrecommended outside the stdlib. I had this pattern in mind:

bool compare(auto a, auto b) if (is(typeof(a < b) : bool)) { ... }


Andrei

On 08/03/2013 12:19 AM, Andrei Alexandrescu wrote:
> On 8/2/13 3:17 PM, Timon Gehr wrote:
>> On 08/03/2013 12:06 AM, Andrej Mitrovic wrote:
>>> 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.
>>> ...
>>
>> bool compare(a,b) if(__traits(compiles,a<b)) { return a<b; }
>
> Direct use of __traits is unrecommended outside the stdlib.

The language is not expressive enough to wrap __traits(compiles,a<b) in the stdlib.

> I had this pattern in mind:
>
> bool compare(auto a, auto b) if (is(typeof(a < b) : bool)) { ... }
> ...

Checking for implicit conversion to bool is redundant due to how operator overloading is handled for '<'.

Furthermore, this constraint is not sufficient.


bool compare(A,B)(A a,B b) if (is(typeof(a < b) : bool)){
    return a<b;
}

void main(){
    int o(T)(T r){ return 0; }
    static struct S{
        alias o opCmp;
    }
    compare(S(),S()); // causes error in template body
}

DMD's implementation of __traits(compiles,...) currently shares this issue; this is a compiler bug as far as I can tell. The above behaviour is to be expected for is(typeof(.)) though.

On Fri, Aug 02, 2013 at 03:19:33PM -0700, Andrei Alexandrescu wrote:
> On 8/2/13 3:17 PM, Timon Gehr wrote:
> >On 08/03/2013 12:06 AM, Andrej Mitrovic wrote:
> >>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.
> >>...
> >
> >bool compare(a,b) if(__traits(compiles,a<b)) { return a<b; }
> 
> Direct use of __traits is unrecommended outside the stdlib. I had this pattern in mind:
> 
> bool compare(auto a, auto b) if (is(typeof(a < b) : bool)) { ... }
[...]

I like this syntax.

I'm worried, though, about how it will interact with explicit template parameters. E.g., how would you express this:

	bool func(R,T,U)(T t, U u) { ... }

in the new syntax?

	bool func(R)(auto t, auto u) { ... }

?

What if we have variadics on either side?

I'm still on the fence as to whether we should add the new syntax, nice as it is. The current syntax is far more unambiguous, and allows you to specify signature constraints on the input types directly, as well as use it in the return type spec, without needing to say typeof(t) or typeof(u).


T

-- 
"The whole problem with the world is that fools and fanatics are always so certain of themselves, but wiser people so full of doubts." -- Bertrand Russell. "How come he didn't put 'I think' at the end of it?" -- Anonymous

> I like this syntax.
>
> I'm worried, though, about how it will interact with explicit template
> parameters. E.g., how would you express this:
>
> 	bool func(R,T,U)(T t, U u) { ... }
>
> in the new syntax?
>
> 	bool func(R)(auto t, auto u) { ... }
>
> ?
>
> What if we have variadics on either side?
>
> I'm still on the fence as to whether we should add the new syntax, nice
> as it is. The current syntax is far more unambiguous, and allows you to
> specify signature constraints on the input types directly, as well as
> use it in the return type spec, without needing to say typeof(t) or
> typeof(u).
>
>
> T

If these syntax is feasible to template functions, is it possible to apply it to class template?

class A
{
    int a; // normal member
    auto b; // template member?
}

On Sat, Aug 03, 2013 at 01:03:36AM +0200, SteveGuo wrote:
> >I like this syntax.
> >
> >I'm worried, though, about how it will interact with explicit template parameters. E.g., how would you express this:
> >
> >	bool func(R,T,U)(T t, U u) { ... }
> >
> >in the new syntax?
> >
> >	bool func(R)(auto t, auto u) { ... }
> >
> >?
> >
> >What if we have variadics on either side?
> >
> >I'm still on the fence as to whether we should add the new syntax, nice as it is. The current syntax is far more unambiguous, and allows you to specify signature constraints on the input types directly, as well as use it in the return type spec, without needing to say typeof(t) or typeof(u).
> >
> >
> >T
> 
> If these syntax is feasible to template functions, is it possible to apply it to class template?
> 
> class A
> {
>     int a; // normal member
>     auto b; // template member?
> }

I think that's a bad idea. It's too ambiguous. What will you do with template member functions?

	class A
	{
		auto b(auto c) { ... }
	}

What are the template parameters of A?

I still think the current syntax is better. It's a little more verbose in some cases, but I think that's not a big deal. After having used D templates for a while now, the syntax is actually very comfortable to use. I think this kind of cosmetic change is not worth the effort (and potential breakage) at this point in time.


T

-- 
A computer doesn't mind if its programs are put to purposes that don't match their names. -- D. Knuth

> 	class A
> 	{
> 		auto b(auto c) { ... }
> 	}
>
> What are the template parameters of A?

class A
{
     void foo(auto x) { ... }
}

int main()
{
    scope a = new A;

    a.foo(1); // this means A has a member function "void foo(int x) {...}"
    a.foo(1.1); // this means A has another member function "void foo(double x) {...}"
    // compiler will automatically build two versions of function "foo"
}

On 8/2/2013 1:34 PM, SteveGuo wrote:
> I'm not an expert on programming language, if I made a naive issue, just forgive
> me:p

We never forgive, and the internet never forgets! :-)


> Can we declare a template function like this?
>
> auto Add(a, b) // Note a, b do not have type, that means a and b use template type
> {
>      return a + b;
> }
>
> auto Sub(a, int b) // a uses template type, b is fixed to int
> {
>      return a - b;
> }

The trouble with this is that sometimes people will use a type without an identifier in order to indicate that the parameter is not used:

auto Foo(int, unsigned x)

But also note that for lambdas, D does allow the form you suggest, as there weren't backwards compatibility issues with it.

On Sat, Aug 03, 2013 at 01:20:02AM +0200, SteveGuo wrote:
> 
> >	class A
> >	{
> >		auto b(auto c) { ... }
> >	}
> >
> >What are the template parameters of A?
> 
> class A
> {
>      void foo(auto x) { ... }
> }
> 
> int main()
> {
>     scope a = new A;
> 
>     a.foo(1); // this means A has a member function "void foo(int x)
> {...}"
>     a.foo(1.1); // this means A has another member function "void
> foo(double x) {...}"
>     // compiler will automatically build two versions of function
> "foo"
> }

How would you translate this to the new syntax:

	class A(T,U)
	{
		T fun1(U x) { ... }
		U fun2(T x) { ... }
		V fun3(V)(V x) { ... }
		auto fun4(T)(T x) { ... }
		auto fun5(V)(T x, V y) { ... }
		const(T) fun6(T x) { ... }

		T p;
		T q;
		U r;
		U s;
	}

?


T

-- 
The easy way is the wrong way, and the hard way is the stupid way. Pick one.