On Thu, 14 May 2020 at 19:10, Hubert Tong
<hubert.reinterpretcast_at_[hidden]> wrote:

>> 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.)
>
> I work in the vicinity of such an implementation. The cost to removing (1) is non-zero for "C" language linkage, and I am not sufficiently familiar with the nuances of the implementation to know how expensive migrating code would be if a change was made from the status quo in the standard. Removing (1) for other language linkages, of which the implementation supports several, is a non-starter. In particular, the implementation does use language linkage to indicate differences in calling convention, and interfacing with code implemented with different calling conventions is common in the context of the platform (due to a large body of non-C system APIs and object-code-only libraries built against older ABI levels).

Oh hai, xlc++. I'm not convinced it's a non-starter, you'd just need
to have extensions or non-conforming functionality
rather than be supported by what the standard says. I often wonder why
that's so outrageous that we need to keep
supporting every variation everywhere, and then very reasonable
programs are claimed ill-formed or UB by the standard
when that's only a case for a particular slice of the portability
spectrum, without making any claims about what
the size of that slice is.

I'm fine with conditionally-supported. It's better than claiming that
a reasonable implementation can't allow taking the address
of an extern "C" function and using it like a pointer to a function.
And for those poor souls who need to also target the
implementations where that doesn't work, the work-around of a wrapper
lambda is available.