[Issue 8887] static arrays passed by value in extern C/C++ functions should not compile

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=8887

--- Comment #13 from Steven Schveighoffer <schveiguy at yahoo.com> ---
(In reply to Dicebot from comment #12)
> (In reply to Steven Schveighoffer from comment #11)
> > The issue here is -- we use the non-mangling "feature" of C calls to
> > override type checking inside druntime. So even if something is extern(C) it
> > can actually be implemented in D. That function may never need to be called
> > or used in C code at all.
> 
> This is abuse and needs to be fixed. We have pragma(mangle) to override
> mangling.

I wasn't aware that we had a C mangling feature. We should change this ASAP, as
I don't like the idea of specifying C functions for the sole purpose of
escaping typechecking. If we fixed this, perhaps you have a better case for
changing this.

> http://dlang.org/attribute.html#linkage is pretty clear on legitimate use
> cases this feature was designed for.

I don't think that's an exhaustive list of the uses. It only identifies one use
-- calling existing C or C++ functions. But it can also be used to *implement*
functions that are called from C (or D) code. When you implement an extern(C)
function in D code, how should it treat a static array parameter? I think it
would be more confusing to have this be different based on the extern(C).

> > Why shouldn't D support ref for C? All it is doing is auto-taking the
> > address of the parameter, which maps perfectly to accepting a pointer or
> > array argument.
> 
> Exactly because it is special case - it takes a language feature that does
> not have clear mapping to C feature and makes use of ABI details to work it
> as-is. It is not bad on its own but quite puzzling.

ref is sort of a weird thing to begin with. It automatically takes the address
of the parameter, and passes that to the function, then the function
dereferences it at every use. It's syntax sugar more than a storage class. And
it extends beyond the ABI, because the entire function has to deal with it.

> > As another example, on a 32-bit system, C's long is 32-bit. But D's long is
> > 64 bit. What to do here?
> > 
> > extern(C) foo(long x);
> 
> Ideally this should use C interpretation too but I recognize how it is
> totally impractical. This is not the case for static array arguments.

I see it as very similar. Two different interpretations of the same type
keyword, in one language you have to tweak it a bit to fit the other,
intransigent, existing language.

> You call tweaking own code (that makes use of undefined language area) to
> address compiler regression a right move?

It's not a regression if the breakage is intentional. It was not an accident
that the compiler changed static arrays from being passed by reference to
passed by value.

--