> On Dec 12, 2017, at 2:29 PM, Jordan Rose <[email protected]> wrote:
>
>
>
>> On Dec 12, 2017, at 14:15, Douglas Gregor via swift-dev <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>>
>>
>>> On Dec 10, 2017, at 4:47 PM, Brent Royal-Gordon <[email protected]
>>> <mailto:[email protected]>> wrote:
>>>
>>>> On Dec 5, 2017, at 2:28 PM, Douglas Gregor via swift-dev
>>>> <[email protected] <mailto:[email protected]>> wrote:
>>>>
>>>> To perform that mapping from a mangled type in a conditional requirement
>>>> to type metadata, we effectively need an operation to take a mangled type
>>>> name and turn it into a type metadata pointer. This is something we could
>>>> surface in the Swift standard library/runtime as, e.g.,
>>>>
>>>> func type(named: String) -> Any.Type?
>>>>
>>>> to take a mangled type name and try to get the type metadata for it. From
>>>> there, one can query protocol conformances that (say) allow one to
>>>> construct instances of the arbitrarily-named type. Think of it as
>>>> NSClassFromString for any type in the Swift language, including
>>>> specializations of generic types.
>>>
>>>
>>> It's worth noting here that the standard library already provides a limited
>>> `_typeByName(_:)` function for Corelibs Foundation to use. That function
>>> will presumably become part of the ABI unless we design a public version in
>>> Swift 5.
>>
>>
>> Woah. That’s kinda awful… it parses “Foo.Bar” as a class name and looks for
>> class Bar in module Foo.
>
> Needed to implement NSCoding on Linux. They did limit it to "Foo.Bar" at
> least, deliberately excluding anything more complicated.
Makes sense. A type(named:) would serve their use case better, of course.
- Doug
_______________________________________________
swift-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-dev
