I’m pretty much a +1 by default to anything that avoids unexpected runtime errors =D
But yeah, I agree that Swift’s type inference shouldn’t result in types that we can’t trust, and that it’s better to force the developer to declare what they want/expect the type to be. Most occurrences of AnyObject are one of only a few possible types, and well-documented (otherwise you’d be unable to do anything with them), so while looking up the types you need to check for is an added step, I think it’s worth the extra safety, especially with so much useful code still written in Objective-C. > On 23 Mar 2016, at 01: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
