> On 13 May 2016, Erica Sadun wrote:
>
>> As per Pyry’s feedback, you could add a version:
>>
>> #if import Frobnication(<1.7.3) // <- Only added version constraint here.
>> extension Knob : Frobnicatable { ... }
>> #endif
>
> I have no problem with this but would need to defer to the build and
> On May 13, 2016, at 1:42 AM, Patrick Smith wrote:
>
>> canImport (or whatever it ends up being called) is deliberate.
>>
>> You test before you import:
>>
>> #if canImport(x)
>> import x
>> #else
>> ...
>> #endif
>>
>> and you test at the use-site
>>
>> #if canImport(x)
>> // use things
I can’t decide if this would be a good idea or not? I can see pluses and
minuses!
+
Consistent.
One way to remember to work with modules.
Reinforces the rule that if you want to work with a module, you want to import
it.
-
Could get confusing exactly where things are being imported, but you can
Well my idea also included module(X), modelled after the os() function, e.g.
#if os(OSX)
#if import UIKit
// Some UIKit-related declarations
#endif
// Later in the same file
func f() {
#if module(UIKit)
// Use UIKit-only declarations
#endif
}
Looking forw
> Le 13 mai 2016 à 11:05, Pyry Jahkola a écrit :
>
>> Gwendal Roué wrote:
>>
>> `#if import Foo` can not deal with the fact that a single source file may
>> have to perform the importability test several times.
>
> This would be less of a problem if conditional imports like that worked
> loc
> Gwendal Roué wrote:
>
> `#if import Foo` can not deal with the fact that a single source file may
> have to perform the importability test several times.
This would be less of a problem if conditional imports like that worked locally
in all scopes of code, so you could write just
func fo
Hello,
`#if import Foo` can not deal with the fact that a single source file may have
to perform the importability test several times.
For example:
#if canImport(UIKit)
import UIKit
// Some UIKit-related declarations
#endif
// Later in the
Patrick,
I think you're making valuable points here. I also can't think of cases where
you wouldn't also import a module in case it was found to be importable. So the
use cases I can think of could as well be tackled by allowing expressions such
as `import Foo.Bar` as compile-time checks within
> canImport (or whatever it ends up being called) is deliberate.
>
> You test before you import:
>
> #if canImport(x)
>import x
> #else
> ...
> #endif
>
> and you test at the use-site
>
> #if canImport(x)
> // use things that are available in x
> #else
> ...
>
> So you don't import UIKit
* What is your evaluation of the proposal?
+1.
It attacks a real problem that is met regularly when working on multi-platform
code.
I also like `canImport`. As it’s gonna be used mostly after #if, the whole
statement becomes very readable.
* Is the problem being addressed significant enough
> The review of "SE-0075: Adding a Build Configuration Import Test" begins now
> and runs through May 16. The proposal is available here:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0075-import-test.md
>
> * What is your evaluation of the proposal?
+1, I th
> On May 12, 2016, at 7:30 PM, Dany St-Amant via swift-evolution
> wrote:
>
>
>> On May 10, 2016, at 2:49 PM, Chris Lattner via swift-evolution
>> wrote:
>>
>> Hello Swift community,
>>
>> The review of "SE-0075: Adding a Build Configuration Import Test" begins now
>> and runs through May
> On May 10, 2016, at 2:49 PM, Chris Lattner via swift-evolution
> wrote:
>
> Hello Swift community,
>
> The review of "SE-0075: Adding a Build Configuration Import Test" begins now
> and runs through May 16. The proposal is available here:
>
>
> https://github.com/apple/swift-evolution/bl
> * What is your evaluation of the proposal?
>
+1, solves a useful problem on the horizon.
> * Is the problem being addressed significant enough to warrant a
> change to Swift?
>
Yes.
> * Does this proposal fit well with the feel and direction of Swift?
>
Yes. Althoug
> * What is your evaluation of the proposal?
I think the proposal is worthwhile and I see myself using those when writing
multiplatform code. I agree that they are much less brittle than os tests.
> * Is the problem being addressed significant enough to warrant a change
> to Swift?
Hello Swift community,
The review of "SE-0075: Adding a Build Configuration Import Test" begins now
and runs through May 16. The proposal is available here:
https://github.com/apple/swift-evolution/blob/master/proposals/0075-import-test.md
Reviews are an important part of the Swift evo
16 matches
Mail list logo
