On Saturday, 30 January 2021 at 07:27:16 UTC, Jacob Carlborg wrote:
> On 2021-01-27 19:25, Max Haughton wrote:
>
>> Struct ABI can mean overhead in places you don't expect
>
> If proper tuples are built-in to the language the language can invent its own ABI for that type. Just like it does for arrays and delegates.
>
> On the other hand, there are a bunch of existing C functions that encodes out parameter as pointers.

Totally expected. "out" and "ref" parameters in a backend are pointers.
In a front end it's "just" an abstraction that allows special checks, typically : 1. accepts only lvalues and 2. dont try implicit conversions.
In addition for "out" it adds a zeroinit before the call since as it's a kind of return it must be defined even if not modified by the callee.

On Thursday, 28 January 2021 at 09:17:47 UTC, Dukc wrote:
> int f(out int, int);
>
> int func()
> {  out int x;
>    if(someCond) x.f(0);
>    else if(someOtherCond) x.f(1);
>    return x;
> }
>
> What should the compiler do? It cannot know whether it's possible x can be returned uninitialized. It can issue an error just in case, and we hate to refactor code due to false alarms like that.

Exactly this. Something similar is true for an immutable constructor:

struct S
{
    int a;
    this(int x) immutable
    {
        if (x < 0) { a = 1; }
        else if (x > 0) { a = 2; }
        if (x == 0) a = 3; // error
    }
}

This problem is inherent.