> That's a possible method to provide encapsulation, but it does nothing
> to address the existing issue of involuntary ABI ossification. I would
> consider this to be an implementation detail that can be left to whoever
> is implementing a public interface.


It creates a clear divide between the shared ABI and the static ABI. Things
like this are possible for example:

inline ssize_t read( int fd, void *dest, size_t size )
{
   int res = stdiocall( fd, STDCALL_FETCH, dest, &size );
   errno = (res < INT_MIN || res > INT_MIN) ? -1 : res;
   return (res != 0) ? -1 : size;
}

#ifdef EXTERN_STD_INLINES
extern ssize_t read( int fd, void *dest, size_t size );
#endif

To enable this sort of thing would have to swap the errno usage I gave in
the previous example for a separate errno, like errno32 for example.
Since errno32 would be a fixed size it can still be exposed to the public
ABI and allow transitional development from using errno to errno32, all the
while
the annoying ILP64 vs LP64 vs LLP64 crap can be left entirely to the inline
ABI. That would be the very 1st step in fixing ABI nonsense, shifting data
model crap out of the shared libraries. You can also use something like
typedef struct stdref
{
  int32_t version;
  char *name;
  void *ud;
  int32_t (*refcall)( void *ud, int32_t call, va_list va );
} stdref_t;
To internally manage different classes. If the name and version don't match
what is supported then you use only what is known across all versions.
The class keyword should be treated like the inline keyword, only ever used
on the static build part of the ABI while the shared part of the ABI
always uses the baseline C structs to keep things simple.

On Wed, 10 Jul 2024 at 14:35, Jonathan Wakely via Std-Proposals <
std-proposals_at_[hidden]> wrote:

>
>
> On Wed, 10 Jul 2024 at 09:22, Hans <hguijtra_at_[hidden]> wrote:
>
>> On 08/07/2024 17:46, Jonathan Wakely wrote:
>> > "There is great reticence to add new standard library classes"
>> >
>> > Is there? I'm not sure I want to live in a world where we add a lot
>> > /more/ classes to the standard, if what we have now is the result of
>> > great reticence!
>>
>> It is my understanding that proposals have been rejected on the basis of
>> ABI stability. If that impression is wrong, please let me know and I'll
>> remove that sentence.
>>
>
> Proposals to *change* existing classes have been rejected for reasons
> related to ABI stability. Your proposal says there is a reticence to add
> new classes to the library, which is not the same as changing existing
> classes, and I am unaware of any proposals to add *new* classes that have
> been rejected.
>
>
>
>> > The comparison with previous proposals would benefit from references to
>> > those proposals.
>>
>> I'm not sure if there were ever any papers, or if they were just ideas
>> floated in the community.
>>
>> Apart from this, what's your feeling on the idea in general?
>>
>>
>> Hans Guijt
>>
>>
>> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>