[swift-users] plugins, verifiable code?

[Austin Zheng]

Hi Robert,

To my knowledge, nothing like this has been seriously proposed. You may want to mail the swift-evolution at swift.org list and start a discussion there.

I think a good way to approach your objectives might be for Swift to adopt some sort of taint analysis-like checking, much like what Rust does with its 'unsafe' keyword. The idea being that certain things, like a function which invokes a C function or unsafe direct access to memory, would be marked as 'unsafe', and anything using an 'unsafe' thing would itself become 'unsafe'. A library that is 'safe' at the top level would be guaranteed not to segfault, call C code, or do many other things that could cause issues.

Best,
Austin

https://doc.rust-lang.org/book/unsafe.html <https://doc.rust-lang.org/book/unsafe.html>

> On May 25, 2016, at 8:54 PM, Robert Nikander via swift-users <swift-users at swift.org> wrote:
> 
> Hi,
> 
> I’m thinking about creating an OS X app with dynamically loaded plugins. I hear that it’s safest to load plugins in a separate process, so they can’t crash the host program. I haven’t tried this yet, so I’m not sure exactly how it will work. But it got me wondering… has there been any discussion about doing something in Swift like Java’s “verified” code, where you can load a 3rd party plugin and trust that it’s not going to segfault or call some C-library? In other words, no unsafe actions. I’ve seen references to “bitcode” but I don’t know how close that is to JVM bytecode.  And maybe this idea is incompatible in some way with the guiding principles of Swift.
> 
> Rob
> _______________________________________________
> swift-users mailing list
> swift-users at swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-users/attachments/20160525/b50cf26e/attachment.html>