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 > <swift-evolution@swift.org> 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 <saa...@saagarjha.com > <mailto:saa...@saagarjha.com>> 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 >> <swift-evolution@swift.org <mailto: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 <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <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
