[swift-corelibs-dev] SR-6405: URLRequest does not capitalise HTTP methods

[Stephen Celis]

> On Nov 16, 2017, at 2:57 PM, Alex Blewitt <alblue at apple.com> wrote:
> 
> I understood your question, but I can only point to you as to what is available and run on the swift-corelibs-foundation open source project.

Sorry to continue on this train (especially since it’s a big of a derailment). I’m really not trying to be obtuse, but I don’t understand your answer. I was asking what I thought were simple yes/no questions that didn’t require any private/confidential information about the closed source code. Do you or does anyone else know if the open-source project has a test target that runs its test suite against the closed-source implementation? If not, shouldn’t it?

I read your first response as: swift-corelibs-foundation has a test suite that runs against its own implementation. Am I missing something?

> Yes, being consistent between platforms is one of the purposes of the swift-corelibs-foundation project. However, there are both run-time and implementation differences between the two platforms; the existence (or not) of the Objective-C runtime, whether or not comparisons are performed using the rules based on the Darwin version of Foundation or the ICU rules on the open-source version of Foundation, and so on.

I understand this, but I’m not talking about run-time/implementation differences, just testable input/output expectations on the functions and methods that swift-corelibs-foundation can implement. Assuming that the functions and methods swift-corelibs-foundation can implement should behave the same, its test suite should be able to run against Darwin Foundation.

> Some of the differences are just bugs, in which case we can try and resolve the issues when they're filed at bugs.swift.org <http://bugs.swift.org/> or via pull requests on the GitHub repository. Some of the issues are ones where the implementation in the open source version is missing; either because the functionally cannot be implemented (e.g. dynamic unloading of bundles) or because it's not been prioritised yet (e.g. https://github.com/apple/swift-corelibs-foundation/search?utf8=✓&q=nsunimplemented <https://github.com/apple/swift-corelibs-foundation/search?utf8=%E2%9C%93&q=nsunimplemented>). In particular the big items that are missing at the moment are encoder/decoder implementations and those relating to nspredicate/expression, which both can be implemented in runtimes that have dynamic introspection of data structures but which therefore can't be implemented in Linux.
> 
> Having said that, if you do find consistency issues which are important to you then please file bugs, and optionally provide pull requests for them. We can help on the mailing list to try and resolve any issues or questions as they arise.

I totally have been and will continue to! I was hopeful that we could discuss a system that automates some of this and can catch regressions and inconsistencies more quickly. Is there any reason not to discuss such a solution?

Stephen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-corelibs-dev/attachments/20171116/82b37a5b/attachment.html>