> On Mar 23, 2016, at 3:45 PM, Joseph Pamer <[email protected]> wrote:
>
>
>> On Mar 23, 2016, at 11:29 AM, Jordan Rose <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> The most common use case I've seen for this has been drilling into a
>> heterogeneous collection without specifying intermediate types, i.e.
>> `pluginProperties["actions"][0]["name"]`. Some possible variations on this
>> proposal could continue to allow that:
>>
>> - Remove all lookup except the subscripts `(AnyObject) -> AnyObject?` and
>> `(Int) -> AnyObject`.
>> - Instead of removing AnyObject lookup completely (the proposal), change the
>> IUO-wrapped results (the current behavior) to use Optional, requiring
>> developers to explicitly deal with the possibility of failure.
>> - Both of the above.
>>
>> I know Joe Pamer has been looking into seeing how this feature is used by
>> introducing a warning for it in the type checker. Before making any changes
>> here we'd want to know how it affects real-world projects.
>
> I should be pushing a branch that does both of the above “real soon now”.
> (This branch also includes my recent experiments in inhibiting implicit
> bridging conversions.) I’ll be curious to know what people think once they’ve
> had a chance to play with these changes.
>
> Thanks!
> - Joe
>
Good to hear! Is this change going to make this work on linux/etc so that
behavior is consistent on all platforms too?
If it turns out that it's not practical to remove this behavior outright, what
if we move the behavior to a new type that has this expectation built in,
perhaps `ObjcObject` or something similar? If the importer keeps every use of
`id` from objective-c imported as AnyObject, then a developer could opt-in to
this behavior by casting to ObjcObject explicitly:
for thing in things {
(thing as ObjcObject).bar()
}
If we can't get this behavior to work on all platforms, exposing it through a
dedicated ObjcObject type like this would help identify whether code that uses
it is able to be used cross platform or not.
>>
>> Jordan
>>
>>
>>> On Mar 22, 2016, at 18:59 , Kevin Lundberg via swift-evolution
>>> <[email protected] <mailto:[email protected]>> wrote:
>>>
>>> In "Using Swift with Cocoa and Objective-C", this behavior is described as
>>> part of how AnyObject works:
>>>
>>> “You can also call any Objective-C method and access any property without
>>> casting to a more specific class type." … "However, because the specific
>>> type of an object typed as AnyObject is not known until runtime, it is
>>> possible to inadvertently write unsafe code. As in Objective-C, if you
>>> invoke a method or access a property that does not exist on an AnyObject
>>> typed object, it is a runtime error.”
>>>
>>> I propose that we remove this behavior entirely to push swift further in
>>> the direction of type safety.
>>>
>>> Rationale:
>>> Even if you don’t mean to write code that relies on this behavior, it's
>>> easy to accidentally do so when interfacing with various Cocoa APIs due to
>>> type inference. A developer may not even realize that their code is unsafe
>>> since their code will compile just fine when calling obj-c visible methods.
>>> Removing this behavior would alleviate any confusion that a developer may
>>> have while writing this, especially as it is not a highly advertised
>>> feature of AnyObject. Furthermore, anyone who reads swift code using this
>>> will know with more certainty what types the author expects to be using
>>> here since an explicit cast will be required.
>>>
>>> Considerations:
>>> If this is done, the way I see AnyObject behaving is similar to Any, where
>>> you need to manually downcast in order to call methods on things. Code
>>> would change from this:
>>>
>>>
>>> class Foo: NSObject { func bar() {} }
>>> let things = NSOrderedSet(object: Foo())
>>>
>>> for thing in things { // thing is AnyObject
>>> thing.bar() // happens to work but not verified by compiler, may crash
>>> in the future
>>> }
>>>
>>>
>>> to something like this:
>>>
>>> //...
>>>
>>> for thing in things {
>>> if let foo = thing as? Foo { // needs an explicit cast
>>> foo.bar() // type checked, verified by compiler, won’t crash
>>> due to missing method
>>> }
>>> }
>>>
>>>
>>> One ancillary benefit that I can see of doing this is that it could make
>>> AnyObject consistent across darwin and other platforms. As far as I can
>>> tell, this behavior only exists on platforms where swift integrates with
>>> the objective-c runtime, and doing this will help swift code be more
>>> portable as it doesn’t rely on this implicit behavior.
>>>
>>> Any thoughts?
>>>
>>> --
>>> Kevin Lundberg
>>> [email protected] <mailto:[email protected]>
>>>
>>>
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> [email protected] <mailto:[email protected]>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>
>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
