mirror of
https://github.com/apple/swift.git
synced 2026-10-18 17:49:23 +02:00
John McCall
4cd6d3e915
We're going to add scope arguments to nominal types. Following the lead of the current representation and splitting the class hierarchy would be a disaster --- we'd end up with four different classes for nominal types. And even adding them separately for the classes we have would be pretty annoying. But the real underlying problem is that the split we've got in the current representation between nominal and bound-generic types has never made much sense. It's not that the existence of generic arguments isn't important, but the split makes it *more* important than it deserves to be. Most code should work uniformly on nominal types whether they have generic arguments or not. When code does care about the presence of generic arguments, it's usually interested in whether the type is specialized *at all*, which types without generic arguments can still be because of their parent types. In this patch, I've tried to stay focused on the representation change and not mess around with the underlying logic. That means I've left uses of hasGenericArgs() in various conditions where I couldn't easily just unify the BoundGeneric and Nominal paths. Most of these are questionable and should probably be replaced with is-specialized checks. There's also quite a lot of code that continues to ignore parent types and should probably be walking substitution maps instead. The unconditional addition of a FoldingSetNode to all NominalTypes is not as efficient as it could be. If we decide to do something about this, we could easily add hidden subclasses of EnumType, StructType, and ClassType that support trailing storage, then just unique the simple cases with a DenseMap like we do now. However, I don't know that this is worthwhile, for the simple reason that nominal types without any other structure are necessarily unique per declaration --- eliminating a few bytes from these objects might save a few dozen kilobytes, but that might not be worth the complexity. It's the specialized types that we might end up generating at any number of specializations that it'd be better to save space in.