> On Dec 12, 2016, at 2:46 PM, Joe Groff <[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.
Charles
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
