> On Dec 6, 2017, at 10:00 PM, John McCall <rjmcc...@apple.com> wrote: > > Yes, I can see how there's some nice synergy there, and it would certainly be > good to avoid having to eagerly generate code for this operation. And it > should be possible to optimize the cast operation in the runtime if we find > ourselves executing it many times for different types. > > Okay, the basic idea seems reasonable to me. I guess my biggest concern is > the use of just mangled names, since it seems like that will pose a lot of > problems with private or local types.
As long as we mangle the unique private or local discriminator prefix, it shouldn’t be a problem. We’re not looking up global symbols by name, but scanning some kind of metadata section in the binary, which would presumably still have metadata for private and local types. > When Ashley was working on the remote-mirrors metadata, we had the idea of > using descriptor "strings" that could embed a reference to a nominal type > descriptor (or something like that) instead of just relying on a name. (A > name would still be reasonable for a type that's not known to be defined > within the linkage unit, of course.) Yes, this would be a useful optimization, but I don’t think it’s a pre-requisite for getting an initial implementation going before the ABI is finalized. > In AST terms: > func matchEnvironment(GenericSignature, Type, TypeMetadata) -> > GenericEnvironment? > func substitute(GenericEnvironment, Type) -> TypeMetadata? By GenericEnvironment do you really mean a substitution map? Slava _______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
