> On 6 Sep 2017, at 10:26, blaster_in_black via swift-dev <swift-dev@swift.org>
> wrote:
>
> 1) How much and what types of interfaces with non-Swift code is there in the
> standard library and the runtime? I have seen references to the "Builtin"
> class, that as I understand is directly implemented in LLVM IR language, and
> also calls to C++ functions ("SwiftShims" is full of that). Is there any more
> "boundary" with non-Swift parts of the implementation?
The "Builtin" comes from a number of different places, e.g.:
https://github.com/apple/swift/blob/master/include/swift/AST/Builtins.def
<https://github.com/apple/swift/blob/master/include/swift/AST/Builtins.def>
https://github.com/apple/swift/blob/master/lib/AST/Builtins.cpp
<https://github.com/apple/swift/blob/master/lib/AST/Builtins.cpp>
They aren't directly implemented in LLVM IR as such, but rather the parser
replaces uses of Builtin.Word with the appropriate type via
SILType::getBuiltinWordType and BuiltinIntegerType::getWordType.
Normally these aren't accessible to Swift programs, but if you compile with
-parse-stdlib you can see what effect it has on the generated output. Looking
at the -emit-sil is an interesting way of seeing what is produced. (You can
also use a GUI tool I wrote called SILInspector, which runs the commands and
hosts them in a text field for ease of use.)
The SwiftShims are a set of additional functions that allow C functions to be
exposed as platform-independent Swift functions:
https://github.com/apple/swift/tree/9354a93b1861efe14c4a72fd581c746b48334ccc/stdlib/public/SwiftShims
<https://github.com/apple/swift/tree/9354a93b1861efe14c4a72fd581c746b48334ccc/stdlib/public/SwiftShims>
https://github.com/apple/swift/blob/9354a93b1861efe14c4a72fd581c746b48334ccc/stdlib/public/SwiftShims/LibcShims.h
<https://github.com/apple/swift/blob/9354a93b1861efe14c4a72fd581c746b48334ccc/stdlib/public/SwiftShims/LibcShims.h>
> 2) Are you aware of any project out there that aims to minimize, or at least
> make more consistent, the amount of references to non-Swift functions and
> types in the standard library? I know about Pure Swift's "SwiftFoundation"
> and other artifacts of them, but as far as I know they do not dig into the
> standard library.
I'm not sure what question you are asking here. If you are asking "Is there a
desire or goal to move away from C based functions into Swift functions" then
the answer is likely to be no; some of the functions need to be implemented in
C because they are platform specific or use e.g. C++ like namespaces, and the
bulk of the compiler and intrinsics are written in C++ already.
Foundation, on the other hand, has a number of C functions that have been
inherited from the Darwin codebase, which has a collection of C underlying
concepts and then higher level wrappers. While it would be technically possible
to rewrite working code with other working code, the focus has been on filling
out the gaps in places where there isn't working code at the moment. In
addition, it's generally unproductive to rewrite working and tested code with
new code unless there's a specific reason (speed, portability, security) to do
so.
Alex
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
