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