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

[Xiaodi Wu]

Unless I'm mistaken, NSURL is not among the types being renamed in this
proposal?
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.
>
> Charles
>
> > 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
> 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 at swift.org
> > 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/20160510/618f07f9/attachment.html>