[swift-evolution] [Review] SE-0086: Drop NS Prefix in Swift Foundation

[Matt Whiteside]

This sounds like a good idea.

-Matt

> On May 10, 2016, at 03:43, Geordie Jay via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> Am 10.05.2016 um 12:26 schrieb Haravikk via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>>:
>> 
>> 
>>> 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
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160516/77acb5ea/attachment.html>