> • 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
