Re: [swift-evolution] [swift-evolution-announce] [REVIEW] SE-0193 - Cross-module inlining and specialization

> On Dec 22, 2017, at 7:09 PM, Xiaodi Wu wrote: > > On Fri, Dec 22, 2017 at 6:12 PM, Chris Lattner > wrote: > >> On Dec 22, 2017, at 1:03 PM, Xiaodi Wu > > wrote: >>

Re: [swift-evolution] [swift-evolution-announce] [REVIEW] SE-0193 - Cross-module inlining and specialization

> On Dec 22, 2017, at 9:55 AM, Chris Lattner wrote: > When and if we add private cases to enums, we’ll need to be able to associate > an availability range with an “exhaustive” marker. When/if that happens, > then yes, we should do so through @available(exhaustive:

Re: [swift-evolution] [REVIEW] SE-0193 - Cross-module inlining and specialization

> On Dec 22, 2017, at 1:50 AM, Johannes Weiß wrote: > > totally agree that these attributes are necessary, they should be in Swift as > soon as we bike shedded the right name. But to prevent them from being placed > everywhere without thinking I propose to introduce

Re: [swift-evolution] [swift-evolution-announce] [REVIEW] SE-0193 - Cross-module inlining and specialization

On Fri, Dec 22, 2017 at 6:12 PM, Chris Lattner wrote: > > On Dec 22, 2017, at 1:03 PM, Xiaodi Wu wrote: > > In short, respectfully request that you at least add this approach to the >> "alternatives considered” section. >> >> >> So, does anyone have any

Re: [swift-evolution] The Non-Exhaustive Enums proposal kills one of Swift's top features - change proposal

> On Dec 21, 2017, at 10:33 AM, Jordan Rose via swift-evolution > wrote: > > The main blocker was that such a case becomes untestable (see also "Testing > invalid cases"). You can always make it testable through appropriate factoring—for example, have the `future`

Re: [swift-evolution] [swift-evolution-announce] [REVIEW] SE-0193 - Cross-module inlining and specialization

> On Dec 22, 2017, at 1:03 PM, Xiaodi Wu wrote: > >> In short, respectfully request that you at least add this approach to the >> "alternatives considered” section. > > So, does anyone have any strong objections to Chris’s proposal? > > From an implementation standpoint,

Re: [swift-evolution] [swift-evolution-announce] [REVIEW] SE-0193 - Cross-module inlining and specialization

On Fri, Dec 22, 2017 at 2:08 AM, Slava Pestov via swift-evolution < swift-evolution@swift.org> wrote: > Hi Chris, > > Thanks for reviewing the proposal! > > On Dec 20, 2017, at 11:14 PM, Chris Lattner via swift-evolution < > swift-evolution@swift.org> wrote: > > On Dec 20, 2017, at 4:19 PM, Ted

Re: [swift-evolution] [REVIEW] SE-0193 - Cross-module inlining and specialization

> On Dec 22, 2017, at 1:29 AM, Slava Pestov wrote: > >> On Dec 21, 2017, at 12:42 PM, Paul Cantrell > > wrote: >> >> 1. Presumably the portions of A inlined into B and C remain sensitive to the >> version-specific memory

Re: [swift-evolution] [swift-evolution-announce] [REVIEW] SE-0193 - Cross-module inlining and specialization

> On Dec 21, 2017, at 11:08 PM, Slava Pestov wrote: >> I am hugely supportive of the features that these attributes enable, but I >> think that the spelling of this is absolutely wrong, and I’m disappointed >> that the extensive discussion we’ve had for months about this

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

> On Dec 20, 2017, at 11:12 PM, Cheyo Jimenez wrote: > > > >> On Dec 19, 2017, at 2:58 PM, Ted Kremenek via swift-evolution >> wrote: >> >> The review of "SE 0192 - Non-Exhaustive Enums" begins now and runs through >> January 3, 2018. >>

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

> On Dec 21, 2017, at 10:02 AM, Dave DeLong via swift-evolution > wrote: > > I would love to see some sort of formal API versioning that we could do > instead in libraries, along with easy runtime support for checking the linked > version of libraries, making it

Re: [swift-evolution] Evaluating the case of an enum with associated values as a bool

Many styles of programming can take advantage of if/else and switch/case being actual expressions (actually, these are all special cases of the very general concept of "folding"). We don't have this in Swift, and I have occasion to be bothered by this almost on a daily basis in my work,

Re: [swift-evolution] The Non-Exhaustive Enums proposal kills one of Swift's top features - change proposal

I think you make a fair point here - either case is currently untestable in a non-exhaustive enum. Perhaps this pushes harder on the “future” case and a way we can test this in Unit Tests when we @testable import other frameworks to simulate an additional case. > On 22 Dec 2017, at 5:36 am,

Re: [swift-evolution] [REVIEW] SE-0193 - Cross-module inlining and specialization

Hi Slava, > On 22 Dec 2017, at 7:13 am, Slava Pestov wrote: > > Hi Johannes, > > Thanks for reviewing this proposal! > >> On Dec 21, 2017, at 8:06 AM, Johannes Weiß via swift-evolution >> wrote: > >> The library I'm working on will presumably