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 < [email protected]> 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 < > [email protected]> 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 > > [email protected] > > 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
