[swift-evolution] [swift-evolution-announce] [Review] SE-0086: Drop NS Prefix in Swift Foundation
xiaodi.wu at gmail.com
Mon May 9 19:29:53 CDT 2016
Unless I'm mistaken, NSURL is not among the types being renamed in this
On Mon, May 9, 2016 at 19:06 Charles Srstka via swift-evolution <
swift-evolution at swift.org> wrote:
> 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.
> > On May 9, 2016, at 6:57 PM, Brent Royal-Gordon via swift-evolution <
> swift-evolution at 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
> > * 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
> > 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 at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> swift-evolution mailing list
> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution