[swift-evolution] [Pitch] SE-0083 revisited: removing bridging behavior from `as`/`is`/`as?` casts

[Kenny Leung]

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]

Where an NSArray is being implicitly bridged to a Swift array. Since such an implicit conversion exists anyway, what’s the harm in it happening when you do 

let swiftSuctionBalls = getSomething() as [SuctionBall]

-Kenny


> On Mar 3, 2017, at 10:18 AM, Joe Groff via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On Mar 3, 2017, at 9:56 AM, Tony Parker <anthony.parker at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution