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. Jordan > On Mar 22, 2016, at 18:59 , Kevin Lundberg via swift-evolution > <[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] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
