Re: [swift-corelibs-dev] [swift-evolution] Proposal: Swift Open Source Project and Foundation replacements

[David Hart]

The improvements to the Objective-C bridge in Swift 3 are definitely 
appreciated but are just cosmetics (they only affect naming). What about the 
fact that NSURL in your example, being an immutable type, would be better 
represented by a  value type in Swift? Don't misunderstand me, I applaud the 
fact that corelibs exists, and understand that Foundation has a lot of great 
ideas, but I would have preferred seeing it exist as a community hobby project 
instead of an official Swift project and have the community instead concentrate 
on a core library that embraces value types, generics, protocols, etc...

> On 04 Dec 2015, at 00:14, Tony Parker  wrote:
> 
> Hi David,
> 
> Fundamentally, we believe that the Foundation library is part of Swift. We 
> also believe that it would be a mistake to throw out the many years of 
> experience that it brings with it. In areas where there are impedance 
> mismatches between the existing API and what feels “Swifty”, we can improve 
> the API of Foundation to make it as great to use there as it is in 
> Objective-C. The first step of that is our heavy involvement with the Swift 3 
> naming guidelines here: 
> 
> https://swift.org/documentation/api-design-guidelines.html
> 
> Hope this helps,
> - Tony
> 
>> On Dec 3, 2015, at 3:09 PM, David Hart  wrote:
>> 
>> Hi Tony,
>> 
>> Like Jacob, I would have preferred a completely original corelibs library 
>> that uses that clean sheet to be as bold in library design as the standard 
>> library is. Why would that direction go against the goal of begin "as 
>> standards compliant as possible”? it would just mean that Apple Platform 
>> developers would have the option of using the Objective-C bridge to talk to 
>> Objective-C Foundation or use the “swifter” corelibs.
>> 
>> David.
>> 
 On 03 Dec 2015, at 23:33, Tony Parker  wrote:
 
 Hi Jacob,
 
 On Dec 3, 2015, at 2:23 PM, Jacob Bandes-Storch  wrote:
 
> On Thu, Dec 3, 2015 at 2:13 PM, Chris Lattner  wrote:
> 
> As others have surmised, the goal for the Swift Foundation project is to 
> provide a pure-swift implementation (which reuses widely-available C 
> libraries) of important Foundation APIs that do *not* depend on the 
> Objective-C runtime.  Reusing GNUstep, Cocotron, or even Apple’s existing 
> Foundation implementation didn’t allow us to achieve those goals, so we 
> didn’t go with those approaches.
 
 This is great, but is the goal also to exactly duplicate all the 
 idiosyncrasies of the Obj-C Foundation?
 
 Quiz: what's the result of NSURL(string: 
 "http://one/two;three/four";)?.URLByAppendingPathComponent("five") ?
 
 If, as I would hope, corelibs-foundation is an opportunity to make simpler 
 APIs that resolve some of these weirdnesses, then should the class names 
 (NSURL, NSFileHandle, etc.) really be the same?
 
  ___
 swift-corelibs-dev mailing list
 swift-corelibs-dev@swift.org
 https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
>>> 
>>> I think NSURL is actually a pretty great example of an API that we want to 
>>> be the same on all platforms. There is quite a bit of logic backing it 
>>> (along with something like NSURLComponents). Check out some of it here:
>>> 
>>> https://github.com/apple/swift-corelibs-foundation/blob/master/CoreFoundation/URL.subproj/CFURLComponents_URIParser.c
>>> 
>>> (and that CF code is reflected up into NSURLComponents)
>>> 
>>> It’s tricky stuff, and the goal is to get it as standards compliant as 
>>> possible. If we use this implementation for all Swift clients then we can 
>>> get a consistent answer everywhere - and even better, fix bugs everywhere 
>>> at the same time.
>>> 
>>> So if you find some of the interface confusing (or wrong), then file a bug 
>>> for us at bugs.swift.org. We can take this opportunity to try to make it 
>>> better for everyone.
>>> 
>>> Thanks,
>>> - Tony
>>> 
>>> 
>>> 
>>>  ___
>>> swift-corelibs-dev mailing list
>>> swift-corelibs-dev@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
> 
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] [swift-evolution] Proposal: Swift Open Source Project and Foundation replacements

[ChanMaxthon]

Then just please leave some stub there so communities can plug their own 
bridging into Swift gracefully (that is, not as an out-of-tree patch)

My idea:

1) a pure C header file, swift-compat.h describing the interface the 
community-provided bridging mechanism should implement besides objc/runtime.h, 
objc/message.h and objc/objc-arc.h, and the associated documentation describing 
what the community should do, in a even more liberal license like MIT or 3c/BSD
2) The build system checking for a compatible, community-provided 
libswift-compat.so during compilation and enable the community-provided 
bridging mechanism if present.
3) Compile-time issues can be solved similarly using libswift-repl-compat.so

When building Swift without a compatible community-provided Foundation 
reimplementation present everything here will be built, like what we are doing 
here. When building with such a library set and the corresponding 
libswift-compat.so present only the Swift standard library will be built, 
linking to the community-provided Objective-C runtime (which is also used as 
the Swift runtime through the Objective-C bridge) and take advantage of the 
community-provided Foundation framework through bridging.

Sent from my iPhone

> On Dec 4, 2015, at 16:14, David Hart  wrote:
> 
> The improvements to the Objective-C bridge in Swift 3 are definitely 
> appreciated but are just cosmetics (they only affect naming). What about the 
> fact that NSURL in your example, being an immutable type, would be better 
> represented by a  value type in Swift? Don't misunderstand me, I applaud the 
> fact that corelibs exists, and understand that Foundation has a lot of great 
> ideas, but I would have preferred seeing it exist as a community hobby 
> project instead of an official Swift project and have the community instead 
> concentrate on a core library that embraces value types, generics, protocols, 
> etc...
> 
>> On 04 Dec 2015, at 00:14, Tony Parker  wrote:
>> 
>> Hi David,
>> 
>> Fundamentally, we believe that the Foundation library is part of Swift. We 
>> also believe that it would be a mistake to throw out the many years of 
>> experience that it brings with it. In areas where there are impedance 
>> mismatches between the existing API and what feels “Swifty”, we can improve 
>> the API of Foundation to make it as great to use there as it is in 
>> Objective-C. The first step of that is our heavy involvement with the Swift 
>> 3 naming guidelines here: 
>> 
>> https://swift.org/documentation/api-design-guidelines.html
>> 
>> Hope this helps,
>> - Tony
>> 
>>> On Dec 3, 2015, at 3:09 PM, David Hart  wrote:
>>> 
>>> Hi Tony,
>>> 
>>> Like Jacob, I would have preferred a completely original corelibs library 
>>> that uses that clean sheet to be as bold in library design as the standard 
>>> library is. Why would that direction go against the goal of begin "as 
>>> standards compliant as possible”? it would just mean that Apple Platform 
>>> developers would have the option of using the Objective-C bridge to talk to 
>>> Objective-C Foundation or use the “swifter” corelibs.
>>> 
>>> David.
>>> 
> On 03 Dec 2015, at 23:33, Tony Parker  wrote:
> 
> Hi Jacob,
> 
> On Dec 3, 2015, at 2:23 PM, Jacob Bandes-Storch  
> wrote:
> 
>> On Thu, Dec 3, 2015 at 2:13 PM, Chris Lattner  wrote:
>> 
>> As others have surmised, the goal for the Swift Foundation project is to 
>> provide a pure-swift implementation (which reuses widely-available C 
>> libraries) of important Foundation APIs that do *not* depend on the 
>> Objective-C runtime.  Reusing GNUstep, Cocotron, or even Apple’s 
>> existing Foundation implementation didn’t allow us to achieve those 
>> goals, so we didn’t go with those approaches.
> 
> This is great, but is the goal also to exactly duplicate all the 
> idiosyncrasies of the Obj-C Foundation?
> 
> Quiz: what's the result of NSURL(string: 
> "http://one/two;three/four";)?.URLByAppendingPathComponent("five") ?
> 
> If, as I would hope, corelibs-foundation is an opportunity to make 
> simpler APIs that resolve some of these weirdnesses, then should the 
> class names (NSURL, NSFileHandle, etc.) really be the same?
> 
>  ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
 
 I think NSURL is actually a pretty great example of an API that we want to 
 be the same on all platforms. There is quite a bit of logic backing it 
 (along with something like NSURLComponents). Check out some of it here:
 
 https://github.com/apple/swift-corelibs-foundation/blob/master/CoreFoundation/URL.subproj/CFURLComponents_URIParser.c
 
 (and that CF code is reflected up into NSURLComponents)
 
 It’s tricky stuff, and the goal is to get it as standards compliant as 

Re: [swift-corelibs-dev] [swift-evolution] Proposal: Swift Open Source Project and Foundation replacements

[Alex Blewitt]

A more interesting question would be: is Swift designed to ultimately replace 
Objective-C? If so, baking in compatibility from the outset of the open source 
version would probably be going in the wrong direction.

Alex

> On 4 Dec 2015, at 11:12, ChanMaxthon  wrote:
> 
> Then just please leave some stub there so communities can plug their own 
> bridging into Swift gracefully (that is, not as an out-of-tree patch)
> 
> My idea:
> 
> 1) a pure C header file, swift-compat.h describing the interface the 
> community-provided bridging mechanism should implement besides 
> objc/runtime.h, objc/message.h and objc/objc-arc.h, and the associated 
> documentation describing what the community should do, in a even more liberal 
> license like MIT or 3c/BSD
> 2) The build system checking for a compatible, community-provided 
> libswift-compat.so during compilation and enable the community-provided 
> bridging mechanism if present.
> 3) Compile-time issues can be solved similarly using libswift-repl-compat.so
> 
> When building Swift without a compatible community-provided Foundation 
> reimplementation present everything here will be built, like what we are 
> doing here. When building with such a library set and the corresponding 
> libswift-compat.so present only the Swift standard library will be built, 
> linking to the community-provided Objective-C runtime (which is also used as 
> the Swift runtime through the Objective-C bridge) and take advantage of the 
> community-provided Foundation framework through bridging.
> 
> Sent from my iPhone
> 
> On Dec 4, 2015, at 16:14, David Hart  > wrote:
> 
>> The improvements to the Objective-C bridge in Swift 3 are definitely 
>> appreciated but are just cosmetics (they only affect naming). What about the 
>> fact that NSURL in your example, being an immutable type, would be better 
>> represented by a  value type in Swift? Don't misunderstand me, I applaud the 
>> fact that corelibs exists, and understand that Foundation has a lot of great 
>> ideas, but I would have preferred seeing it exist as a community hobby 
>> project instead of an official Swift project and have the community instead 
>> concentrate on a core library that embraces value types, generics, 
>> protocols, etc...
>> 
>> On 04 Dec 2015, at 00:14, Tony Parker > > wrote:
>> 
>>> Hi David,
>>> 
>>> Fundamentally, we believe that the Foundation library is part of Swift. We 
>>> also believe that it would be a mistake to throw out the many years of 
>>> experience that it brings with it. In areas where there are impedance 
>>> mismatches between the existing API and what feels “Swifty”, we can improve 
>>> the API of Foundation to make it as great to use there as it is in 
>>> Objective-C. The first step of that is our heavy involvement with the Swift 
>>> 3 naming guidelines here: 
>>> 
>>> https://swift.org/documentation/api-design-guidelines.html 
>>> 
>>> 
>>> Hope this helps,
>>> - Tony
>>> 
 On Dec 3, 2015, at 3:09 PM, David Hart >>> > wrote:
 
 Hi Tony,
 
 Like Jacob, I would have preferred a completely original corelibs library 
 that uses that clean sheet to be as bold in library design as the standard 
 library is. Why would that direction go against the goal of begin "as 
 standards compliant as possible”? it would just mean that Apple Platform 
 developers would have the option of using the Objective-C bridge to talk 
 to Objective-C Foundation or use the “swifter” corelibs.
 
 David.
 
> On 03 Dec 2015, at 23:33, Tony Parker  > wrote:
> 
> Hi Jacob,
> 
>> On Dec 3, 2015, at 2:23 PM, Jacob Bandes-Storch > > wrote:
>> 
>> On Thu, Dec 3, 2015 at 2:13 PM, Chris Lattner > > wrote:
>> 
>> As others have surmised, the goal for the Swift Foundation project is to 
>> provide a pure-swift implementation (which reuses widely-available C 
>> libraries) of important Foundation APIs that do *not* depend on the 
>> Objective-C runtime.  Reusing GNUstep, Cocotron, or even Apple’s 
>> existing Foundation implementation didn’t allow us to achieve those 
>> goals, so we didn’t go with those approaches.
>> 
>> This is great, but is the goal also to exactly duplicate all the 
>> idiosyncrasies of the Obj-C Foundation?
>> 
>> Quiz: what's the result of NSURL(string: "http://one/two;three/four 
>> ")?.URLByAppendingPathComponent("five") ?
>> 
>> If, as I would hope, corelibs-foundation is an opportunity to make 
>> simpler APIs that resolve some of these weirdnesses, then should the 
>> class names (NSURL, NSFileHandle, etc.) really be the same?
>> 
>>  ___

Re: [swift-corelibs-dev] [swift-evolution] Proposal: Swift Open Source Project and Foundation replacements

[Maxthon Chan]

Let’s take a look at C# which Microsoft designed to replace C++ MFC. The 
compatibility is never removed although C# itself is pretty complete already. 
During early days (2002) lots of components in C# are stubs calling back to MFC 
but nevertheless this presented a more or less complete library set to the user 
and allowed the language to gain traction - so many traction that now people 
demand it to be ported to multiple platforms.

Removing Objective-C compatibility in Swift (which does not even have a 
complete set of libraries yet) in this stage would undermine its usability and 
the completeness of the libraries, and when the project finally matured a bad 
reputation of “incomplete support” would already be out there, hampering its 
use.

> On Dec 4, 2015, at 18:33, Alex Blewitt  wrote:
> 
> A more interesting question would be: is Swift designed to ultimately replace 
> Objective-C? If so, baking in compatibility from the outset of the open 
> source version would probably be going in the wrong direction.
> 
> Alex
> 



smime.p7s
Description: S/MIME cryptographic signature
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] Third party license compatible libraries for JSON

[swizzlr]

Sorry, forgot to include the link:

http://zserge.com/jsmn.html
> On 4 Dec 2015, at 13:33, swizzlr  wrote:
> 
> I would like to begin work on implementing NSJSONSerialization. I believe 
> that to get this up and running quickly, it would be prudent to vendor jsmn 
> () within Foundation so we can quickly provide an implementation which will 
> be crucial to web server support, instead of writing our own tokenizer in 
> Swift, though this would definitely be a worthwhile long term goal.
> 
> My questions are:
> 
> Would it be appropriate to vendor this library either as a static lib, or 
> even better, within the target itself?
> Would there be an objection to adding MIT licensed code to the OSS Foundation?
> 
> If the answer to these questions is yes, then I will begin immediately, but 
> I’d like to hear from someone in the core team about it.
> 
> Best,
> 
> Tom

___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

[swift-corelibs-dev] Third party license compatible libraries for JSON

[swizzlr]

I would like to begin work on implementing NSJSONSerialization. I believe that 
to get this up and running quickly, it would be prudent to vendor jsmn () 
within Foundation so we can quickly provide an implementation which will be 
crucial to web server support, instead of writing our own tokenizer in Swift, 
though this would definitely be a worthwhile long term goal.

My questions are:

Would it be appropriate to vendor this library either as a static lib, or even 
better, within the target itself?
Would there be an objection to adding MIT licensed code to the OSS Foundation?

If the answer to these questions is yes, then I will begin immediately, but I’d 
like to hear from someone in the core team about it.

Best,

Tom
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] [swift-evolution] Proposal: Swift Open Source Project and Foundation replacements

[Maxthon Chan]

The thing is, I can, in fact, point out a few libraries I would like to use in 
Swift and as of now you cannot provide it:

GNUstep GUI (AppKit) and UIKit - anything that have GUI in it will need either 
of those libraries, and GNUstep’s version works perfectly under Linux as well 
as Windows.
GNUstep GSWeb (WebObjects) and GDL2 (Enterprise Objects Framework) - Web 
development stack, ain’t this your initial intention of allowing Swift to be 
run on Linux?
GNUstep SimpleWebKit (lightweight Web browser framework, depend on AppKit)
GNUstep Base for Windows (Foundation, but it works under Windows while yours 
currently don’t) - better cross platform capability from the get-go.

And a few other libraries that are nice to have:

CocoaAsyncSocket
Objective-C LINQ
CGIKit (a lightweight replacement for WebObjects) - another Web stack

Also by maintaining Objective-C compatibility means you can free yourself from 
the burden of maintaining any runtime libraries except the Swift standard 
library itself, as it would allow you to offload Foundation and all other 
supporting libraries to other, existing, Objective-C-based projects, like 
GNUstep.

> On Dec 4, 2015, at 21:39, Adrian Kashivskyy  wrote:
> 
>> Removing Objective-C compatibility in Swift (which does not even have a 
>> complete set of libraries yet) in this stage would undermine its usability 
>> and the completeness of the libraries, and when the project finally matured 
>> a bad reputation of “incomplete support” would already be out there, 
>> hampering its use.
> 
> Could you point out five Objective-C Linux libraries (apart from GNU 
> Foundation) that you'd like to use in your Swift projects on Linux? I suspect 
> you can't and that's why I strongly disagree. You only need Objective-C on 
> Apple platforms – and that's not going away. 
> 
> Maintaining Objective-C interoperability for non-Apple platforms is a very 
> niche aim and could potentially lead to longer development and evolvement 
> process. That's a reasonable tradeoff.
> 
> Pozdrawiam – Regards,
> Adrian Kashivskyy
> 
>> Wiadomość napisana przez Maxthon Chan > > w dniu 04.12.2015, o godz. 11:54:
>> 
>> Let’s take a look at C# which Microsoft designed to replace C++ MFC. The 
>> compatibility is never removed although C# itself is pretty complete 
>> already. During early days (2002) lots of components in C# are stubs calling 
>> back to MFC but nevertheless this presented a more or less complete library 
>> set to the user and allowed the language to gain traction - so many traction 
>> that now people demand it to be ported to multiple platforms.
>> 
>> Removing Objective-C compatibility in Swift (which does not even have a 
>> complete set of libraries yet) in this stage would undermine its usability 
>> and the completeness of the libraries, and when the project finally matured 
>> a bad reputation of “incomplete support” would already be out there, 
>> hampering its use.
>> 
>>> On Dec 4, 2015, at 18:33, Alex Blewitt >> > wrote:
>>> 
>>> A more interesting question would be: is Swift designed to ultimately 
>>> replace Objective-C? If so, baking in compatibility from the outset of the 
>>> open source version would probably be going in the wrong direction.
>>> 
>>> Alex
>>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolut...@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 



smime.p7s
Description: S/MIME cryptographic signature
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] [xctest] Who tests the tests?

[Mike Ferris]

One possible direction to consider which would be more consistent with our 
goals this year for API-compatibility would be to look into implementing 
XCTestObserver.

Mike

> On Dec 3, 2015, at 8:03 PM, Tony Parker  wrote:
> 
> Hi Brian,
> 
>> On Dec 3, 2015, at 3:45 PM, Brian Gesiak > > wrote:
>> 
>> Hello! This is in reference to 
>> https://github.com/apple/swift-corelibs-xctest/pull/3 
>> . That pull request 
>> contains a commit that attempts to refactor XCTest such that it is more 
>> "unit-testable”.
>> 
> 
> Cool, thanks for looking into this area.
> 
>> To do so, it gives XCTMain an additional parameter: a list of objects 
>> conforming to the Reporter protocol. I think of this as a minimal, corelibs 
>> equivalent to Apple's XCTest's XCTestObserver.h. I say "minimal" because 
>> Reporter only defines Reporter.log(), whereas XCTestObserver has one method 
>> for each kind of test event (started, failed, finished, etc.).
>> 
> 
> Do you think it’d be possible to split out the idea of adding this new API to 
> XCTest from getting some tests for XCTest itself?
> 
> The reason I’m asking is that (like Foundation and dispatch), we’re trying to 
> keep the API surface of this XCTest very similar to the one that ships today 
> with Xcode. This will help developers who need to integrate their 
> cross-platform tests into suites that include features that Obj-C XCTest has 
> that we will probably not add to the Swift one (e.g., UI testing).
> 
> We made a concession to language limitations with the XCTMain function, 
> because there is no way to dynamically discover all of the test cases. I’d 
> really like to get rid of it in the long term in favor of something else; 
> maybe a decoration like @testable that we could find automatically.
> 
> - Tony
> 
>> These reporters are, for now, storied in a global array. In the future, I'd 
>> like to discuss moving XCTest to a model in which all tests are (optionally) 
>> run in sub-processes, each of which may (optionally) run in parallel. This 
>> global array most certainly won't work for such a change, but for now, I 
>> simply want to have regression tests on the project. It's hard to send pull 
>> requests without knowing everything still works!
>> 
>> Besides this approach, which modifies XCTest in order to test it, it may be 
>> more prudent to add tests *without* changing XCTest at all. To do so, I 
>> could add tests that run programs that call XCTMain(), then verify what's 
>> printed to stdout. This could be done using a Python script (which would go 
>> well with the build script, also in Python).
>> 
>> I'd love input on which of these approaches sounds more viable. Other ideas 
>> are also, of course, welcome!
>> 
>> - Brian Gesiak
> 
> 
> 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] [swift-evolution] Proposal: Swift Open Source Project and Foundation replacements

[Maxthon Chan]

Let’s take a look at C# which Microsoft designed to replace C++ MFC. The 
compatibility is never removed although C# itself is pretty complete already. 
During early days (2002) lots of components in C# are stubs calling back to MFC 
but nevertheless this presented a more or less complete library set to the user 
and allowed the language to gain traction - so many traction that now people 
demand it to be ported to multiple platforms.

Removing Objective-C compatibility in Swift (which does not even have a 
complete set of libraries yet) in this stage would undermine its usability and 
the completeness of the libraries, and when the project finally matured a bad 
reputation of “incomplete support” would already be out there, hampering its 
use.

> On Dec 4, 2015, at 18:33, Alex Blewitt  wrote:
> 
> A more interesting question would be: is Swift designed to ultimately replace 
> Objective-C? If so, baking in compatibility from the outset of the open 
> source version would probably be going in the wrong direction.
> 
> Alex
> 
>> On 4 Dec 2015, at 11:12, ChanMaxthon > > wrote:
>> 
>> Then just please leave some stub there so communities can plug their own 
>> bridging into Swift gracefully (that is, not as an out-of-tree patch)
>> 
>> My idea:
>> 
>> 1) a pure C header file, swift-compat.h describing the interface the 
>> community-provided bridging mechanism should implement besides 
>> objc/runtime.h, objc/message.h and objc/objc-arc.h, and the associated 
>> documentation describing what the community should do, in a even more 
>> liberal license like MIT or 3c/BSD
>> 2) The build system checking for a compatible, community-provided 
>> libswift-compat.so during compilation and enable the community-provided 
>> bridging mechanism if present.
>> 3) Compile-time issues can be solved similarly using libswift-repl-compat.so
>> 
>> When building Swift without a compatible community-provided Foundation 
>> reimplementation present everything here will be built, like what we are 
>> doing here. When building with such a library set and the corresponding 
>> libswift-compat.so present only the Swift standard library will be built, 
>> linking to the community-provided Objective-C runtime (which is also used as 
>> the Swift runtime through the Objective-C bridge) and take advantage of the 
>> community-provided Foundation framework through bridging.
>> 
>> Sent from my iPhone
>> 
>> On Dec 4, 2015, at 16:14, David Hart > > wrote:
>> 
>>> The improvements to the Objective-C bridge in Swift 3 are definitely 
>>> appreciated but are just cosmetics (they only affect naming). What about 
>>> the fact that NSURL in your example, being an immutable type, would be 
>>> better represented by a  value type in Swift? Don't misunderstand me, I 
>>> applaud the fact that corelibs exists, and understand that Foundation has a 
>>> lot of great ideas, but I would have preferred seeing it exist as a 
>>> community hobby project instead of an official Swift project and have the 
>>> community instead concentrate on a core library that embraces value types, 
>>> generics, protocols, etc...
>>> 
>>> On 04 Dec 2015, at 00:14, Tony Parker >> > wrote:
>>> 
 Hi David,
 
 Fundamentally, we believe that the Foundation library is part of Swift. We 
 also believe that it would be a mistake to throw out the many years of 
 experience that it brings with it. In areas where there are impedance 
 mismatches between the existing API and what feels “Swifty”, we can 
 improve the API of Foundation to make it as great to use there as it is in 
 Objective-C. The first step of that is our heavy involvement with the 
 Swift 3 naming guidelines here: 
 
 https://swift.org/documentation/api-design-guidelines.html 
 
 
 Hope this helps,
 - Tony
 
> On Dec 3, 2015, at 3:09 PM, David Hart  > wrote:
> 
> Hi Tony,
> 
> Like Jacob, I would have preferred a completely original corelibs library 
> that uses that clean sheet to be as bold in library design as the 
> standard library is. Why would that direction go against the goal of 
> begin "as standards compliant as possible”? it would just mean that Apple 
> Platform developers would have the option of using the Objective-C bridge 
> to talk to Objective-C Foundation or use the “swifter” corelibs.
> 
> David.
> 
>> On 03 Dec 2015, at 23:33, Tony Parker > > wrote:
>> 
>> Hi Jacob,
>> 
>>> On Dec 3, 2015, at 2:23 PM, Jacob Bandes-Storch >> > wrote:
>>> 
>>> On Thu, Dec 3, 2015 at 2:13 PM, Chris Lattner >> > wrote:
>>> 
>>> As others have surmised, the goal for the Swift Foundation project is 
>

[swift-corelibs-dev] Rules on adding dependencies

[Tom Leavy]

I was wondering what the official position on introducing dependencies 
currently is. I would love to contribute an implementation of 
NSJSONSerialization. I already have written a wrapper that uses yajl to take a 
CFDictionaryRef or CFArrayRef and encodes them into CFDataRef or CFStringRef 
JSON values.. Is it acceptable to use yajl and introduce a dependency, or is it 
a goal of the foundation project to supply its own implementation of a JSON 
parser?
This e-mail message is intended only for the named recipient(s) above and is 
covered by the Electronic Communications Privacy Act 18 U.S.C. Section 
2510-2521. This e-mail is confidential and may contain information that is 
privileged or exempt from disclosure under applicable law. If you have received 
this message in error please immediately notify the sender by return e-mail and 
delete this e-mail message from your computer, mobile devices and any cloud 
storage backup systems as well as destroy any printed copy you might have made.

___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] Rules on adding dependencies

[Tony Parker]

Hi Tom,

I believe it’s important for us to keep our dependencies to an absolute minimum 
for the core libraries, since they will be distributed very widely. I would 
prefer to have our own implementation of the JSON parser in Foundation rather 
than use one from another project.

The one from Darwin is about 2k lines of Objective-C (actually, mostly C).

- Tony

> On Dec 4, 2015, at 11:21 AM, Tom Leavy  wrote:
> 
> I was wondering what the official position on introducing dependencies 
> currently is. I would love to contribute an implementation of 
> NSJSONSerialization. I already have written a wrapper that uses yajl to take 
> a CFDictionaryRef or CFArrayRef and encodes them into CFDataRef or 
> CFStringRef JSON values.. Is it acceptable to use yajl and introduce a 
> dependency, or is it a goal of the foundation project to supply its own 
> implementation of a JSON parser?
> This e-mail message is intended only for the named recipient(s) above and is 
> covered by the Electronic Communications Privacy Act 18 U.S.C. Section 
> 2510-2521. This e-mail is confidential and may contain information that is 
> privileged or exempt from disclosure under applicable law. If you have 
> received this message in error please immediately notify the sender by return 
> e-mail and delete this e-mail message from your computer, mobile devices and 
> any cloud storage backup systems as well as destroy any printed copy you 
> might have made.
> 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] [xctest] Who tests the tests?

[Mike Ferris]

Oops. It was pointed out to me that XCTestObserver is deprecated. I get it 
confused sometimes with its replacement..  What we’d presumably want to pursue 
adding the the corelibs XCTest is the API from XCTestObservation.h (and 
associated stuff).

Your same questions about the bundle stuff will still apply, though. On the 
other hand, perhaps a partial implementation that at least allowed observation 
starting at the test suites or even just at the test cases would suffice to 
start things off.


Mike

> On Dec 4, 2015, at 9:08 AM, Brian Gesiak  wrote:
> 
> Excellent, thanks for the feedback everyone!
> 
> On Thu, Dec 3, 2015 at 10:39 PM, Daniel Dunbar  > wrote:
>> It should be possible to use an out-of-process model that still uses XCTest 
>> itself to run the tests. For example, in the package manager we have some 
>> tests which spawn the package manager in order to test the end-to-end 
>> behavior. Ideally we would only do this for a small number of tests that 
>> really need this level of testing, and use unit testing for the rest.
> 
> I'll send a pull request with this approach, since I believe it's the
> least invasive to the current API while still getting us regression
> tests for the current implementation. Of course I'd be thrilled if
> someone beats me to it! :)
> 
>> On Dec 3, 2015, at 8:03 PM, Tony Parker > > wrote:
>> The reason I’m asking is that (like Foundation and dispatch), we’re trying 
>> to keep the API surface of this XCTest very similar to the one that ships 
>> today with Xcode. This will help developers who need to integrate their 
>> cross-platform tests into suites that include features that Obj-C XCTest has 
>> that we will probably not add to the Swift one (e.g., UI testing).
> 
> Absolutely agree. Still, once we have regression tests in place, I'd
> love to start a conversation about whether we could provide a Obj-C
> XCTest-compatible API layer on top of some more flexible architecture.
> 
>> On Fri, Dec 4, 2015 at 11:24 AM, Mike Ferris > > wrote:
>> One possible direction to consider which would be more consistent with our 
>> goals this year for API-compatibility would be to look into implementing 
>> XCTestObserver.
> 
> Yes! Very exciting. We'll need to consider how methods like
> `-[XCTestObservation testBundleWillStart:]` map to SwiftXCTest,
> especially considering we don't use NSBundle at all (which I think is
> a great thing). I'll be looking forward to participating in more
> discussions on this mailing list.
> 
> - Brian Gesiak
> 
> 
> On Fri, Dec 4, 2015 at 11:24 AM, Mike Ferris  > wrote:
>> 
>> One possible direction to consider which would be more consistent with our 
>> goals this year for API-compatibility would be to look into implementing 
>> XCTestObserver.
>> 
>> Mike
>> 
>> On Dec 3, 2015, at 8:03 PM, Tony Parker  wrote:
>> 
>> Hi Brian,
>> 
>> On Dec 3, 2015, at 3:45 PM, Brian Gesiak  wrote:
>> 
>> Hello! This is in reference to 
>> https://github.com/apple/swift-corelibs-xctest/pull/3. That pull request 
>> contains a commit that attempts to refactor XCTest such that it is more 
>> "unit-testable”.
>> 
>> 
>> Cool, thanks for looking into this area.
>> 
>> To do so, it gives XCTMain an additional parameter: a list of objects 
>> conforming to the Reporter protocol. I think of this as a minimal, corelibs 
>> equivalent to Apple's XCTest's XCTestObserver.h. I say "minimal" because 
>> Reporter only defines Reporter.log(), whereas XCTestObserver has one method 
>> for each kind of test event (started, failed, finished, etc.).
>> 
>> 
>> Do you think it’d be possible to split out the idea of adding this new API 
>> to XCTest from getting some tests for XCTest itself?
>> 
>> The reason I’m asking is that (like Foundation and dispatch), we’re trying 
>> to keep the API surface of this XCTest very similar to the one that ships 
>> today with Xcode. This will help developers who need to integrate their 
>> cross-platform tests into suites that include features that Obj-C XCTest has 
>> that we will probably not add to the Swift one (e.g., UI testing).
>> 
>> We made a concession to language limitations with the XCTMain function, 
>> because there is no way to dynamically discover all of the test cases. I’d 
>> really like to get rid of it in the long term in favor of something else; 
>> maybe a decoration like @testable that we could find automatically.
>> 
>> - Tony
>> 
>> These reporters are, for now, storied in a global array. In the future, I'd 
>> like to discuss moving XCTest to a model in which all tests are (optionally) 
>> run in sub-processes, each of which may (optionally) run in parallel. This 
>> global array most certainly won't work for such a change, but for now, I 
>> simply want to have regression tests on the project. It's hard to send pull 
>> requests without knowing everything still works!
>> 
>> Besides this approach, w

Re: [swift-corelibs-dev] Rules on adding dependencies

[Tom Leavy]

Hey Tony,

That sounds like a good objective overall, thanks for clarifying. I think you 
guys should write that someplace in the documentation on github (if it hasn’t 
been already)

Thomas Leavy | Wickr Inc.
VP Mobile Applications, Architecture | Newark, NJ


> On Dec 4, 2015, at 2:39 PM, anthony.par...@apple.com wrote:
> 
> Hi Tom,
> 
> I believe it’s important for us to keep our dependencies to an absolute 
> minimum for the core libraries, since they will be distributed very widely. I 
> would prefer to have our own implementation of the JSON parser in Foundation 
> rather than use one from another project.
> 
> The one from Darwin is about 2k lines of Objective-C (actually, mostly C).
> 
> - Tony
> 
>> On Dec 4, 2015, at 11:21 AM, Tom Leavy  wrote:
>> 
>> I was wondering what the official position on introducing dependencies 
>> currently is. I would love to contribute an implementation of 
>> NSJSONSerialization. I already have written a wrapper that uses yajl to take 
>> a CFDictionaryRef or CFArrayRef and encodes them into CFDataRef or 
>> CFStringRef JSON values.. Is it acceptable to use yajl and introduce a 
>> dependency, or is it a goal of the foundation project to supply its own 
>> implementation of a JSON parser?
>> This e-mail message is intended only for the named recipient(s) above and is 
>> covered by the Electronic Communications Privacy Act 18 U.S.C. Section 
>> 2510-2521. This e-mail is confidential and may contain information that is 
>> privileged or exempt from disclosure under applicable law. If you have 
>> received this message in error please immediately notify the sender by 
>> return e-mail and delete this e-mail message from your computer, mobile 
>> devices and any cloud storage backup systems as well as destroy any printed 
>> copy you might have made.
>> 
>> ___
>> swift-corelibs-dev mailing list
>> swift-corelibs-dev@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
> 


This e-mail message is intended only for the named recipient(s) above and is 
covered by the Electronic Communications Privacy Act 18 U.S.C. Section 
2510-2521. This e-mail is confidential and may contain information that is 
privileged or exempt from disclosure under applicable law. If you have received 
this message in error please immediately notify the sender by return e-mail and 
delete this e-mail message from your computer, mobile devices and any cloud 
storage backup systems as well as destroy any printed copy you might have made.
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] Rules on adding dependencies

[Tony Parker]

Good idea, I filed a bug for that here.

https://bugs.swift.org/browse/SR-59 

- Tony

> On Dec 4, 2015, at 12:49 PM, Tom Leavy  wrote:
> 
> Hey Tony,
> 
> That sounds like a good objective overall, thanks for clarifying. I think you 
> guys should write that someplace in the documentation on github (if it hasn’t 
> been already)
> 
> Thomas Leavy | Wickr Inc.
> VP Mobile Applications, Architecture | Newark, NJ
> 
> 
>> On Dec 4, 2015, at 2:39 PM, anthony.par...@apple.com wrote:
>> 
>> Hi Tom,
>> 
>> I believe it’s important for us to keep our dependencies to an absolute 
>> minimum for the core libraries, since they will be distributed very widely. 
>> I would prefer to have our own implementation of the JSON parser in 
>> Foundation rather than use one from another project.
>> 
>> The one from Darwin is about 2k lines of Objective-C (actually, mostly C).
>> 
>> - Tony
>> 
>>> On Dec 4, 2015, at 11:21 AM, Tom Leavy  wrote:
>>> 
>>> I was wondering what the official position on introducing dependencies 
>>> currently is. I would love to contribute an implementation of 
>>> NSJSONSerialization. I already have written a wrapper that uses yajl to 
>>> take a CFDictionaryRef or CFArrayRef and encodes them into CFDataRef or 
>>> CFStringRef JSON values.. Is it acceptable to use yajl and introduce a 
>>> dependency, or is it a goal of the foundation project to supply its own 
>>> implementation of a JSON parser?
>>> This e-mail message is intended only for the named recipient(s) above and 
>>> is covered by the Electronic Communications Privacy Act 18 U.S.C. Section 
>>> 2510-2521. This e-mail is confidential and may contain information that is 
>>> privileged or exempt from disclosure under applicable law. If you have 
>>> received this message in error please immediately notify the sender by 
>>> return e-mail and delete this e-mail message from your computer, mobile 
>>> devices and any cloud storage backup systems as well as destroy any printed 
>>> copy you might have made.
>>> 
>>> ___
>>> swift-corelibs-dev mailing list
>>> swift-corelibs-dev@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
>> 
> 
> 
> This e-mail message is intended only for the named recipient(s) above and is 
> covered by the Electronic Communications Privacy Act 18 U.S.C. Section 
> 2510-2521. This e-mail is confidential and may contain information that is 
> privileged or exempt from disclosure under applicable law. If you have 
> received this message in error please immediately notify the sender by return 
> e-mail and delete this e-mail message from your computer, mobile devices and 
> any cloud storage backup systems as well as destroy any printed copy you 
> might have made.

___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] Will the Portability Stack include KVC/KVO support?

[Tony Parker]

Hi Benoit,

KVO and KVC rely heavily on the presence of the Objective-C runtime (for 
example, sometimes creating new subclasses for objects out of thin air). We’re 
not sure yet how or if we want to implement that functionality. 

In the meantime, filing a bug at bugs.swift.org would be a great way to make 
sure we all have something to keep an eye on.

Thanks,
- Tony

> On Dec 4, 2015, at 2:59 AM, Benoit Pereira da silva  wrote:
> 
> Dear all,
> 
> Will the Portability Stack include KVC/KVO support?
> If not what could be the best alternative?
> 
> Benoit 
> 
> 
> Benoit Pereira da Silva
> Ultra Mobile Developer & Movement Activist
> Développeur Ultra Mobile & Militant du mouvement
> Site : http://pereira-da-silva.com 
> 
> 
> 
> 
> 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] Rules on adding dependencies

[Tom Leavy]

Thanks!

Is there a list of current dependencies someplace? I understand you use a 
specific version of ICU as part of CoreFoundation.

Thomas Leavy | Wickr Inc.
VP Mobile Applications, Architecture | Newark, NJ


On Dec 4, 2015, at 3:52 PM, 
anthony.par...@apple.com wrote:

Good idea, I filed a bug for that here.

https://bugs.swift.org/browse/SR-59

- Tony

On Dec 4, 2015, at 12:49 PM, Tom Leavy mailto:t...@wickr.com>> 
wrote:

Hey Tony,

That sounds like a good objective overall, thanks for clarifying. I think you 
guys should write that someplace in the documentation on github (if it hasn’t 
been already)

Thomas Leavy | Wickr Inc.
VP Mobile Applications, Architecture | Newark, NJ


On Dec 4, 2015, at 2:39 PM, 
anthony.par...@apple.com wrote:

Hi Tom,

I believe it’s important for us to keep our dependencies to an absolute minimum 
for the core libraries, since they will be distributed very widely. I would 
prefer to have our own implementation of the JSON parser in Foundation rather 
than use one from another project.

The one from Darwin is about 2k lines of Objective-C (actually, mostly C).

- Tony

On Dec 4, 2015, at 11:21 AM, Tom Leavy mailto:t...@wickr.com>> 
wrote:

I was wondering what the official position on introducing dependencies 
currently is. I would love to contribute an implementation of 
NSJSONSerialization. I already have written a wrapper that uses yajl to take a 
CFDictionaryRef or CFArrayRef and encodes them into CFDataRef or CFStringRef 
JSON values.. Is it acceptable to use yajl and introduce a dependency, or is it 
a goal of the foundation project to supply its own implementation of a JSON 
parser?
This e-mail message is intended only for the named recipient(s) above and is 
covered by the Electronic Communications Privacy Act 18 U.S.C. Section 
2510-2521. This e-mail is confidential and may contain information that is 
privileged or exempt from disclosure under applicable law. If you have received 
this message in error please immediately notify the sender by return e-mail and 
delete this e-mail message from your computer, mobile devices and any cloud 
storage backup systems as well as destroy any printed copy you might have made.

___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev



This e-mail message is intended only for the named recipient(s) above and is 
covered by the Electronic Communications Privacy Act 18 U.S.C. Section 
2510-2521. This e-mail is confidential and may contain information that is 
privileged or exempt from disclosure under applicable law. If you have received 
this message in error please immediately notify the sender by return e-mail and 
delete this e-mail message from your computer, mobile devices and any cloud 
storage backup systems as well as destroy any printed copy you might have made.



This e-mail message is intended only for the named recipient(s) above and is 
covered by the Electronic Communications Privacy Act 18 U.S.C. Section 
2510-2521. This e-mail is confidential and may contain information that is 
privileged or exempt from disclosure under applicable law. If you have received 
this message in error please immediately notify the sender by return e-mail and 
delete this e-mail message from your computer, mobile devices and any cloud 
storage backup systems as well as destroy any printed copy you might have made.
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] swift-corelibs-dev Digest, Vol 1, Issue 18

[swizzlr]

is e-mail is confidential and may contain information that is 
> privileged or exempt from disclosure under applicable law. If you have 
> received this message in error please immediately notify the sender by return 
> e-mail and delete this e-mail message from your computer, mobile devices and 
> any cloud storage backup systems as well as destroy any printed copy you 
> might have made.
> 
> 
> 
> This e-mail message is intended only for the named recipient(s) above and is 
> covered by the Electronic Communications Privacy Act 18 U.S.C. Section 
> 2510-2521. This e-mail is confidential and may contain information that is 
> privileged or exempt from disclosure under applicable law. If you have 
> received this message in error please immediately notify the sender by return 
> e-mail and delete this e-mail message from your computer, mobile devices and 
> any cloud storage backup systems as well as destroy any printed copy you 
> might have made.
> -- next part --
> An HTML attachment was scrubbed...
> URL: 
> <https://lists.swift.org/pipermail/swift-corelibs-dev/attachments/20151204/3b3aa317/attachment-0001.html>
> 
> --
> 
> Message: 2
> Date: Fri, 04 Dec 2015 13:09:09 -0800
> From: Tony Parker 
> To: Tom Leavy 
> Cc: "swift-corelibs-dev@swift.org" 
> Subject: Re: [swift-corelibs-dev] Rules on adding dependencies
> Message-ID: <1d8fa53c-37cd-4653-8bdd-6c9f6dee5...@apple.com>
> Content-Type: text/plain; charset="utf-8"
> 
> 
>> On Dec 4, 2015, at 1:01 PM, Tom Leavy  wrote:
>> 
>> Thanks!
>> 
>> Is there a list of current dependencies someplace? I understand you use a 
>> specific version of ICU as part of CoreFoundation.
>> 
> 
> The best source of this info is going to be the build.py file and Xcode 
> project.
> 
> You are correct that on Apple platforms we use a specific version of ICU 
> (which is itself open source, on opensource.apple.com). For now, on Linux, we 
> try to use the installed one. There are certainly some areas where we require 
> the functionality provided by the Apple ICU but we have just omitted those 
> from the build on Linux for the time being (look for __HAS_APPLE_ICU__ in 
> CF). Eventually we’ll have to figure out a unified story for this.
> 
> - Tony
> 
>> Thomas Leavy | Wickr Inc.
>> VP Mobile Applications, Architecture | Newark, NJ
>> 
>> 
>>> On Dec 4, 2015, at 3:52 PM, anthony.par...@apple.com 
>>> <mailto:anthony.par...@apple.com> wrote:
>>> 
>>> Good idea, I filed a bug for that here.
>>> 
>>> https://bugs.swift.org/browse/SR-59 <https://bugs.swift.org/browse/SR-59>
>>> 
>>> - Tony
>>> 
>>>> On Dec 4, 2015, at 12:49 PM, Tom Leavy >>> <mailto:t...@wickr.com>> wrote:
>>>> 
>>>> Hey Tony,
>>>> 
>>>> That sounds like a good objective overall, thanks for clarifying. I think 
>>>> you guys should write that someplace in the documentation on github (if it 
>>>> hasn’t been already)
>>>> 
>>>> Thomas Leavy | Wickr Inc.
>>>> VP Mobile Applications, Architecture | Newark, NJ
>>>> 
>>>> 
>>>>> On Dec 4, 2015, at 2:39 PM, anthony.par...@apple.com 
>>>>> <mailto:anthony.par...@apple.com> wrote:
>>>>> 
>>>>> Hi Tom,
>>>>> 
>>>>> I believe it’s important for us to keep our dependencies to an absolute 
>>>>> minimum for the core libraries, since they will be distributed very 
>>>>> widely. I would prefer to have our own implementation of the JSON parser 
>>>>> in Foundation rather than use one from another project.
>>>>> 
>>>>> The one from Darwin is about 2k lines of Objective-C (actually, mostly C).
>>>>> 
>>>>> - Tony
>>>>> 
>>>>>> On Dec 4, 2015, at 11:21 AM, Tom Leavy >>>>> <mailto:t...@wickr.com>> wrote:
>>>>>> 
>>>>>> I was wondering what the official position on introducing dependencies 
>>>>>> currently is. I would love to contribute an implementation of 
>>>>>> NSJSONSerialization. I already have written a wrapper that uses yajl to 
>>>>>> take a CFDictionaryRef or CFArrayRef and encodes them into CFDataRef or 
>>>>>> CFStringRef JSON values.. Is it acceptable to use yajl and introduce a 
>>>>>> dependency, or is it a goal of the foundation project to supply its own 

[swift-corelibs-dev] New contributions document

[Tony Parker]

Hi everyone,

Thank you so much for your interest in the Core Libraries over the first 2 
days! Your response to the release has been overwhelming, and we’re really 
looking forward to working with you on this project going forward.

I quickly realized that we needed to clarify some of the process that we want 
to use for accepting contributions, so I put a new CONTRIBUTING.md file in 
swift-corelibs-foundation to outline it. The summary is that we follow the 
Swift process, outlined at Swift.org here: https://swift.org/contributing/

We have a few additional things to think about, which I’ve written up in the 
document. Specifically, I want to make sure we follow the swift-evolution 
process for API changes in the project. I’m going to go through some of our 
pull requests that propose change to public API and note that we should discuss 
it here and on the swift-evolution list before proceeding with a code pull.

Thanks again,
- Tony

___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev