Proposal: Object/?? Destruction

[Timon Gehr]

On 09.10.2017 01:20, Steven Schveighoffer wrote:
> On 10/7/17 8:56 PM, Timon Gehr wrote:
>> 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
> 
> My questioning comes with this:
> 
> void bar(int a);
> void bar((int,) x);
> 
> To me, it is confusing or at least puzzling that these two aren't the same.
> ...

Well, to me it is a bit confusing that this is puzzling to you. Why 
should int be the same as (int,)? It does not make sense to index an 
integer, but (int,) can be indexed with 0 to get an integer.

I believe your difficulty is rather with the notion that what before was 
a function that takes a single value is no longer analogous to what 
before was a function that takes multiple values. The analogy breaks 
because now they are handled precisely the same way, rather than just 
analogously. Furthermore, some existing syntax slightly changes meaning: 
The prior syntax for declaring multiple arguments is now a pattern that 
matches against a single tuple argument.

The new design is more orthogonal and in effect more useful, because 
functions no longer need to care about and interfere with the concept of 
"multiple values".

> The first is like a "regular" function that doesn't take a tuple.
> 
> The second is a new "tuplized" function that takes a tuple. both take 
> one parameter (one version via the regular argument syntax, one via a 
> tuplized syntax).

One takes an argument that is an integer. The other takes an argument 
that is a tuple containing a single integer.

> Why is it not the same?

One takes an int while the other takes an (int,).

> Clearly a tuple of 1 can bind 
> to a single value, just like a tuple of 2 can bind to 2 values.
> ...

But it is precisely what is happening. However, not every value is a 
singleton tuple just by virtue of not being a tuple of multiple values.

> Currently, I can call this:
> 
> foo(T...)(T t) if (T.length == 1) // function that takes a single 
> element tuple
> 
> like this:
> 
> foo(1);
> 
> Why is this disallowed in your tuple scheme?
> ...

I take this to mean, why does the following code not compile:

void foo(T)(T t) if(T.length == 1) { ... }

foo(1);

This is because T is matched to int, which does not have length.

A few more examples:

void foo(int x);       // foo takes an int
void foo(int x,);      // foo takes an (int,) and matches it against 
(int x,) in order to extract the value x
void foo(int x,int y); // foo takes an (int,int) and matches it against 
(int x,int y) in order to extract the values x and y.

>> 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?
> 
> I don't understand the question.

I'm was trying to figure out what is causing the confusion. I was trying 
to appeal to symmetry to get past what seemed to be your notion that 
there is a significant difference between multiple values and a single 
tuple: If you have a function that needs to return multiple values, you 
return a single tuple. If you have a function that needs to take 
multiple values, you take a single tuple. With tuples, it is sufficient 
to return a single value, and it is also sufficient to take a single 
value as the argument.

> I would think single value tuples and 
> single values would be pretty much interchangeable.

Well, no. Otherwise 2[0] would be allowed and equal to 2. And then, what 
would [2][0] be? [2] or 2?

> It's up to the user 
> of the value whether he wants to look at it as a tuple (which has length 
> and must be indexed) vs. a single value.
> ...

A singleton tuple is like a box that contains a single value. You need 
to open the box to get at the value. Opening the box is achieved by 
matching the tuple against a tuple pattern. This is the same regardless 
of the length of the tuple.

Singleton tuples might seem pointless, and some languages do not support 
such single-element tuples, but as we want to support slicing, they 
should probably exist. (Also, we might want to create a tuple from an 
AliasSeq, which can be achieved by dropping it into a single-element 
tuple and letting it auto-expand.)

>>> 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.
>>>
>>
>> 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.
> 
> I definitely don't have an answer off hand, but I wouldn't be surprised 
> if this broke at least some code in phobos.
> ...

I guess we'll need to try.

>> 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.
> 
> This flew over my head :)
> ...

If we cannot have proper tuples, having some syntactic sugar for tuple 
unpacking during variable declaration may still be useful:

import std.typecons;

auto (x,y) = tuple(1,"2");
(int x,string y) = tuple(1,"2");

This is syntactically forward-compatible.