Proposal: Object/?? Destruction

Steven Schveighoffer schveiguy at yahoo.com
Tue Oct 10 15:05:43 UTC 2017


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?

It shouldn't matter to the caller whether you plan to fiddle with your 
parameter via tuple syntax or directly with a value.

Again, I go back to the 2-parameter version. I can call it with 2 
values, or a tuple of 2 values. It makes no difference to the callee how 
I call it, as long as I put 2 values on the stack.

I don't see why it should be different for a single parameter function.

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?

>> 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 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?

Not interchangeable in terms of usage, but interchangeable in terms of 
overloading.

What I would have expected is for foo(int) and foo((int,)) to be 
equivalent mangling (like the bar(int, int) and bar((int, int)) are 
equivalent), and for the caller to be able to call those functions with 
either a single value or a singleton tuple.

Inside the function, of course, they are treated differently as the 
callee decides whether to unpack the tuple or not via the parameters.

>>> 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.

OK, this makes sense, yes.

-Steve


More information about the Digitalmars-d mailing list