I have a branch that adds 3 flags to TypeResolutionFlags and leaves 2 bits free in the type. The "fullness" of the type will eventually become a distraction and I'd like to make the situation better for people experimenting with Swift. Would people object to expanding top-of-tree TypeResolutionFlags to 64 bits? If not, can we refactor some of the existing flags into the flags that my branch adds? For the record, my branch adds the following:
I'd be interested to know why specifically you want to add more flags. I tried looking for the branch you mentioned but it doesn't appear it's published to Github yet.
I've extended the type system in a private research branch and I need to control how the new types surface in the language, therefore TypeResolutionFlags seemed reasonable.
For the sake of discussion, imagine that "escapability" were a part of the formal type system and not a flag on AnyFunctionType. (This is not what I've implemented but the comparison is sufficient.) If this idea was implemented, one would need to control when/how "escapability" is exposed in the formal language. For example, trying to coerce a non-escaping class instance into an escaping instance would need to error. Similarly, returning a non-escaping class instance is arguably wrong too.
In any case, my goal with this topic is to see if any of the existing TypeResolutionFlags can be refactored into a union of more primitive flags (perhaps with the flags I need/want). If not, I might proactively create a pull request to make the 32- to 64-bit overflow scenario less painful to private research branches.
In general, any reduction in the number and kind of TypeResolutionFlags is always a good thing. For example the VariadicFunctionInput flag can probably be removed. I suspect it's only there to support the old @escaping propagation hack. @Michael_Ilseman can probably speak to that (if he remembers why anymore).