Proposal: Object/?? Destruction

[Steven Schveighoffer]

Sorry for waiting so long to respond, I had to think about this a lot...

On 10/12/17 3:05 PM, Timon Gehr wrote:
> On 10.10.2017 17:05, Steven Schveighoffer wrote:
>> On 10/9/17 11:22 AM, Timon Gehr wrote:
>>> On 09.10.2017 01:20, Steven Schveighoffer wrote:
>>>>
>>>> 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 understand why (int,) is different from int. What I meant was, why 
>> can't I *call* a function that takes a single int tuple with a single 
>> int value?
>> ...
> 
> Because this would require a special-case rule that I had not considered 
> so far. This is up to discussion though.
> 
> I interpreted your question to be: "Why do your proposed rules not lead 
> to my expected behaviour?", and not: "Why do your rules not allow 
> this?", but it seems I have misinterpreted your question. Sorry for the 
> confusion! :)

Not a problem!

>> Again, I go back to the 2-parameter version. I can call it with 2 
>> values, or a tuple of 2 values.
> 
> With the caveat that those two cases are actually identical, yes.
> 
> auto x = (1,"2"); // construct value
> f(x); // now call f with value
> 
> and
> 
> f(1,"2"); // construct tuple and call f with the resulting value
> 
> It is like:
> 
> auto x = [1,2];
> f(x);
> 
> and
> 
> f([1,2]);
> 
> Except that redundant parentheses are optional:
> f(1,"2") is exactly equivalent to f((1,"2")) after parsing.
> 
> The second expression just adds an additional pair of parentheses around 
> f. f(((1,"2"))) is also the same expression for the same reason.
> 
> Note that this does not compile:
> 
> void f(int a,int b,int c){}
> f(1,(2,3));

Right, there is a structural difference here. The 2 and 3 being tied 
together is a piece of information that is lost or different than is 
expected. I get that, and agree with it.

> 
> The reason is that I tried to call f with an argument of type 
> (int,(int,int)), while it expected an argument of type (int,int,int).
> 
>> It makes no difference to the callee how I call it, as long as I put 2 
>> values on the stack.
>> ...
> 
> Well, I think it should maybe not be possible to conflate e.g. (int,int) 
> and ((int,),(int,)).

This, I'm not 100% sure on. In my mind, the difference between a value 
and a tuple of one element is trivial and negligible. I think they 
should be implicitly convertible between each other. Perhaps they would 
still be mangled differently, but you could still call both with the 
different forms. Sort of like const(int) and int have different 
semantics, but I can call a function with one or the other.

In that sense, perhaps foo(int) and foo((int,)) are different manglings, 
but you can still call either form with either form.

>> I don't see why it should be different for a single parameter function.
>> ...
> 
> I think you are making a strong point here.
> 
>> To put it another way, in your scheme, what is the benefit to 
>> overloading a single value function call with a function call that 
>> takes a single element tuple? When would this be useful?
>> ...
> 
> I agree that this is actually not useful.
> 
> Note that this means the following code will be accepted also:
> 
> void foo(int x,int y,int z){}
> 
> foo((1,2,3),);
> 
> Does this match your expectation?

Yes, that seems reasonable to me.

> 
>>>> 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);
>>
>> Nope, I meant my original. A "tuple" as D currently uses it, can have 
>> exactly one element, and I can call that function with exactly one 
>> value. I don't have to call it as:
>>
>> AliasSeq!(int) v;
>> v[0] = 1;
>> foo(v);
>>
>> Which is analogous to your requirements (obviously, D is missing the 
>> syntax for tuple literals, which is why it's complicated).
>>
>> Note that if foo is:
>>
>> foo(int x);
>>
>> I can still call it with v. I don't see why we can't keep these kinds 
>> of allowances.
>> ...
> 
> I see. Well, we can't keep them to the extent AliasSeq has them. 
> AliasSeq always auto-expands. Auto-expansion for tuples can become a 
> problem, especially in generic code, because it forgets structure 
> information. For example:
> 
> void printElements(T)(T[] arr){
>      foreach(x;enumerate(a)){
>          print("at index ",x[0]," we have ",x[1]);
>      }
> }
> 
> auto a = [(1,2),(3,4),(5,6)];
> printElements(a);
> 
> With auto-expansion, this prints:
> at index 0, we have 1
> at index 1, we have 3
> at index 2, we have 5
> 
> However, it is quite clear from the definition of printElements that the 
> programmer wanted it to print:
> 
> at index 0, we have (1,2)
> at index 1, we have (3,4)
> at index 2, we have (5,6)
> AliasSeq does not have this specific problem, because it cannot be put 
> into an array without expanding.

Right, I was specifically focusing on what I understood -- the existing 
mechanism of "singleton tuple" in D.

But really, I think implicit expanding or tupling of values when needed 
would fix all the problems I had, fits into the current expectations of 
D users, and allows your scheme to work.

So to recap my thoughts:

1. I think T and (T,) can be different types, probably should be mangled 
differently, but implicitly cast to one another, similar to T and 
const(T) when T is a value type.
2. I'm OK with fun(T,T) and fun((T,T)) being equivalent.
3. I'm still not in love with (T,) as a singleton tuple type, it looks 
like you accidentally put in a trailing comma. But I don't have a better 
syntax to suggest.
4. I'm still convinced that having a template type match a tuple when 
multiple parameters are passed as in:

foo(T)(T t) {...}

foo(1, 2); // OK, T = (int, int)

is not going to go well with existing code.

On point 4, as a compromise, would it be possible to opt-in to such 
things via a new syntax? For example something like:

foo((T,...))(T t) // T is a tuple of 0 or more items.

One other thing, what does an empty tuple look like? Is it (,)?

-Steve