> 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 version). - 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 swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
