July 22, 2011
http://d.puremagic.com/issues/show_bug.cgi?id=2779



--- Comment #10 from Andrei Alexandrescu <andrei@metalanguage.com> 2011-07-22 10:20:55 PDT ---
Jacob: yes, and that's a great thing. What's not so great is the interaction between tuples and matching arguments to functions, as I explained. I didn't argue that saving ".whatever" is not worthy IN GENERAL.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
July 22, 2011
http://d.puremagic.com/issues/show_bug.cgi?id=2779



--- Comment #11 from Jacob Carlborg <doob@me.com> 2011-07-22 11:06:48 PDT ---
Andrei: I don't see how it could be much different when matching one argument and several.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
July 22, 2011
http://d.puremagic.com/issues/show_bug.cgi?id=2779



--- Comment #12 from Andrei Alexandrescu <andrei@metalanguage.com> 2011-07-22 11:11:48 PDT ---
(In reply to comment #11)
> Andrei: I don't see how it could be much different when matching one argument and several.

I explained in my argument about this:

fun(t1, t2, t3, t4);

How do you suggest we handle that?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
July 22, 2011
http://d.puremagic.com/issues/show_bug.cgi?id=2779



--- Comment #13 from Jacob Carlborg <doob@me.com> 2011-07-22 11:21:21 PDT ---
(In reply to comment #12)
> (In reply to comment #11)
> > Andrei: I don't see how it could be much different when matching one argument and several.
> 
> I explained in my argument about this:
> 
> fun(t1, t2, t3, t4);
> 
> How do you suggest we handle that?

Depends on how the function is declared and what's passed to the function. If the original type matches (i.e. the tuple) then don't expand the tuple. If the tuple doesn't match then try to expand the tuple.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
July 22, 2011
http://d.puremagic.com/issues/show_bug.cgi?id=2779



--- Comment #14 from Andrei Alexandrescu <andrei@metalanguage.com> 2011-07-22 11:24:19 PDT ---
(In reply to comment #13)
> (In reply to comment #12)
> > (In reply to comment #11)
> > > Andrei: I don't see how it could be much different when matching one argument and several.
> > 
> > I explained in my argument about this:
> > 
> > fun(t1, t2, t3, t4);
> > 
> > How do you suggest we handle that?
> 
> Depends on how the function is declared and what's passed to the function. If the original type matches (i.e. the tuple) then don't expand the tuple. If the tuple doesn't match then try to expand the tuple.

fun could be overloaded and might use variadics and template constraints.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
July 22, 2011
http://d.puremagic.com/issues/show_bug.cgi?id=2779



--- Comment #15 from Jacob Carlborg <doob@me.com> 2011-07-22 11:29:47 PDT ---
Say we have this:

struct Foo
{
    int value;
    alias value this;
}

If an "instance" of Foo is passed to a function taking variadic arguments then it's received as Foo and not int, correct? Why would an alias this with a tuple behave any different. In that case you would have to manually expand it.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
July 22, 2011
http://d.puremagic.com/issues/show_bug.cgi?id=2779



--- Comment #16 from Kenji Hara <k.hara.pg@gmail.com> 2011-07-22 11:36:47 PDT ---
(In reply to comment #15)
> If an "instance" of Foo is passed to a function taking variadic arguments then it's received as Foo and not int, correct?

It is correct. Variadic functions take arguments itself, not expanded.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
July 22, 2011
http://d.puremagic.com/issues/show_bug.cgi?id=2779



--- Comment #17 from Andrei Alexandrescu <andrei@metalanguage.com> 2011-07-22 11:44:32 PDT ---
(In reply to comment #15)
> Say we have this:
> 
> struct Foo
> {
>     int value;
>     alias value this;
> }
> 
> If an "instance" of Foo is passed to a function taking variadic arguments then it's received as Foo and not int, correct? Why would an alias this with a tuple behave any different. In that case you would have to manually expand it.

This is not only about variadic arguments, sorry for being confusing. It is about the combinatorial explosion when overloading rules meet automatic expansion. Again, please consider this example:

fun(t1, t2, t3, t4);

and consider:

* fun may have an arbitrary number of overloads
* Some or all of t1 through t4 may be tuples, some also including tuples of
tuples

The fact that there exists an algorithm to find an expansion (albeit in potentially a long time) is little solace when we consider the complexity inflicted on the human reader.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
July 22, 2011
http://d.puremagic.com/issues/show_bug.cgi?id=2779



--- Comment #18 from Jacob Carlborg <doob@me.com> 2011-07-22 12:02:51 PDT ---
> This is not only about variadic arguments, sorry for being confusing. It is about the combinatorial explosion when overloading rules meet automatic expansion. Again, please consider this example:
> 
> fun(t1, t2, t3, t4);
> 
> and consider:
> 
> * fun may have an arbitrary number of overloads
> * Some or all of t1 through t4 may be tuples, some also including tuples of
> tuples
> 
> The fact that there exists an algorithm to find an expansion (albeit in potentially a long time) is little solace when we consider the complexity inflicted on the human reader.

Ok, I can see now that it can become quite complicated. Specially with nested tuples.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
1 2
Next ›   Last »