> On Dec 22, 2015, at 10:03 AM, marc hoffman via swift-evolution > <[email protected]> wrote: > > Thanx! > > i understand it’s internal, but i’m asking because i work on > http://www.elementscompiler.com/silver, and eventually we’d love to be able > to compile parts of the standard library ourselves ;)
Given the deep dependence in our standard library on LLVM primitives and semantics, as well as the rather messy interactions between our compiler, stdlib, and runtime in general, I'm not sure that's a practical goal. Maybe if there were a better-factored 'core' that defined the basic interfaces in terms of the substrate, giving you Int/String/etc. in terms of LLVM/CLR/JavaScript/WebAssembly/whatever primitives, that was isolated from the higher-level parts of the stdlib, but that's a sizable effort in itself. I know you all already define your own versions of stdlib interfaces in terms of common .NET/JVM abstractions, and change semantics in many places as a result. -Joe > —marc > >> On Dec 22, 2015, at 11:29 AM, Joe Groff <[email protected]> wrote: >> >> >>> On Dec 22, 2015, at 7:26 AM, marc hoffman via swift-evolution >>> <[email protected]> wrote: >>> >>> Joe, >>> >>> quick side question: is @_transparent documented somewhere? I’ve seen it in >>> the standard library source code, but i cannot see out covered in any of >>> the docs… >> >> It's not publicly documented, because it's intended to be an implementation >> detail. It only really works within the standard library, and is likely to >> be replaced by our proper resilience model for cross-module inlining. Check >> out docs/TransparentAttr.rst for the internal documentation. >> >> -Joe > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
