Hi Jan,
on which level would this work? Linker level? Or compiler level, e.g. inline functions / templates?
Your example shows annotated declarations, so I would think about linker level.
I don't see how you would enforce this at the linker level easily without some advanced tech like linker scripts. How would the linker emit a warning (with correct location in C++ source code) telling you you're missing an [[opt_in]] annotation?
I think this would need to operate in the C++ compiler frontend, which also makes it possible to provide opt-in requirements for e.g. type aliases and other things that don't actually exist at the linker level. The idea is simply that if the compiler sees that if name lookup finds a declaration with [[requires_opt_in]] and you are not in a context where you're opting in, you get a warning.
Would the feature be transitive. A function opting in and using an e.g. 'unstable-stuff' function would itself require it from callers?
I don't think [[opt_in]] could be transitive because that seems like it would bubble up all the way to main. However, Kotlin does let you annotate your own stuff with the same opt-in requirement as the opt-in-requiring API, so you can also put @ExperimentalStuff on your own declarations, and that's basically a transitive opt-in. Maybe that could be a feature for the C++ counterpart. That is, you could either opt-in, or repeat the existing opt-in requirement.