Hi Tom,

On 5/5/23 08:26, Tom Honermann via Std-Proposals wrote:
> On 5/4/23 8:07 PM, Alejandro Colomar wrote:
>>>> Like I don't see a reason requiring inline functions to have the same
>>>> body - regardless of the statement above.
>>> Taking the address of a (inline or otherwise) function in one
>>> translation unit must produce a pointer equivalent to that produced in
>>> another translation unit; they must both point to the same function.
>>> Thus, you can't have different implementations in different translation
>>> units.
>> I don't remember all the details of C++'s inline (and they were always
>> blurry to me, compared to the clear model of C, where the programmer
>> has more control/understanding of what happens), but IIRC, each TU that
>> sees the inline function _and_ has a use that's not inlined emits a weak
>> symbol, so that the linker chooses one of them.
> Yes, that is a common implementation strategy.
>> However, as long as the contents are reasonably compatible, I don't see
>> why it would be problematic. Requiring a token-per-token copy probably
>> was more preventing programmers doing stupid things than a real need.
>>
>> Maybe unspecified behavior instead of undefined behavior could be
>> reasonable.
>
> Not from the point of the standard since defining "reasonably
> compatible" would be ... challenging. Also, unspecified behavior is
> usually used within the standard to allow an implementation to select
> from a set of options.
>
> What problem would be solved by changing the standard? What would you be
> able to do that you can't do today?

No, I don't really have any problems with it, and am not asking for a
change in the standard. I was wanted to understand why C++ needs to
make undefined behavior some things that are well-defined in C, since
normally it's the other way around.

Cheers,
Alex