On Friday, 31 January 2020 at 02:29:15 UTC, Walter Bright wrote:
> On 1/30/2020 4:39 AM, Seb wrote:
>> Structs are essentially just fancy tuples and look the same when stored in memory.
>
> I've wanted to make tuples<=>structs. Here's the big problem - passing them as function parameters.
>
> It just doesn't work and be compatible with the C ABI.

Could you clarify the problem?  If you have a C function like pow:

extern (C) double pow(double,double);

Is the problem providing a way to call pow with one symbol?

pow(s);

So that's why D hasn't been able to unify structs/tuples? Because tuples auto-expand and structs do not?

On Friday, 31 January 2020 at 02:29:15 UTC, Walter Bright wrote:
> On 1/30/2020 4:39 AM, Seb wrote:
>> Structs are essentially just fancy tuples and look the same when stored in memory.
>
> I've wanted to make tuples<=>structs. Here's the big problem - passing them as function parameters.
>
> It just doesn't work and be compatible with the C ABI.

As mentioned earlier and by others: there are still two options (even without a solution for this) that would solve the C ABI problem. I'm failing to understand why they wouldn't work:

1) There are only a handful of C functions that would be able to receive this tuple (the printf family). Why can't we add an overload for them?

2) If (1) isn't an option, wouldn't printf(i"interpolated ...".c) work?

On 1/31/2020 3:37 AM, Jonathan Marler wrote:
> On Friday, 31 January 2020 at 02:29:15 UTC, Walter Bright wrote:
>> It just doesn't work and be compatible with the C ABI.
> 
> Could you clarify the problem?

If you have a C function:

   void foo(char a, char b, char c);

and pass it a:

   struct S { char a, b, c; }

it won't be passed the same way.

On 1/31/2020 6:46 AM, Seb wrote:
> As mentioned earlier and by others: there are still two options (even without a solution for this) that would solve the C ABI problem. I'm failing to understand why they wouldn't work:
> 
> 1) There are only a handful of C functions that would be able to receive this tuple (the printf family). Why can't we add an overload for them?

Then they aren't really printf? C functions aren't overloadable?


> 2) If (1) isn't an option, wouldn't printf(i"interpolated ...".c) work?

structs and tuples aren't interchangeable if you have to remember to do things like that.

On Sunday, 2 February 2020 at 07:23:31 UTC, Walter Bright wrote:
>> 2) If (1) isn't an option, wouldn't printf(i"interpolated ...".c) work?
>
> structs and tuples aren't interchangeable if you have to remember to do things like that.

You don't really have to remember per se because you'll get a type mismatch error if you don't do it. The compiler error message could even recognize it and remind you in the error message to use the method.

Will you sacrifice all the other use cases in their entirety just because `printf(i"".c)` is not 100% identical to `printf(i"")`? I don't see the logic in that. D is an all purpose language, not syntax sugar over C.

On 02.02.20 15:11, Adam D. Ruppe wrote:
> On Sunday, 2 February 2020 at 07:23:31 UTC, Walter Bright wrote:
>>> 2) If (1) isn't an option, wouldn't printf(i"interpolated ...".c) work?
>>
>> structs and tuples aren't interchangeable if you have to remember to do things like that.
> 
> You don't really have to remember per se because you'll get a type mismatch error if you don't do it. The compiler error message could even recognize it and remind you in the error message to use the method.
> 
> Will you sacrifice all the other use cases in their entirety just because `printf(i"".c)` is not 100% identical to `printf(i"")`? I don't see the logic in that. D is an all purpose language, not syntax sugar over C.

This is a use case for `alias this`, the language just has to support it.

On Sunday, 2 February 2020 at 14:20:16 UTC, Timon Gehr wrote:
> This is a use case for `alias this`, the language just has to support it.

Indeed.

So is

string s = i"";

so idk which one we'd use (unless the language gets multiple alias this lol).

But regardless the struct lets us have it all. With alias this it is every minor detail. Without it it is a simple method call.

I used to lukewarm support this DIP, but since the struct is so much better, superior in almost every objective measure, I now think we should vote it down unless it changes.

On Sunday, 2 February 2020 at 14:29:17 UTC, Adam D. Ruppe wrote:
> On Sunday, 2 February 2020 at 14:20:16 UTC, Timon Gehr wrote:
>> This is a use case for `alias this`, the language just has to support it.
>
> Indeed.
>
> So is
>
> string s = i"";
>
> so idk which one we'd use (unless the language gets multiple alias this lol).
>

Implict conversion to string would trigger allocations! This is not an option, allocations has to be explict. However alias this to tuple is fine by me.

On Sunday, 2 February 2020 at 15:31:46 UTC, Tove wrote:

> Implict conversion to string would trigger allocations! This is not an option

D is a GC language.

On Sunday, 2 February 2020 at 15:31:46 UTC, Tove wrote:
> Implict conversion to string would trigger allocations! This is not an option, allocations has to be explict. However alias this to tuple is fine by me.

The GC is usually opt-in. Having this in feature in @gc code would be better than not having it at all.