Hi Christoffer,

Thanks for your feedback.


> On Aug 11, 2025, at 5:26 AM, Christoffer Lernö via Liaison <liaison_at_[hidden]> wrote:
>
> Although the dependent attributes address a very real problem, it’s still piling complexity upon complexity, and tries to circumvent the need for an actual language change by pushing it as an attribute. I can easily see this feature being adopted by some compilers to enhance diagnostics of core OS libraries BUT, the cost is that the code will look more opaque and hard to read.
>
> Looking at the concrete examples, it’s about solving solving things like
>
> 1. The lack of slices
> 2. The missing ability to express ownership / threading semantics
>
> BUT If the lack of slices is important enough to warrant the changes needed for dependent attributes – shouldn’t then slices be a full fledged feature? That would allow regular user code actually use such slices and leverage much more than just some security checks.
>
> And if OWNERSHIP is important enough to warrant the changes needed for dependent attributes, shouldn’t then OWNERSHIP be a full fledged feature?
>
> It will be slower to migrate to such full-fledged solutions, but isn’t it immensely more valuable?

Can we do both? I agree that full-fledged solutions for slices and ownership in C would be ideal, but as you rightly pointed out, such language changes take considerable time to design, standardize, and deploy. In the meantime, we have an urgent need to make existing C code safer—and that work is already underway.

The bounds and lifetime annotations are actively being adopted in security-critical codebases today. For example, the Linux kernel has been adopting bounds annotations for enhanced safety checking. However, progress has been hampered by the lack of struct scope and forward referencing features, which is exactly what this proposal aims to address.

>
> TLDR; If dependent attributes are added, then it looks like the functionality will see limited use outside of libraries, but if this functionality is added to C, then it seems like they are even better as full-fledged features that ordinary users will use.

I’m not sure why you assume the functionality will see limited use outside of libraries. Can you elaborate more?

In practice, we're seeing interest in these annotations from various types of codebases—operating systems, embedded systems, network services, and security-critical applications. We've already successfully adopted the bounds safety features in a significant amount of such codebases inside Apple. Any codebase where memory safety matters (which is increasingly all of them) can benefit from these features, not just traditional libraries.


>
> Best Regards,
>
> Christoffer
> _______________________________________________
> Liaison mailing list
> Liaison_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison
> Link to this post: http://lists.isocpp.org/liaison/2025/08/1564.php

Best regards,
Yeoul