[swift-dev] how much of non-Swift in Swif

[Alex Blewitt]

> On 6 Sep 2017, at 10:26, blaster_in_black via swift-dev <swift-dev at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20170906/de18e525/attachment.html>