> On Dec 12, 2016, at 2:09 PM, Joe Groff via swift-evolution
> <[email protected]> wrote:
>
>
>> On Dec 12, 2016, at 12:59 PM, Charles Srstka <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>>> On Dec 12, 2016, at 2:46 PM, Joe Groff <[email protected]
>>> <mailto:[email protected]>> wrote:
>>>
>>> Everything *can* be bridged to an object as a result of SE-0116
>>> ("id-as-Any"), so there's no longer such a thing as a "non-bridgable value
>>> type”.
>>
>> Ah, so that arbitrary Swift types can be stashed in Objective-C userInfo
>> dictionaries and the like. Of course. Still wish this could have just
>> happened at the bridge, as part of whatever magic converts Arrays to
>> NSArrays, Dictionaries to NSDictionaries, etc. Oh well.
>>
>>> #6 is a bug, since the AnyObject method lookup ought to produce `nil` if
>>> the ObjC method isn't implemented on the object.
>>
>> Good to know that it’s a bug. Hopefully it’ll get fixed in a future release
>> (or at least warn if the ? isn’t before the parens).
>>
>> By the way, while we’re at it, I managed to find a way to get the property
>> version to crash by leaving out some question marks, as well:
>>
>> print((s as AnyObject).foo as Any) // fatal error: unexpectedly found nil
>> while unwrapping an Optional value
>>
>> Interestingly, it works in the context of string interpolation. 'print("\((s
>> as AnyObject).foo)”)’ prints nil, just like you’d expect. It’s just when you
>> pass it straight to print that the crash happens. Once again, the compiler
>> doesn’t give us any kind of warning about this.
>>
>>>> 2. Why is there no obvious way to figure out whether something can
>>>> actually be an object? The already kind of non-obvious “type(of: s) is
>>>> AnyObject.Type” trick works to tell you if the thing is already a class,
>>>> but not if something is bridgeable to a class; using it on a string, for
>>>> example, returns false. And trying something like “type(of: s as
>>>> AnyObject) is AnyObject.Type” returns true (?!), so that doesn’t work to
>>>> detect bridgeable things.
>>>
>>> What are you trying to do that requires you to know whether something is a
>>> class or bridgable to a class (which, as mentioned above, includes
>>> everything)?
>>
>> The immediate use case? Avoiding the crash on #6. ;-) At least there turned
>> out to be a workaround on that.
>>
>> Beyond that? Making the whole thing less head-hurtingly complicated, and
>> avoiding random crashing bugs popping up due to the difficulty of completely
>> reasoning about how the whole thing works. But I was a fan of the lamentably
>> departed SE-0083, so grumble, grumble.
>
> Yeah, it would be nice if we could revisit SE-0083. I think it's still doable
> in a way that could localize the dynamic bridging complexity to Anys that
> were sourced from Objective-C.
>
> -Joe
+1 Perhaps adding a way to specify “bridgeability” e.g.
struct S : AutoBridged {}
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
