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 <da...@hartbit.com> 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 <anthony.par...@apple.com> 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 <da...@hartbit.com> 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 <anthony.par...@apple.com> wrote: >>>>> >>>>> Hi Jacob, >>>>> >>>>> On Dec 3, 2015, at 2:23 PM, Jacob Bandes-Storch <jtban...@gmail.com> >>>>> wrote: >>>>> >>>>>> On Thu, Dec 3, 2015 at 2:13 PM, Chris Lattner <clatt...@apple.com> 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-evolution mailing list > swift-evolut...@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
