API stability support

[lerno]

API stability – dynamic libraries (esp OS ones) being able to be both backwards and forwards compatible is an important consideration.

Some things that potentially break the API:

1. Function signature changes and availability
2. Changes to struct/union size or alignment
3. Struct/union internal member ordering and availability
4. Enum values

Note that C3 is stable under error changes.

[lerno]

Mitigating 1:

• Multiple functions for the same function
• Hiding function availability behind macros
• ObjC style dynamic dispatch
• ObjC style runtime availability requests

Mitigating 2:

• Structs only available by pointer

Mitigating 3:

• Structs only available by pointer
• Opaque pointer
• "accessor" style access of members

Mitigating 4:

• Enum aliases (e.g. FOO = 3, BAR = FOO)
• Each enum directly defined rather than implicitly
• Using constants rather than enums

[lerno]

Feature:

fn void foo() @dynamic;

Can be checked if it is available, and called if it is:

fn void test()
{
   if (foo.available) foo();
}

[lerno]

Roughly this is what it could have been in C:

extern int fooNewFunction(void) __attribute__((dynamic));
int test()
{
   if (!__exists(fooNewFunction)) return -1;
   fooNewFunction();
}

Under the covers this is added to the client code:

int fooNewFunction(void) { panic(); } __attribute__((noinline) __attribute__((weak));
bool __fooNewFunctionExists __attribute__((weak)) = false ;

[lerno]

Implemented dynamic calls.