On 06.10.2017 23:34, Steven Schveighoffer wrote:
No. All functions take one argument and produce one result. (The
argument and the result may or may not be a tuple, but there is no
essential difference between the two cases.) You can match a value
against a pattern on the function call.
It is weird to me that a function with 2 parameters is the same as a
function that takes a 2-element tuple, but a function with one parameter
is not the same as a function that takes a 1-element tuple. That is
where I feel it's a contradiction.
...
If a function with 2 parameters was the same as a function that takes a
2-element tuple, and a function with one parameter that is a 2-element
tuple is the same as a function that takes a 1-element tuple, then a
function that takes a 2-element tuple is the same as a function that
takes a 1-element tuple. So I think the opposite is the case.
// those two are the same
void foo(int a,string b); // match two-element tuple
void foo((int,string) x); // take two-element tuple w/o matching
// those two are the same
void bar(int a,); // match one-element tuple
void bar((int,) x); // take one-element tuple w/o matching
This is like:
(int a,string b)=(1,"2"); // match
// vs
(int,string) x=(1,"2"); // w/o matching
and
(int a,)=(1,); // match
// vs
(int,) x=(1,); // w/o matching
In case this is not convincing to you: Why does your reasoning apply to
arguments but not return values? Why should arguments not behave the
same as return values? If it does actually apply to return values: what
special syntax would you propose for functions that "return multiple
values"? Is it really reasonable to not use tuples for that?
This would mess up a TON of code. I can say for certain, a single
type argument can never be made to accept a tuple.
The proposal is to make all arguments "single type arguments". The
"single type" might be a tuple. A tuple type is just a type, after
all. For two current functions where only one matches but after the
change both would match, the same one would still be selected, because
it is more specialized.
Right, but cases where T is expected to match to exactly one type will
now match with multiple types. It messes up is(typeof(...)) checks.
-Steve
All new language features can be detected using is(typeof(...)) this is
usually ignored for language evolution. We'd need to check how much code
relies on this specific case not compiling.
We can also think about adding a "light" version of tuple support, that
just supports unpacking for library-defined tuple types and nothing
else, but I'd prefer to have proper tuples.
