This sounds like a good idea. -Matt
> On May 10, 2016, at 03:43, Geordie Jay via swift-evolution > <[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] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
