Can we autogenerate a SAFE high-level projection? How good of one?

[contextfree]

• Is COM/WinRT's reference counting enough to satisfy Rust's notion of memory safety? If so, how can we convince the compiler of this?
• WinRT's "agile objects" and MTA-compatible objects (both declared in metadata) seem like an equivalent to Rust's Send and Share traits - can the projection rely on objects declared with this metadata to follow the rules of these traits or are there gotchas?
• WinRT unfortunately doesn't have any explicit concept of immutability, which limits the usefulness of an autogenerated safe projection. My only idea here is that property getters might be reasonably assumed to satisfy "external immutability" and therefore be safely usable by read-only references. Can this be relied on in practice?
• WinRT doesn't support non-nullable references either. Will we have to wrap everything in an option?
• How damaging would it be to have a generator that relies on metadata "promises" that <100% of APIs keep? Can we whitelist or blacklist APIs from a safe autogen'd projection? How would poorly behaving APIs be discovered, or well behaving APIs be vetted?
• If we do implement a safe high-level projection, should it + the unsafe low-level one be the only two, or should we provide an unsafe high-level projection as well?

[Boddlnagg]

I will first comment on this point:

If we do implement a safe high-level projection, should it + the unsafe low-level one be the only two, or should we provide an unsafe high-level projection as well?

I would try to make the low-level projection as high-level as possible, so that there is no need for another unsafe projection in between. I think that mechanisms such as ComPtr and HString from #3 can grow to a degree that working with the low-level projection is sufficiently "pleasant" and does not require too much boilerplate code.

Regarding the other points: I don't have much experience with the semantics and usage of the WinRT APIs. Your ideas sound valid, but the APIs need to be reviewed extensively and I guess that a manually generated API could be much better. E.g. when the documentation states that references can not be null at some point and this can not be extracted from the metadata. Errors are another area where the documentation would allow for a much more precise API definition, since all error types that might occur for a given method call are documented, but this information is not available in the metadata.

This point you made is really a key issue:

How would poorly behaving APIs be discovered, or well behaving APIs be vetted?

As long as we can't guarantee that the "safe" auto-generated APIs are truly safe, they are of no use.

In conclusion, to me the best way forward seems to be: Create a low-level API that is as high-level and as safe as possible (but of course marked as unsafe wherever we can't make guarantees). Everything beyond that will probably need a lot of experimentation and reviewing of APIs case-by-case. We might still be able to autegenerate something, but we may not only need to whitelist/blacklist APIs, but also add additional metadata extracted from the documentation (such as error information) that is not available from the WinMD files.