I don’t think the API of types have to be bulletproof from the start, but it shouldn’t have core usage limitations based on Objective C. One example would be if I have to deal with NSNumber/NSString/NSArray/NSDictionary to fully use the API, such as NSAttributedString or NSError.
The issue is that Foundation is both the objective-c compatibility base and the cross-platform foundational library for Swift. These goals conflict. Without an idea of how the Swift flavor of Foundation will evolve in the future to deal with this conflict, it is hard to evaluate this other than saying “will be confusing why some Objective-C things have prefixes and others don’t” and “will cause conflicts with non-Apple foundational libraries”. -DW > On May 17, 2016, at 7:41 AM, Matt Whiteside via swift-evolution > <[email protected]> wrote: > > I meant to say that it sounds like a good idea to leave the ’NS’ prefix on > types that were auto-translated, and remove it from those that have been > rewritten by hand for swift. > > -Matt > >> On May 16, 2016, at 21:24, Matt Whiteside <[email protected] >> <mailto:[email protected]>> wrote: >> >> This sounds like a good idea. >> >> -Matt >> >>> On May 10, 2016, at 03:43, Geordie Jay via swift-evolution >>> <[email protected] <mailto:[email protected]>> wrote: >>> >>> >>>> Am 10.05.2016 um 12:26 schrieb Haravikk via swift-evolution >>>> <[email protected] <mailto:[email protected]>>: >>>> >>>> >>>>> What is your evaluation of the proposal? >>>> Personally I’m a -1; I’d prefer to see the NS prefix remain on types that >>>> have been translated automatically with minimal human interaction, in >>>> favour of dropping the prefix for types that have received more attention >>>> to establish a Swift-ier style, but migrating these into a new module >>>> instead. >>> >>> I strongly agree with keeping NS prefix on API that has not been >>> ‘Swiftified'. First step, achieve functional equivalence with Darwin APIs. >>> Second step, systematically improve Foundation to the point where it feels >>> like this fundamental part of the language is as easy to use and idiomatic >>> as the standard library itself. At that point I’d be very much for dropping >>> the prefixes. >>> >>>> >>>>> Is the problem being addressed significant enough to warrant a change to >>>>> Swift? >>>> Since it’s a basic API that most developers will be interacting with then >>>> yes, even though the change is fairly minor, it definitely bears >>>> consideration. >>>> >>>>> Does this proposal fit well with the feel and direction of Swift? >>>> Yes and no. Prefixing types with NS definitely isn’t very Swift-y, but at >>>> the same time this is why I’d like to keep the current convention for >>>> existing (unchanged) types, as it makes it much clearer that these are >>>> things that weren’t originally designed for Swift and thus won’t behave >>>> quite as you might expect. >>> >>> Completely agree >>> >>>> >>>>> If you have used other languages or libraries with a similar feature, how >>>>> do you feel that this proposal compares to those? >>>> I’ve worked in languages where libraries had different styles of >>>> name-spacing, and while it was annoying to have a mixture, I think it was >>>> fine, especially for libraries that are older, as the prefix name-spacing >>>> style makes it absolutely clear that this is an older API. >>>> >>> >>> Yes, we should be clear this is an older API, also to add motivation on >>> introducing a more modern one (even if at first it just wraps Foundation >>> with a more Swift-like API) >>> >>>>> How much effort did you put into your review? A glance, a quick reading, >>>>> or an in-depth study? >>>> >>>> Quick read of the proposal, kept an eye on the discussion leading up to it >>>> though. >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> [email protected] <mailto:[email protected]> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <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
