> On May 14, 2020, at 1:46 PM, Richard Smith <richardsmith_at_[hidden]> wrote:
>
> On Thu, 14 May 2020, 09:57 David Vandevoorde, <daveed_at_[hidden] <mailto:daveed_at_[hidden]>> wrote:
>
>
>> On May 14, 2020, at 4:00 AM, Richard Smith via SG12 <sg12_at_[hidden] <mailto:sg12_at_[hidden]>> wrote:
>>
> [ About language linkage being part of function types…]
>> I hope someone who maintains an implementation for such a target will speak up. (I think someone did when this was last asked, though, so I don't think this is a theoretical or legacy concern. I'd be very happy to be wrong about that.)
>
> Our front end can be configured in this respect:
> - Whether C and C++ language linkage function types are distinct
> - If they are not distinct, whether they can be implicitly converted from one to another
> (and some added configurability to decide whether those implicit conversions are
> enabled by default or require a command-line option)
>
> For those customers who have shared they configurations with us, most appear to keep the types distinct but allow implicit conversions between them. So the following example is accepted:
>
> $ cat -> r.cpp
> extern "C" typedef int F(void);
> extern "C++" typedef int FPP(void);
>
> constexpr int g(F) { return 1; }
> constexpr int g(FPP) { return 2; };
>
> F f;
> FPP fpp;
> F *pf = fpp;
>
> static_assert(g(f) == 1);
> static_assert(g(fpp) == 2);
> $ ./cfe --c++20 r.cpp
> $
>
> (The “major” implementations would complain g has a duplicate definition.)
>
> So, if we want to make all known implementations conforming, we would need to make both (1) and (2) conditionally supported. Right?

Probably. That said, none of the configuration files I had access to made types distinct and disallowed conversions. I.e., either language linkage did not affect function types, or they did but you could convert pointers to C-functions to pointers to C++-functions (and v.v.; suggesting that it’s only a type system feature, not a calling convention feature). (But to be sure, the configurations I checked do not represent all our customers.)

> I'd be less happy with that than with making only one of the two options conditionally-supported, but maybe it's the right choice, given that changing only (2) would require an ABI break for major implementations to conform, and changing only (1) would be a source-level break for Daveed's customers described above -- that is, for the people who were trying to follow our rules as best as they could even though their C and C++ functions had the same calling convention.
>
> (Also, it sounds like there are not just one or two targets like this, given Hubert's report and Daveed's multiple customers. I'm guessing the latter implementations are things like processor-specific compilers in the embedded space or similar, which I think generally have less representation on the committee.)

Right.

> Now we have "Recommended behavior" as a tool, we could make (1) conditionally supported, with a recommendation that C language linkage result in the same type as C++ language linkage, and make (2) conditionally supported, with a recommendation to allow conversion if the calling convention would be the same (for those that didn't follow our first recommendation).

That sounds reasonable to me.

 Daveed