A complementary tactic would be that migration tool support to Swift 5 would insert the needed casts to NSString. That way even if the magic lookup is gone in Swift 5 the code could be automatically migrated and preserve the same semantics. If this came to a formal proposal I’d really like to see something like that considered.
> On Oct 24, 2017, at 3:56 PM, Slava Pestov via swift-evolution > <[email protected]> wrote: > > I think to maintain source compatibility, the old behavior would be preserved > until/if we remove -swift-version 4 mode. By deprecating it though, we won’t > have to devote as much time to maintaining it going forward. > > Slava > >> On Oct 24, 2017, at 3:54 PM, Philippe Hausler <[email protected]> wrote: >> >> I think any serious proposal with the removal of APIs would need to consider >> source compatibility and to do so you should likely audit the API surface >> area that is being offered (and replace it via the NSStringAPI.swift >> extension) >> >>> On Oct 24, 2017, at 3:12 PM, Slava Pestov via swift-evolution >>> <[email protected]> wrote: >>> >>> Perhaps you could write up a proposal to outline the missing functionality >>> :-) >>> >>> Slava >>> >>>> On Oct 24, 2017, at 3:09 PM, Jonathan Hull <[email protected]> wrote: >>>> >>>> I would feel better about it if String gained a lot of the utility of >>>> NSString (so that we don’t have to go to NSString all the time for methods) >>>> >>>> Thanks, >>>> Jon >>>> >>>>> On Oct 24, 2017, at 3:00 PM, Slava Pestov via swift-evolution >>>>> <[email protected]> wrote: >>>>> >>>>> Hi, >>>>> >>>>> Members of NSString, except those defined in Foundation, are available on >>>>> values of type String. For example, >>>>> >>>>> extension NSString { >>>>> @objc func foo() {} >>>>> } >>>>> >>>>> let s: String = “hello” >>>>> >>>>> s.foo() >>>>> >>>>> We don’t do this for any other bridged types, for instance NSArray >>>>> methods are not imported as Array methods. It’s literally a special case >>>>> in the type checker for member lookup on String. >>>>> >>>>> This behavior doesn’t really much sense conceptually and it was put in as >>>>> a stop-gap in Swift 1 to beef up the String API. I would like to phase it >>>>> out as follows: >>>>> >>>>> - Unconditional warning in Swift 4.1, with a fixit to insert an ‘as >>>>> NSString’ cast >>>>> - Error in Swift 5 with -swift-version 5 >>>>> >>>>> What does everyone think about this? >>>>> >>>>> Slava >>>>> _______________________________________________ >>>>> 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 >> > > _______________________________________________ > 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
