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

Hello Swift community,

The review of SE-0086 "Drop NS Prefix in Swift Foundation" begins now and runs through May 16, 2016. The proposal is available here:

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution
or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:

Proposal link:

Reply text

Other replies
<swift-evolution/process.md at master · apple/swift-evolution · GitHub goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
More information about the Swift evolution process is available at

Thank you,

-Doug Gregor

Review Manager

  • What is your evaluation of the proposal?

I support the enum hoisting and case renaming, but not the dropping of the "NS" prefix quite this widely, for several reasons:

1. I agree with the critique that "NSCoder" and its ilk should retain their "NS" prefix because they represent something very specific to Foundation, not some general concept of a "coder". ("JSONSerialization", on the other hand, *is* something quite generic.)

2. I think the "NS" prefixes may be a valuable indicator of which types are values and which are references. (For this to be the case, we might need to drop some NS prefixes from certain enums.)

3. I am wholly unconvinced by the arguments in the "Keep NS on future value types" section.

Another proposal (I'm behind, so I'm not sure if it's been accepted) suggests that we add a value-typed `URL` to Foundation. Think about what would happen if that proposal were deferred to Swift 4: `NSURL` would be renamed to `URL` in Swift 3, and then Swift 4 would want to use `URL` for something else. At that point, we have several choices, none of them very nice:

* Rename uses of `URL` back to `NSURL`, only one version after making the opposite change. Note that this doesn't only mean migrating code, but also developers' understanding of the frameworks—people will misread code for a while.

* Choose a different name for the new value-typed `URL`, like `URLValue` or `URI` or something. The preferred type then gets a suboptimal name.

* Deprecate the `URL` name, encourage use of `NSURL` instead, and delay the introduction of the new `URL` for a version or two while the deprecation works its magic. Now we've slowed down the evolution of the language.

Any of these seems like a huge own goal next to the alternative of simply leaving all (or most) NS prefixes in place, at least until we feel the main work of adding value types to Foundation is complete.

  • Is the problem being addressed significant enough to warrant a change to Swift?

Sure, Foundation needs some cleanup. Just not *this* cleanup.

  • Does this proposal fit well with the feel and direction of Swift?

Yes and no. I worry it'll slow the adoption of value types by Foundation, which would not be a good thing.

  • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

N/A.

  • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Quick reading, I suppose.

···

--
Brent Royal-Gordon
Architechies

What is your evaluation of the proposal?

+1 I already gave my opinion in the original discussion but I’ll summarise it here. I understand the fears that this proposal may inhibit us in the future from making the modifications that Foundation needs to make it feel more Swifty. But I think that those fears are maybe exaggerated and that this proposal is the first step in the right direction.

Is the problem being addressed significant enough to warrant a change to Swift?

This could mean the difference between a good and a great adoption of corelibs-foundation, so I think it definitely is significant enough.

Does this proposal fit well with the feel and direction of Swift?

Definitely.

If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

Not applicable to this proposal.

How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

I read the proposal in detail and followed the heated debate around the pitch :)

What is your evaluation of the proposal?

I very much support hoisting types, updating enumerations, and updating the NSStringEncoding constants.

I do not support dropping NS on type level names. Dropping the 2 character prefix is a very small benefit and it comes with very real costs. I believe unprefixed top level names should not be taken without a manual review of the API design.

Types which will be value types in the future are obvious candidates for redesign but are not the only types whose API would benefit by human consideration and Swiftification. Keeping the NS prefix until this happens recognizes that the Swiftification of Foundation is a work in progress. It will give us more options in the future that don’t involve breaking changes.

It will also serve as a signal to developers about what kinds of APIs should be considered idiomatic in Swift. If we want developers to learn how to distinguish idiomatic Swift, our API guidelines, etc from Objective-C mappings we need to provide some cues. I believe name prefixes are a good way to do this.

I hope that we will move forward with most of this proposal while keeping the NS prefix for top-level names.

Is the problem being addressed significant enough to warrant a change to Swift?

Yes, but we need to do this carefully, deliberately and in a way that we won’t regret in the future. I believe several parts of the proposal are warranted, but the namesake “drop NS prefix” portion should deferred until each type receives manual consideration and possibly redesign.

Does this proposal fit well with the feel and direction of Swift?

Mostly yes. However, taking top-level unprefixed names without a process of Swiftification does not.

If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

I think this question is N/A for this proposal.

I hesitate in saying this, but I think the best comparison to consider is the origin of Foundation and Cocoa themselves. They are fantastic Objective-C APIs. If they had originated by wrapping pre-existing APIs written in a different language with different idioms and then incrementally enhanced I wonder if they may have been less fantastic.

I believe reserving unprefixed top-level names for manually designed, idiomatic types is the path for Swift that avoids this risk altogether and gives us the best chance possible at an incredible, idiomatic set of libraries.

How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

I participated in the discussion, read the proposal, and carefully considered the consequences of each piece.

···

More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md
Thank you,

-Doug Gregor

Review Manager

_______________________________________________
swift-evolution-announce mailing list
swift-evolution-announce@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution-announce

Proposal link:

https://github.com/apple/swift-evolution/blob/master/proposals/0086-drop-foundation-ns.md
Reply text

What is your evaluation of the proposal?

+1 to all except renaming classes that are planned in the future to become value types, and the NSCoding issue.

I agree with Brent that I am unconvinced we should take off NS from those we have identified as future value types. Classes we highly suspect should become value types should retain their NS prefix at this time, as preparation to avoid the mess that would be to come from reverting, deprecating etc. Just because we don’t have enough time to get these value types sorted right away doesn’t mean we should shoot ourselves in the foot by changing things we’ve already identified as high potential for Value Type Transition. If we identify other types later on that should move to value semantics, these strategies would work, but I wonder why deliberately create a headache for ourselves?

I am uncertain about the NSCoding proposition as it is not a generic concept that is platform agnostic. It is a baked in, Objective-C, Apple-only paradigm that seems to me should retain it’s NS prefix.

Is the problem being addressed significant enough to warrant a change to Swift?

It’s important to get Swift Foundation and Objective-C Foundation heading in the right direction, and to provide for more Swiftification in Foundation in the future, so I think this is significant enough.

Does this proposal fit well with the feel and direction of Swift?

Yes and no. I agree with Brent that dropping NS on high-probability value types is not a wise move, and will slow down value type adoption. It seems easier to deprecate the name with NS at a later date if it is determined it must stay a reference type, than it would be trying to go the other way when we decide to move something to value type.

If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

N/A

How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Read through the proposal, and have followed the preceding discussions regarding value type adoption and the name transition.

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.

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.

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.

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.

Review of proposal:

  https://github.com/apple/swift-evolution/blob/master/proposals/0086-drop-foundation-ns.md

What is your evaluation of the proposal?

I’m +1 on this.

I believe that it represents a useful cleanup of the Foundation type naming, and a maturation of the Swift/Foundation libraries and the integration thereof. Yes, changes can be expected in the future, but if we live in perpetual fear of what the future might bring then we will advance only slowly toward it. The proposal outlines careful thought into how future additional needed transitions can be accomplished.

Is the problem being addressed significant enough to warrant a change to Swift?

Yes

Does this proposal fit well with the feel and direction of Swift?

Yes

···

If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

-

How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

I’ve followed the discussion carefully and carefully read and assessed the proposal.

<swift-evolution/proposals at master · apple/swift-evolution · GitHub
0086-drop-foundation-ns.md>

+1 to dropping the NS prefix; type names are more readable. However:

* AppKit, CoreData, and TextKit will still use the NS prefix.
* Prefixed names (in all frameworks) are more "googleable".
* Should deprecated types (e.g. NSMessagePort) keep the prefix?

+1 to using nested enums/options; it will make method signatures shorter.

You could also have a nested RunLoop.Timer class (cf. CFRunLoopTimer) and
move your experimental `scheduledTimer` method to the RunLoop class.

Will top-level constants/functions also be nested? For example:

* SE-0033: Import Objective-C Constants as Swift Types
* SE-0044: Import as Member

Missing from the "Drop NS prefix" list:

* NSBinarySearchingOptions
* NSCopying, NSMutableCopying
* NSDirectoryEnumerator
* NSEnumerationOptions
* NSEnumerator
* NSExpression
* NSNull
* NSSecureCoding
* NSSortOptions

Missing from the "Hoisted types" list:

* NSAffineTransformStruct
* NSDateComponentsFormatterUnitsStyle
* NSDateComponentsFormatterZeroFormattingBehavior
* NSRoundingMode

-- Ben

Hi everyone,

After some discussion, we have a small update to the proposal. The following types will keep their NS prefix:

NSCoding
NSSecureCoding
NSCoder
NSKeyedArchiver
NSKeyedUnarchiver

The reason is that NSCoding is, at least for the moment, fairly tied to Objective-C (since it is partially implemented with categories on NSObject). The others are not strictly part of that same rule, but they are so tied to NSCoding that I felt it was better to keep them in the same bucket.

- Tony

···

On May 9, 2016, at 3:20 PM, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:

Hello Swift community,

The review of SE-0086 "Drop NS Prefix in Swift Foundation" begins now and runs through May 16, 2016. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0086-drop-foundation-ns.md
Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution
or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:

Proposal link:

https://github.com/apple/swift-evolution/blob/master/proposals/0086-drop-foundation-ns.md
Reply text

Other replies
<https://github.com/apple/swift-evolution/blob/master/process.md#what-goes-into-a-review-1&gt;What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md
Thank you,

-Doug Gregor

Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

* What is your evaluation of the proposal?

+1 to enum renaming / hoisting, including turning NSStringEncoding into
an enum, but -1 on dropping the NS prefix. I agree with a lot of what
the other -1 people have said, but the 2 biggest reasons for me are:

1. The NS prefix is a signal that the type is probably an Objective-C
   class, and with the enum renaming/hoisting this signal will become
   even stronger. The fact that it's an Objective-C class means that
   it's not Swift-like, it's a reference type, it doesn't participate in
   copy-on-write mutation, etc.

2. Dropping the NS prefix means that a *lot* of pretty generic names are
   now owned by Foundation, which makes it difficult to implement the
   same concept in the Swift standard library. A lot of these names
   aren't likely to end up in the Swift stdlib, but I'd rather be
   cautious about this and not take any of these names.

By keeping the NS prefixes, we can then "swiftify" these APIs on an
ongoing basis and drop the prefix once a type has been "swiftified"
(which includes turning things into value types when applicable, not
merely renaming methods). And if done right, the swiftified types can
operate without Foundation at all, the same way
String/Array/Dictionary/Set are independent implementations that bridge
to/from Obj-C.

As a side note, regardless of everything else, we really should not
rename NSJSONSerialization to JSONSerialization. This class is a
specific implementation of a JSON encoder/decoder that operates on
Foundation types. The name JSONSerialization should be reserved for the
potential use of a Swift-native JSON encoder/decoder.

* Is the problem being addressed significant enough to warrant a
   change to Swift?

I don't think so. I'm not sure what the benefit of dropping the "NS"
prefix is supposed to be at all, besides saving 2 keystrokes. The
proposal says this is to "establish these libraries as fundamental and
native Swift libraries" by "making their naming style match the
convention established by the standard library", but I don't think this
is actually the right way to do this. Renaming these classes doesn't
make the API feel like native Swift (biggest example is value vs
reference types). What would make them feel like native Swift is writing
a native Swift type with a native Swift API and native Swift conventions
that bridges to/from the obj-c class (e.g. how Swift 3 is gaining the
URL value type).

* How much effort did you put into your review? A glance, a quick
   reading, or an in-depth study?

A quick reading of the proposal, as well as reading previous discussions
about this topic.

-Kevin Ballard

···

On Mon, May 9, 2016, at 03:20 PM, Douglas Gregor via swift-evolution wrote:

We (you) shouldn't remove the NS prefixes from most of the classes in
the proposal. I agree with the reasons the other naysayers have given,
but I'll try to restate them in my own words.

Swift needs a better namespace/import system before these classes
should lose the NS prefix. Right now, you cannot just import one name
from a module. (If you think you can, try typing “import
Foundation.NSDate; NSPort.self” into the REPL.) Therefore we should be
selective about what loses the NS prefix.

For any type, some fraction of programs need to mention the type by
name in order to justify a prefixless name. What should that threshold
be? Fifty percent? Ten percent? Five percent? String and Int and a
bunch of other types in the standard library can pass a reasonable
threshold. What fraction of programs mention NSTask? NSPort? NSHost?
NSScanner?

For any name, some fraction of programs would want to use that term
for a program-specific type different than the Foundation type. What
fraction is high enough to justify prefixing the Foundation type name?
E.g. are there enough datebook programs that think "Calendar" should
mean the user's schedule of events, so that Foundation shouldn't claim
the generic term "Calendar"? How about "Timer"? "Task"? "Port"?
"Host"?

What fraction of these Foundation types would have a substantially
different API if they were designed from scratch in the age of Swift
with the experience of Foundation? Example: NSDate. Looking at each of
JodaTime, NodaTime, and boost::date_time, I see a type representing a
calendar date (e.g. 2016-05-16) with no associated time of day. I've
seen and answered enough questions on stackoverflow to know that iOS
programmers want a type like that. A from-scratch Swift date/time
library would be justified in having such a type, and "Date" would be
a great name for that type (with a prefix or nested in another type,
unless Swift gets a better namespace/import system). NSDate represents
the same thing as CFAbsoluteTime, and should have a name more
representative of that.

I just don't see the benefit of stripping the NS prefix from most of
the types in Foundation, given the state of those types and the state
of Swift.

I’m afraid I generally have to agree with this criticism. For types like NSURL which would make sense to become value types in the future, dropping the prefix does seem as if it would put constraints on future growth.

I do think the enum hoisting is great, though, and if it were in a separate proposal I’d definitely +1 it.

Charles

···

On May 9, 2016, at 6:57 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

  • What is your evaluation of the proposal?

I support the enum hoisting and case renaming, but not the dropping of the "NS" prefix quite this widely, for several reasons:

1. I agree with the critique that "NSCoder" and its ilk should retain their "NS" prefix because they represent something very specific to Foundation, not some general concept of a "coder". ("JSONSerialization", on the other hand, *is* something quite generic.)

2. I think the "NS" prefixes may be a valuable indicator of which types are values and which are references. (For this to be the case, we might need to drop some NS prefixes from certain enums.)

3. I am wholly unconvinced by the arguments in the "Keep NS on future value types" section.

Another proposal (I'm behind, so I'm not sure if it's been accepted) suggests that we add a value-typed `URL` to Foundation. Think about what would happen if that proposal were deferred to Swift 4: `NSURL` would be renamed to `URL` in Swift 3, and then Swift 4 would want to use `URL` for something else. At that point, we have several choices, none of them very nice:

* Rename uses of `URL` back to `NSURL`, only one version after making the opposite change. Note that this doesn't only mean migrating code, but also developers' understanding of the frameworks—people will misread code for a while.

* Choose a different name for the new value-typed `URL`, like `URLValue` or `URI` or something. The preferred type then gets a suboptimal name.

* Deprecate the `URL` name, encourage use of `NSURL` instead, and delay the introduction of the new `URL` for a version or two while the deprecation works its magic. Now we've slowed down the evolution of the language.

Any of these seems like a huge own goal next to the alternative of simply leaving all (or most) NS prefixes in place, at least until we feel the main work of adding value types to Foundation is complete.

  • Is the problem being addressed significant enough to warrant a change to Swift?

Sure, Foundation needs some cleanup. Just not *this* cleanup.

  • Does this proposal fit well with the feel and direction of Swift?

Yes and no. I worry it'll slow the adoption of value types by Foundation, which would not be a good thing.

  • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

N/A.

  • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Quick reading, I suppose.

--
Brent Royal-Gordon
Architechies

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Plus, NSCoding has a *lot* of legacy cruft associated with it that we would do well to jettison with a brand-new coding protocol, IMO.

Charles

···

On May 9, 2016, at 7:38 PM, Rod Brown via swift-evolution <swift-evolution@swift.org> wrote:

I am uncertain about the NSCoding proposition as it is not a generic concept that is platform agnostic. It is a baked in, Objective-C, Apple-only paradigm that seems to me should retain it’s NS prefix.

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)

···

Am 10.05.2016 um 12:26 schrieb Haravikk via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>:

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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

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)

···

Am 10.05.2016 um 12:26 schrieb Haravikk via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>:

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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

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)

···

Am 10.05.2016 um 12:26 schrieb Haravikk via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>:

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@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

<https://github.com/apple/swift-evolution/blob/master/proposals/
0086-drop-foundation-ns.md>

+1 to dropping the NS prefix; type names are more readable. However:

* AppKit, CoreData, and TextKit will still use the NS prefix.
* Prefixed names (in all frameworks) are more "googleable".
* Should deprecated types (e.g. NSMessagePort) keep the prefix?

+1 to using nested enums/options; it will make method signatures shorter.

You could also have a nested RunLoop.Timer class (cf. CFRunLoopTimer) and
move your experimental `scheduledTimer` method to the RunLoop class.

Will top-level constants/functions also be nested? For example:

* SE-0033: Import Objective-C Constants as Swift Types
* SE-0044: Import as Member

Missing from the "Drop NS prefix" list:

* NSBinarySearchingOptions
* NSCopying, NSMutableCopying

The reasoning behind these keeping NS is that almost all of the mutable copying items have a correlative structural type; e.g. Data, Array, Dictionary, Set etc.

* NSDirectoryEnumerator

NSDirectoryEnumerator is going to be hoisted into FileManager.DirectoryEnumerator (I think the proposal may have missed this one)

* NSEnumerationOptions
* NSEnumerator

NSEnumerator is used to enumerate the NS collections of references

* NSExpression

This is very tied to KVC and reference collections

* NSNull

Not really applicable in swift since you can have an array of options etc.

* NSSecureCoding
* NSSortOptions

Missing from the "Hoisted types" list:

* NSAffineTransformStruct

This one is actually being renamed a bit differently; it will be called AffineTransform to the counterpart reference type NSAffineTransform

* NSDateComponentsFormatterUnitsStyle

This is missing from the proposal and should be listed as DateComponentsFormatter.UnitsStyle

* NSDateComponentsFormatterZeroFormattingBehavior

This is missing from the proposal and should be listed as DateComponentsFormatter.ZeroFormattingBehavior

* NSRoundingMode

This is missing from the proposal and should be listed as Decimal.RoundingMode

-- Ben

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

The others I need to follow up on with Tony to determine if they need better refinements.

···

On May 10, 2016, at 11:11 AM, Ben Rimmington via swift-evolution <swift-evolution@swift.org> wrote:

<https://github.com/apple/swift-evolution/blob/master/proposals/
0086-drop-foundation-ns.md>

+1 to dropping the NS prefix; type names are more readable. However:

* AppKit, CoreData, and TextKit will still use the NS prefix.
* Prefixed names (in all frameworks) are more "googleable".
* Should deprecated types (e.g. NSMessagePort) keep the prefix?

+1 to using nested enums/options; it will make method signatures shorter.

You could also have a nested RunLoop.Timer class (cf. CFRunLoopTimer) and
move your experimental `scheduledTimer` method to the RunLoop class.

Will top-level constants/functions also be nested? For example:

* SE-0033: Import Objective-C Constants as Swift Types
* SE-0044: Import as Member

Missing from the "Drop NS prefix" list:

* NSBinarySearchingOptions

More corrections: this will drop it’s NS

* NSCopying, NSMutableCopying

The reasoning behind these keeping NS is that almost all of the mutable copying items have a correlative structural type; e.g. Data, Array, Dictionary, Set etc.

* NSDirectoryEnumerator

NSDirectoryEnumerator is going to be hoisted into FileManager.DirectoryEnumerator (I think the proposal may have missed this one)

* NSEnumerationOptions

As will this.

* NSEnumerator

NSEnumerator is used to enumerate the NS collections of references

* NSExpression

This is very tied to KVC and reference collections

* NSNull

Not really applicable in swift since you can have an array of options etc.

* NSSecureCoding

This was an oversight and should have it’s prefix dropped as well.

* NSSortOptions

NSSortOptions also will shed it’s prefix

···

On May 10, 2016, at 12:48 PM, Philippe Hausler via swift-evolution <swift-evolution@swift.org> wrote:

On May 10, 2016, at 11:11 AM, Ben Rimmington via swift-evolution <swift-evolution@swift.org> wrote:

Missing from the "Hoisted types" list:

* NSAffineTransformStruct

This one is actually being renamed a bit differently; it will be called AffineTransform to the counterpart reference type NSAffineTransform

* NSDateComponentsFormatterUnitsStyle

This is missing from the proposal and should be listed as DateComponentsFormatter.UnitsStyle

* NSDateComponentsFormatterZeroFormattingBehavior

This is missing from the proposal and should be listed as DateComponentsFormatter.ZeroFormattingBehavior

* NSRoundingMode

This is missing from the proposal and should be listed as Decimal.RoundingMode

-- Ben

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

The others I need to follow up on with Tony to determine if they need better refinements.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

I second Matthew’s points. I believe dropping NS- is more harmful than helpful, especially for the future. People have been using Foundation with the prefix for decades, so I don’t think there’s a longing need that will make using it in Swift unbearable. It has an older Objective-C flavoured approach, relying heavily on classes, run loops, key value observing (e.g. NSOperation), exceptions, and notifications. I think its philosophy will stand out more than its NS- prefix. Even if many classes become value types, it feels more like a port.

I think for something to be so central as the recommended ‘foundational’ library for Swift, it carries too much baggage, which is unfortunate in the light of Swift’s radical eagerness to reject unnecessary legacy.

Many Foundation classes expect NSObject subclasses for delegates and for key value coding & observing. Key value observing requires on-the-fly subclassing at run time, something which goes strongly against Swift’s philosophy AFAIK.

Foundation is in some cases a wrapper around underlying technologies such as GCD, because years ago an Objective-C wrapper was seen as a more friendly, more safe, and a more familiar object-oriented approach. With Swift we have the power to make those technologies themselves more friendly, safe, and familiar with modernisations such as the current proposal for libdispatch. Extensions allow us to add properties and methods directly to the native types.

NSURL has methods such as .getResourceValue(_:forKey:) that involve mutable state.

I think removing the prefixes will take valuable real estate for types such as ‘URL’ and ‘Data’, which instead can have new replacements made, focused on the use-cases of only Swift. I think DispatchData could be a fine choice for ‘Data’, and has the strong benefit that it bridges to NSData on Darwin.

I fully support the idea of improving Foundation, and of there being a Linux-compatible version. I don’t support it being as first class as the standard library or libdispatch, and don’t support removing the NS prefixes.

Patrick

···

On 11 May 2016, at 1:36 AM, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:

What is your evaluation of the proposal?

I very much support hoisting types, updating enumerations, and updating the NSStringEncoding constants.

I do not support dropping NS on type level names. Dropping the 2 character prefix is a very small benefit and it comes with very real costs. I believe unprefixed top level names should not be taken without a manual review of the API design.

Types which will be value types in the future are obvious candidates for redesign but are not the only types whose API would benefit by human consideration and Swiftification. Keeping the NS prefix until this happens recognizes that the Swiftification of Foundation is a work in progress. It will give us more options in the future that don’t involve breaking changes.

It will also serve as a signal to developers about what kinds of APIs should be considered idiomatic in Swift. If we want developers to learn how to distinguish idiomatic Swift, our API guidelines, etc from Objective-C mappings we need to provide some cues. I believe name prefixes are a good way to do this.

I hope that we will move forward with most of this proposal while keeping the NS prefix for top-level names.

Is the problem being addressed significant enough to warrant a change to Swift?

Yes, but we need to do this carefully, deliberately and in a way that we won’t regret in the future. I believe several parts of the proposal are warranted, but the namesake “drop NS prefix” portion should deferred until each type receives manual consideration and possibly redesign.

Does this proposal fit well with the feel and direction of Swift?

Mostly yes. However, taking top-level unprefixed names without a process of Swiftification does not.

If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

I think this question is N/A for this proposal.

I hesitate in saying this, but I think the best comparison to consider is the origin of Foundation and Cocoa themselves. They are fantastic Objective-C APIs. If they had originated by wrapping pre-existing APIs written in a different language with different idioms and then incrementally enhanced I wonder if they may have been less fantastic.

I believe reserving unprefixed top-level names for manually designed, idiomatic types is the path for Swift that avoids this risk altogether and gives us the best chance possible at an incredible, idiomatic set of libraries.

How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

I participated in the discussion, read the proposal, and carefully considered the consequences of each piece.

More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md
Thank you,

-Doug Gregor

Review Manager

_______________________________________________
swift-evolution-announce mailing list
swift-evolution-announce@swift.org <mailto:swift-evolution-announce@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution-announce

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

-1 for all the reasons given so far. Foundation is not a Swift API and the
NS prefixes help users understand that. Until Foundation gets an API
rewrite that makes it feel native in the Swift ecosystem, it should be made
very clear that it is a legacy API and not necessary following Swift best
practices. I'm actually quite surprised that the Swift team decided to
reimplement Foundation with 100% api compatibility, rather than building a
"new and improved" version from scratch.

···

On Mon, May 16, 2016 at 6:37 PM Rob Mayoff via swift-evolution < swift-evolution@swift.org> wrote:

We (you) shouldn't remove the NS prefixes from most of the classes in
the proposal. I agree with the reasons the other naysayers have given,
but I'll try to restate them in my own words.

Swift needs a better namespace/import system before these classes
should lose the NS prefix. Right now, you cannot just import one name
from a module. (If you think you can, try typing “import
Foundation.NSDate; NSPort.self” into the REPL.) Therefore we should be
selective about what loses the NS prefix.

For any type, some fraction of programs need to mention the type by
name in order to justify a prefixless name. What should that threshold
be? Fifty percent? Ten percent? Five percent? String and Int and a
bunch of other types in the standard library can pass a reasonable
threshold. What fraction of programs mention NSTask? NSPort? NSHost?
NSScanner?

For any name, some fraction of programs would want to use that term
for a program-specific type different than the Foundation type. What
fraction is high enough to justify prefixing the Foundation type name?
E.g. are there enough datebook programs that think "Calendar" should
mean the user's schedule of events, so that Foundation shouldn't claim
the generic term "Calendar"? How about "Timer"? "Task"? "Port"?
"Host"?

What fraction of these Foundation types would have a substantially
different API if they were designed from scratch in the age of Swift
with the experience of Foundation? Example: NSDate. Looking at each of
JodaTime, NodaTime, and boost::date_time, I see a type representing a
calendar date (e.g. 2016-05-16) with no associated time of day. I've
seen and answered enough questions on stackoverflow to know that iOS
programmers want a type like that. A from-scratch Swift date/time
library would be justified in having such a type, and "Date" would be
a great name for that type (with a prefix or nested in another type,
unless Swift gets a better namespace/import system). NSDate represents
the same thing as CFAbsoluteTime, and should have a name more
representative of that.

I just don't see the benefit of stripping the NS prefix from most of
the types in Foundation, given the state of those types and the state
of Swift.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Dan Appel