Re: [swift-evolution] Import Conditionals

[Benjamin Spratling via swift-evolution]

Howdy,

There is already an accepted but not implemented proposal to determine whether 
a module can be imported and conditionally compile accordingly.
https://github.com/apple/swift-evolution/blob/master/proposals/0075-import-test.md

While the accepted change is certainly not as compact as your notation, it has 
the advantage that it supports more functionality.  I could, for example, 
include code in a file for UIKit, Cocoa, WatchKit and ostensibly some Linux UI 
framework depending on my target platform.  If my functionality is intended 
around adding a single consistent feature to a Type in each module, then this 
is how I want to organize my code.

Besides, “||” is so JavaScript.  In Swift it would be “??”, and it would 
potentially need to chain because there are more than 2 supported platforms.

Finally, I don’t see how you handle failure to import a module.  Does compile 
fail, or do you provide your own implementation of the desired functionality?  
When Apple adds a module on one platform but not on another, then I might need 
to write my own implementation for platforms on which it is missing, but depend 
on system integrated performance on the platforms they provide it for.  
“canimport” provides for either using other existing # patterns, but your 
proposal does not.

So I recommend checking out the already-accepted proposal.  But if you still 
need the syntax to get smaller, at least move to “??” so it looks like Swift 
instead of some other language.

-Ben


> On Oct 17, 2016, at 5:05 PM, Sean Alling via swift-evolution 
>  wrote:
> 
> Description
> 
> In an effort to both (1) reduce boilerplate code, and (2) promote 
> cross-platform reusability I propose that we implement the following Import 
> Conditional Operators: 
> 
> `||` and `&&`
> 
> Currently, import conditionals must be implemented like so:
> 
> ```
> #if os(Linux) || os(FreeBSD)
>   import Glibc
> #else
>   import Darwin
> #endif
> ```
> 
> With import conditional operators this would be condensed to:
> 
> ```
> import Glibc || Darwin
> ```
> 
> The first library/framework (Glibc) would be imported if found and the the 
> second (Darwin) only in the event the first should fail.
> 
> Other Caveats:
> 
> (A) —  we could limit this to one conditional operator per import line OR we 
> could implement order of operations. Obviously, there are tradeoffs of both 
> that we should discuss.
> 
> (B) — if-conditional statements currently explicitly show the import 
> conditions (i.e., os(Linux) || os(FreeBSD)) this would be a detriment to this 
> new feature. I would argue that the reduction of boilerplate code would in 
> itself be worth this abstraction.
> 
> 
> --
> Sean Alling
> 
> ___
> 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

Re: [swift-evolution] Import Conditionals

[Karl via swift-evolution]

I disagree. What about when you need to disambiguate?

Currently you’d need to use ‘Darwin.connect(...)’ or ‘Glibc.connect(…)’. 
Merging them both in to one ‘Libc’ module would make that much easier.

> On 18 Oct 2016, at 01:07, Sean Alling via swift-evolution 
>  wrote:
> 
> Yeah I saw that thread. I think (a) this is a better solution and (b) this is 
> applicable for use cases other than specifically Glibc/Darwin.
> 
> -Sean
> 
> Sent from my iPhone
> 
> On Oct 17, 2016, at 19:01, Saagar Jha  > wrote:
> 
>> I believe there was a draft to merge all the "Libc" modules; let me see if I 
>> can find that.
>> 
>> On Mon, Oct 17, 2016 at 3:06 PM Sean Alling via swift-evolution 
>> > wrote:
>> Description
>> 
>> In an effort to both (1) reduce boilerplate code, and (2) promote 
>> cross-platform reusability I propose that we implement the following Import 
>> Conditional Operators: 
>> 
>> `||` and `&&`
>> 
>> Currently, import conditionals must be implemented like so:
>> 
>> ```
>> #if os(Linux) || os(FreeBSD)
>>  import Glibc
>> #else
>>  import Darwin
>> #endif
>> ```
>> 
>> With import conditional operators this would be condensed to:
>> 
>> ```
>> import Glibc || Darwin
>> ```
>> 
>> The first library/framework (Glibc) would be imported if found and the the 
>> second (Darwin) only in the event the first should fail.
>> 
>> Other Caveats:
>> 
>> (A) —  we could limit this to one conditional operator per import line OR we 
>> could implement order of operations. Obviously, there are tradeoffs of both 
>> that we should discuss.
>> 
>> (B) — if-conditional statements currently explicitly show the import 
>> conditions (i.e., os(Linux) || os(FreeBSD)) this would be a detriment to 
>> this new feature. I would argue that the reduction of boilerplate code would 
>> in itself be worth this abstraction.
>> 
>> 
>> --
>> Sean Alling
>> 
>> ___
>> 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

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

Re: [swift-evolution] Import Conditionals

[Sean Alling via swift-evolution]

Yeah I saw that thread. I think (a) this is a better solution and (b) this is 
applicable for use cases other than specifically Glibc/Darwin.

-Sean

Sent from my iPhone

> On Oct 17, 2016, at 19:01, Saagar Jha  wrote:
> 
> I believe there was a draft to merge all the "Libc" modules; let me see if I 
> can find that.
> 
>> On Mon, Oct 17, 2016 at 3:06 PM Sean Alling via swift-evolution 
>>  wrote:
>> Description
>> 
>> In an effort to both (1) reduce boilerplate code, and (2) promote 
>> cross-platform reusability I propose that we implement the following Import 
>> Conditional Operators: 
>> 
>> `||` and `&&`
>> 
>> Currently, import conditionals must be implemented like so:
>> 
>> ```
>> #if os(Linux) || os(FreeBSD)
>>  import Glibc
>> #else
>>  import Darwin
>> #endif
>> ```
>> 
>> With import conditional operators this would be condensed to:
>> 
>> ```
>> import Glibc || Darwin
>> ```
>> 
>> The first library/framework (Glibc) would be imported if found and the the 
>> second (Darwin) only in the event the first should fail.
>> 
>> Other Caveats:
>> 
>> (A) —  we could limit this to one conditional operator per import line OR we 
>> could implement order of operations. Obviously, there are tradeoffs of both 
>> that we should discuss.
>> 
>> (B) — if-conditional statements currently explicitly show the import 
>> conditions (i.e., os(Linux) || os(FreeBSD)) this would be a detriment to 
>> this new feature. I would argue that the reduction of boilerplate code would 
>> in itself be worth this abstraction.
>> 
>> 
>> --
>> Sean Alling
>> 
>> ___
>> 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

Re: [swift-evolution] Import Conditionals

[Saagar Jha via swift-evolution]

I believe there was a draft to merge all the "Libc" modules; let me see if
I can find that.

On Mon, Oct 17, 2016 at 3:06 PM Sean Alling via swift-evolution <
swift-evolution@swift.org> wrote:

> *Description*
>
> In an effort to both (1) reduce boilerplate code, and (2) promote
> cross-platform reusability I propose that we implement the following *Import
> Conditional Operators*:
>
> *`||` *and `*&&`*
>
> Currently, import conditionals must be implemented like so:
>
> ```
> #if os(Linux) || os(FreeBSD)
> import Glibc
> #else
> import Darwin
> #endif
> ```
>
> With *import conditional operators* this would be condensed to:
>
> ```
> import Glibc || Darwin
> ```
>
> The first library/framework (Glibc) would be imported if found and the the
> second (Darwin) only in the event the first should fail.
>
> *Other Caveats:*
>
> *(A) —  *we could limit this to one conditional operator per import line
> OR we could implement order of operations. Obviously, there are tradeoffs
> of both that we should discuss.
>
> *(B) —* if-conditional statements currently explicitly show the import
> conditions (i.e., os(Linux) || os(FreeBSD)) this would be a detriment to
> this new feature. I would argue that the reduction of boilerplate code
> would in itself be worth this abstraction.
>
>
> --
> Sean Alling
>
> ___
> 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