Proposal: Object/?? Destruction

[Timon Gehr]

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.