Re: [swift-evolution] [Pitch] @static imports

[Karl Wagner via swift-evolution]

> On 20. Dec 2017, at 22:30, Slava Pestov via swift-evolution 
>  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 
>> 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 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailin

Re: [swift-evolution] [Pitch] @static imports

[Charles Srstka via swift-evolution]

> On Dec 20, 2017, at 8:56 AM, Karl Wagner via swift-evolution 
>  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
> https://lists.swift.org/mailman/listinfo/swift-evolution

What happens if you have two source files in a project that both import the 
same library, one with @static on the import, and one without?

Charles

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] @static imports

[Slava Pestov via swift-evolution]

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.

Slava

> On Dec 20, 2017, at 6:56 AM, Karl Wagner via swift-evolution 
>  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
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution