<div dir="ltr">In addition to the points that have been raised, it's my opinion that some of the stuff in Foundation should really be implemented in the stdlib in the future (for example, collections that weakly reference their items, and a native binary data blob type). The fact that the delineation between what goes in the stdlib and what goes in Foundation is the result of historical happenstance does not really sit well with me. I think that Foundation's evolution should be done with this in mind, such that in the future certain Foundation classes might be implemented as stubs built on top of native data structures, with additional functionality for legacy compatibility (sort of like how String works today).<div><br></div><div>Best,</div><div>Austin</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 9, 2016 at 9:03 AM, Matthew Johnson via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
Sent from my iPad<br>
<span class=""><br>
> On May 9, 2016, at 10:49 AM, Zach Waldowski via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
><br>
> This is exactly the way I see it, too. Many people are coming to Swift<br>
> and immediately decrying the language because it doesn't have built-in<br>
> support for regex, date parsing, collections beyond the built-in 3,<br>
> etc., when it in fact has a rich tapestry of things from Foundation.<br>
><br>
> While I agree with many of the points made in the thread, I think we're<br>
> missing the forest for the trees. Foundation is the best at many of the<br>
> things it does on any platform. This is in spite of many of the points<br>
> made: it *has* an Objective-C API. It *is* coupled to Apple platforms.<br>
> It *does* have crufty edges.<br>
><br>
> Foundation not having a super-Swifty API is a solvable problem over<br>
> time, of which this is a first step down that road. Revamping the<br>
> Foundation API in the Swift 3 timeframe is not a solvable problem.<br>
<br>
</span>I agree with everything you say here. My only concern is trying to ensure we don't take steps today that will make it difficult to implement the best design down the road.<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> Cheers<br>
> Zach Waldowski<br>
> <a href="mailto:zach@waldowski.me">zach@waldowski.me</a><br>
><br>
>> On Mon, May 9, 2016, at 10:42 AM, Sean Heber via swift-evolution wrote:<br>
>> If I am coming to Swift as a new user (possibly as a first language,<br>
>> even) without any prior Objective-C experience and very little knowledge<br>
>> of the long history of Foundation, the NS prefix, etc, this is going to<br>
>> feel worse than a little out of place - it will feel downright wrong,<br>
>> broken, and confusing to see these weird NS prefixes on some seemingly<br>
>> “standard” classes and not on others.<br>
>><br>
>> I’m +1 for removing the NS and evolving forward from there - let’s not<br>
>> create a confusing tangle of old and new that is navigable only by those<br>
>> with knowledge of the esoteric.<br>
>><br>
>> l8r<br>
>> Sean<br>
>><br>
>><br>
>>> On May 9, 2016, at 5:33 AM, Haravikk via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
>>><br>
>>> I have mixed feelings about this; while I agree that prefixing names isn’t a good fit for Swift, at the same time that’s kind of the appeal of it. Assuming that Foundation will eventually be replaced by a more Swift-like alternative, or will be incrementally reworked, I think it makes sense for it to feel a little weird to use as it is right now.<br>
>>><br>
>>> The NS prefix makes it clear that this is something different, something not originally designed with Swift in mind, and in a way that’s a good thing. I know in my own case it makes me instinctively shy away from it, and actually encourages me to wrap NS constructs in something more Swift-like for convenience.<br>
>>><br>
>>>> On 6 May 2016, at 21:52, Tony Parker via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
>>>><br>
>>>> Hi everyone,<br>
>>>><br>
>>>> Thanks to all of you for your feedback on SE-0069 (Foundation Value Types). I’m back again with more information on another part of our plan to integrate Foundation API into Swift: dropping the NS prefix.<br>
>>>><br>
>>>> When we originally proposed this as part of the API guidelines document (SE-0023, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0023-api-guidelines.md" rel="noreferrer" target="_blank">https://github.com/apple/swift-evolution/blob/master/proposals/0023-api-guidelines.md</a>), we took a very broad approach to which classes would drop their prefix. This time, we’ve narrowed the scope considerably, plus taken advantage of the ability to nest types inside classes to further reduce the possibility of introducing conflicting names.<br>
>>>><br>
>>>> I’ve written up a draft of the proposal, which includes an extensive section on motivation plus a list of changes. Please take a look and let me know what you think. We’ll start a formal review period soon.<br>
>>>><br>
>>>> <a href="https://github.com/parkera/swift-evolution/blob/parkera/drop_ns/proposals/NNNN-drop-foundation-ns.md" rel="noreferrer" target="_blank">https://github.com/parkera/swift-evolution/blob/parkera/drop_ns/proposals/NNNN-drop-foundation-ns.md</a><br>
>>>><br>
>>>> Thanks again for your help,<br>
>>>> - Tony<br>
>>>><br>
>>>> _______________________________________________<br>
>>>> swift-evolution mailing list<br>
>>>> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
>>>> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
>>><br>
>>> _______________________________________________<br>
>>> swift-evolution mailing list<br>
>>> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
>>> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
>><br>
>> _______________________________________________<br>
>> swift-evolution mailing list<br>
>> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
>> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
> _______________________________________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</div></div></blockquote></div><br></div>