> On 20. Dec 2017, at 22:30, Slava Pestov via swift-evolution 
> <swift-evolution@swift.org> wrote:
> Hi Karl,
> This is an interesting idea and part of something we would like to explore in 
> the future, which is resilience domains that span more than one module.
> However keep in mind that in the current design, resilience is something you 
> opt into when building a library, with a compiler flag. If you don’t pass the 
> flag, there’s no additional indirection, and the flag is off by default.
> Note that this does not apply to exhaustive enums — we would like those to 
> always be non-exhaustive by default because we don’t want a compiler flag 
> changing language semantics. However, they will be compiled as if they are 
> exhaustive, meaning the compiler can assume the enum has a fixed layout from 
> the client binary.

It’s good to hear that resilience will be off by default in the compiled 
product, even if it will be on by default in the language.

I appreciate not wanting to have the language semantics diverge, but the thing 
about exhaustive enums are that (IMO) it’s intrinsically a resilience 
attribute. It’s about making accommodations for cases which aren’t written in 
the enum at compile-time. Is it really divergent to say that all types imported 
from a @static import are assumed to be a fixed version, but it’s not divergent 
to allow @testable to violate access control? It’s written in your code; it 
becomes part of the language semantics. Some of the stuff we’ve been discussing 
here (*ahem* DynamicLookupThingy) are far dodgier than this in terms of 
consistency of language semantics.

@Charles: As for mixing static/non-static imports - I figured a regular import 
would also work with a module compiled to allow static imports. It just 
wouldn’t _require_ it (and wouldn’t allow you to assume the module is a fixed 

- Karl

> Slava
>> On Dec 20, 2017, at 6:56 AM, Karl Wagner via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> There’s a lot of talk in the non-exhaustive enum discussion about the source 
>> transition. So let me suggest a possible solution: @static imports.
>> Basically, it seems to me like resilience is going to introduce a lot of 
>> indirection, both in generated instructions and in the language. I think 
>> that making resilience opt-in on a declaration-by-declaration basis would 
>> make it difficult for average programmers to get right, so I support the 
>> idea of making Swift libraries resilient-by-default with opt-out abilities 
>> when it is obvious from the perspective of the library author that it should 
>> be so.
>> However, Apps are not libraries. Whereas libraries are a kind of theoretical 
>> block of code, and you naturally want them to be adaptable to different 
>> circumstances, Apps are the concrete things which actually use them. They 
>> might have a different perspective on what can be allowed to be 
>> non-resilient. Just like an App may be built to be compatible with a 
>> particular version of a library, I think it’s reasonable for it to be built 
>> expecting other “flavours” of the library, too - including a non-resilient 
>> flavour. We already kind of have something like this: executables can import 
>> modules as @testable, and those modules are required to be built with the 
>> “-enable-testing” flag.
>> My suggestion is that we create a new kind of import mode, "@static import" 
>> and some corresponding compiler flag. When you import a module using 
>> @static, you tell the compiler that your App requires exactly the module 
>> which it is being compiled alongside. When compiling your regular, 
>> resilient-by-default Swift libraries with the special flag, they will be 
>> transformed to fix them at their current version and provide later stages of 
>> the compiler as much information as if it was within the same module (i.e. 
>> applying final, @exhaustive, providing complete SIL, etc). App code will not 
>> be able to access “internal” members of the @static library (even though the 
>> compiler can see them). We might allow the same attribute to be applied to 
>> static libraries from C, which can be similarly freed of resilience concerns.
>> That would help ease code migration - for this and future resilience-related 
>> changes - because you’ll basically get the Swift 4 behaviour back for 
>> libraries which you control.
>> // Regular imports. We don’t control these libraries.
>> import Foundation
>> import UIKit
>> // Static imports. We control these; they will be embedded in the final 
>> product in some way. Everything is @exhaustive!
>> @static import MyDataModel
>> @static import SharedUIElements
>> - Karl
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

swift-evolution mailing list

Reply via email to