+Int.max Charles
> On Jun 14, 2017, at 1:24 AM, David Hart via swift-evolution > <[email protected]> wrote: > > Very good description. It's always worth re-explaining terms like bridged > conversion to make sure every body is on the same page. But concerning the > rules at the end, I’m not quite sure I understood them all. Please let me > know if I’m correct: > > No bridging conversions will be performed if: > - a call, property reference, or subscript reference is the immediate > syntactic operand of an "as" cast to a type compatible with the foreign > return, property, or subscript element type > > protocol FooBar { > func foo() -> NSMutableArray > var bar: NSMutableDictionary { get set } > subscript(_ index: Int) -> NSDecimalNumber { get set } > } > > let foobar: FooBar = ... > foobar.foo() as NSArray > foobar.bar as NSDictionary > foobar[0] as NSNumber > > - a call argument, right operand of an assignment to a property > reference, or right operand of an assignment to a subscript reference is an > "as" cast from a type compatible with the foreign parameter, property, or > subscript element type. > > protocol BarFoo { > func foo(_ array: NSArray) > var bar: NSDictionary { get set } > subscript(_ index: Int) -> NSNumber { get set } > } > > var barfoo: BarFoo = ... > barfoo.foo(NSMutableArray() as NSArray) > barfoo.bar = NSMutableDictionary() as NSDictionary > barfoo[1] = NSDecimalNumber(string: "1.2") as NSNumber > > On 14 Jun 2017, at 01:11, John McCall via swift-dev <[email protected] > <mailto:[email protected]>> wrote: > >> So, there's a longstanding issue that we're planning to fix in Swift 4, and >> I want to both make sure that the plan is documented publicly and give >> people a chance to disagree with it. >> >> A bridging conversion is a conversion between a Swift type and a foreign >> type (C / ObjC / whatever) which can represent the same set of values. For >> example, there are bridging conversions from Swift.String to ObjC's NSString >> and vice-versa. When there two-way conversions like this, we say that the >> Swift type is bridged to the foreign type. >> >> Bridging conversions are performed for three reasons in Swift: >> >> 1. You can always request a bridging conversion with an unconditional "as" >> cast. For example, if myString is a String, you can convert it to NSString >> by writing "myString as NSString". >> >> 2. Certain bridging conversions can be introduced as implicit conversions. >> (This is perhaps a mistake.) For example, CFString and NSString are >> considered different types, but they will implicitly convert to each other. >> >> 3. Bridging conversions are done "behind the scenes" when using an imported >> declaration that has been given a type that does not match its original >> type. For example, an Objective-C method that returns an NSString will be >> imported as returning a String; Swift will implicitly apply a bridging >> conversion to the true return value in order to produce the String that the >> type system has promised. >> >> Bridging conversions are not always desirable. First, they do impose some >> performance overhead which the user may not want. But they can also change >> semantics in unwanted ways. For example, in certain rare situations, the >> reference identity of an NSString return value is important — maybe it's >> actually a persistent NSMutableString which should be modified in-place, or >> maybe it's a subclass which carries additional information. A pair of >> bridging conversions from NSString to String and then back to NSString is >> likely to lose this reference identity. In the current representation, >> String can store an NSString reference, and if the String is bridged to >> NSString that reference will be used as the result; however, the bridging >> conversion from NSString does not directly store the original NSString in >> the String, but instead stores the result of invoking +copy on it, in an >> effort to protect against the original NSString being somehow mutable. >> >> Bridging conversions arising from reasons #1 and #2 are avoidable, but >> bridging conversions arising from reason #3 currently cannot be eliminated >> without major inconvenience, such as writing a stub in Objective-C. This is >> unsatisfactory. At the same time, it is not valid for Swift to simply >> eliminate pairs of bridging conversions as a matter of course, precisely >> because those bridging conversions can be semantically important. We do not >> want optimization settings to be able to affect things as important as >> whether a particular NSString is mutable or not. >> >> The proposal is to apply a guaranteed syntactic "peephole" to eliminate >> bridging conversions that arise from reason #3. Specifically: >> >> No bridging conversions will be performed if: >> - a call, property reference, or subscript reference is the immediate >> syntactic >> operand of an "as" cast to a type compatible with the foreign return, >> property, >> or subscript element type or >> - a call argument, right operand of an assignment to a property >> reference, or >> right operand of an assignment to a subscript reference is an "as" >> cast from a >> type compatible with the foreign parameter, property, or subscript >> element type. >> Two types are "compatible" if there is a simple subclass or class-protocol >> relationship >> between the underlying non-optional types. >> >> We believe that this rule is easy and intuitive enough to understand that it >> will not cause substantial problems. >> >> John. >> _______________________________________________ >> swift-dev mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-dev >> <https://lists.swift.org/mailman/listinfo/swift-dev> > _______________________________________________ > 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
