Speaking from a position of total ignorance here, but I’ll do it anyway :-)
How is the implicit dynamic bridging any different from implicit static bridging? If I have an Objective-C method like - (NSArray<SuctionBall>)getAllSuctionBalls It would get translated into func getAllSuctionBalls() -> [SuctionBall] Since such an implicit conversion exists anyway, what’s the harm in it happening when you do let > On Mar 3, 2017, at 10:18 AM, Joe Groff via swift-evolution > <swift-evolution@swift.org> wrote: > > >> On Mar 3, 2017, at 9:56 AM, Tony Parker <anthony.par...@apple.com> wrote: >> >> I’m concerned about the large source compatibility impact this change would >> have. Even if we claim that it’s only for Swift 4, migration would be >> difficult. Even if it were just a warning, that could be extremely noisy for >> large projects. >> >> What do you propose to mitigate that problem? >> >> I also think that before proceed with this change any further, we should >> have a lot more data about the impact that it has on real world applications >> in general. How many places use as for bridging now? What alternative >> approach would they use? We should see a diff of some of that real world >> code and see if we actually like the result. > > I plan to take a look at some existing mixed-source projects to see what the > impact of these changes would be, using an instrumented compiler and runtime > to see where bridging casts occur. I'm definitely concerned about the source > compatibility impact, which is part of why I want to break the problem down > into compile-time-only and runtime-only problems. `as` is purely a > compile-time construct, so it's possible to recognize bridging uses of `as` > and map them to equivalent initializer calls as fixits, which are the most > reliable migration mechanism we have. Changing the runtime behavior is more > problematic; like Doug's recent proposal to reduce @objc inference, we're > going to need data to see what the impact is before moving forward with these > ideas. > >> I’m not convinced that it is wrong, semantically, to use an as cast to >> indicate the conversion of a reference type to a value type. As is used to >> indicate type conversion. Bridging is a side effect, yes, but warning on >> this change may just feel pedantic without actually improving the situation. > > `as` isn't generally for type conversion, it's for type *coercion*, giving > the type checker additional information it can't infer. If not for the legacy > of inducing bridging conversions, `as` wouldn't ever have any effect on its > own. Having `as` sometimes be semantically neutral and sometimes introduce > behavior compromises that meaning, since you can't trust that `as` doesn't > have other side effects. Aside from the bridging conversions, all other > conversion operations in the library are handled by initializers, so it would > be more consistent to do the same for explicit bridging operations. Ideally, > over time, the native Swift data types will be powerful enough, and the Clang > importer and overlays comprehensive enough, to reach the point where explicit > bridging conversions are rarely necessary to begin with. > > -Joe > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
