The real experience so far is the cake source itself.

Not sure I agree with that premise as the cake source would have been written in a way to be compatible with ownership annotations from the get go vs retrofitting an existing codebase. Help me understand how something like this composes:

    FILE* open_file(const char* p) {
        FILE* owner f = …
        return f;
    }

Now open_file callers would need to know that ownership is being returned which means that local variables would need to have the owner annotation propagated. That’s what I mean when I say it’s not composable - the ownership has to propagate fully throughout the codebase for a specific resource. Of course maybe you know better as this is just an initial glimpse on my part.

This code will not compile because we cannot return owner as non owner.

To fix we need to add qualifier owner at return type.

    FILE* owner open_file(const char* p) {
        FILE* owner f = …
        return f;
    }

Then when returning f , f is moved. Because f was moved the compiler will not complain at the end of scope of f.

https://thradams.com/cake/playground.html?code=I2luY2x1ZGUgP...

Not sure if I understood. the usage of old and new (checked and unchecked) is a challenge.We may have the same headers used in both codes. The other challenging is that same source may compile in compiler with or without support.

Ownership Feature Strategy (Inspired by stdbool.h)

If the compiler supports ownership checks and qualifiers such as _Owner, _View, _Obj_view, etc., it must define __STDC_OWNERSHIP__.

However, even if the compiler implements ownership, it is not active by default. The objective is to have a smooth transition allowing some files without checks. For instance, a thirty part code inside your project.

For instance, when compiling this file, even if the compiler supports ownership we don't have errors or warnings because the checks are not enabled by default.

    #include <stdlib.h>

    int main() {
      void \* p = malloc(1);
    }

A second define __OWNERSHIP_H__, is used to enable ownership. This define is set when we include <ownership.h> at beginning.

    #include <ownership.h>
    #include <stdlib.h>

    int main() {
      void \* p = malloc(1); //error: missing owner qualifier
    }

The other advantage of having a <ownership.h> is because owner is a macro that can be defined as empty in case the compiler does not support ownership, allowing the same code to be compiled in compilers without ownership support.

To me ownership composability means you can express ownership locally without it infecting anything outside of that local scope. However, ownership is not always tied to lexical scope and in those cases it doesn’t compose. In other words, you can add all the annotations you want locally and a) the code will still be incorrect b) the code may not compile as you show in your other snippet because now the function signature needs to contain the ownership sigil which then results in all callers needing the ownership sigil. Disabling it partially only emulates composition if the callers are in external files compiled with alternate options / skipping ownership validation. If you have local calls to the newly annotated function, you’ll be back into needing to fix the entire file’s annotations.

Unless I misunderstood what OP meant about ownership composition.