> On Dec 12, 2017, at 2:29 PM, Jordan Rose <jordan_r...@apple.com> wrote:
>
>
>
>> On Dec 12, 2017, at 14:15, Douglas Gregor via swift-dev <swift-dev@swift.org
>> <mailto:swift-dev@swift.org>> wrote:
>>
>>
>>
>>> On Dec 10, 2017, at 4:47 PM, Brent Royal-Gordon <br...@architechies.com
>>> <mailto:br...@architechies.com>> wrote:
>>>
>>>> On Dec 5, 2017, at 2:28 PM, Douglas Gregor via swift-dev
>>>> <swift-dev@swift.org <mailto:swift-dev@swift.org>> 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
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
