On 19 October 2024 16:36:31 UTC, Lauri Vasama via Std-Discussion <std-discussion_at_[hidden]> wrote:
>It doesn't matter if the feature is implementable on multiple platforms. When someone in the room points to a platform where it is not implementable, that's it. Arguably even Linux is one such platform, because the single array interface cannot support dynamic linking. Windows is simpler, because there is no expectation of automatic linking across modules. The standard doesn't define dynamic linking, but neither does it define static linking. The standard is concerned with implementability, and like it or not, dynamic linking is part of that.
>
>Yes, supporting dynamic linking makes the interface somewhat more complex, but in the common cases on many platforms you will just end up with a single array in that linked list of arrays.
>
>On 18/10/2024 20.51, Federico Kircheis via Std-Discussion wrote:
>> On 18/10/2024 16.30, Lauri Vasama via Std-Discussion wrote:
>>> P2889 was discussed in Varna. The reception was favourable
>>
>>
>> Hello Lauri,
>>
>> thank you for the feedback
>>
>>
>>> but EWGI wanted to support dynamic linking, which I did not initially propose.
>>
>> Sounds "interesting", because the standard is not concerned with static/dynamic linking...
>>
>>
>>> To do this requires something like linked lists, but a hybrid approach is possible. Instead of linking individual elements, the implementation can choose to merge multiple elements into arrays and to serve a linked list of arrays to the user. In practice most of the time all elements can be placed into a single array, but implementability on more constrained platforms may require a linked list of arrays or even a linked list of individual elements.
>>>
>>> Currently the main thing needed to advance this proposal is an implementation. I have a partial one in Clang, but haven't had much time to work on it recently.
>>
>>
>> Too bad, this new requirement seems to make the feature much more complex than required.
>>
>> I just read the minutes, and am confused about the feedback...
>>
>> Maybe the audience believed that something novel would be better than what we already have through compiler extensions?
>>
>> The existing practice already has two (gcc, clang) and a half (msvc, because of those gaps between elements) implementations in the wild, all used by multiple projects.
>>
>> Thus we already know that
>>
>> * it is useful
>> * it is implementable on multiple platforms
>> * it will simplify existing code taking advantage of newer c++ standard
>>
>> and since how dynamic linking work is implementation defined, if an implementation can merge those arrays together (as someone pointed out in this mailing list), it is even possible to standardize the current practice and try to improve it later.
>>
>> I guess that one implementation exposing the array and size (or a couple of pointers, an initializer_list, a span, or something else) is still desired, even for proposing the status quo with a better interface.
>> I suppose the amount of work is, compared to support dynamic linking, negligible.
>>

The linux kernel itself uses this feature... what do you mean that it does not work?

GCC and clang supports it on Linux systems...

Dynamic linking is implementation defined, I do not see why it is a big issue.

Dynamic kinking already breaks multiple guarantees from the standard; for example that function pointers are always valid, and many things that have to do with global objects, I personally do not see why this array should be treated differently