Re: [swift-evolution] [RFC] Associated type inference

> On Nov 30, 2017, at 4:28 PM, Douglas Gregor via swift-evolution > wrote: > > Hello Swift community, > > Associated type inference, which is the process by which the Swift compiler > attempts to infer typealiases to satisfy associated-type requirements based > on

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0189: Restrict Cross-module Struct Initializers

> On Nov 17, 2017, at 5:59 PM, Slava Pestov wrote: > > > >> On Nov 17, 2017, at 8:57 PM, Jordan Rose via swift-evolution >> > wrote: >> >> >> >>> On Nov 17, 2017, at 15:20, Ben Langmuir

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0189: Restrict Cross-module Struct Initializers

Hi Jordan, First off, this is clearly the model we should have had all along ;-) That said, I have a concern about source-compat and our ability to automatically migrate code impacted by this change. > Source compatibility > > This makes existing code invalid in Swift 5, which is a source

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

Hi Slava, What is the impact on debugging? Will we emit a non-inline version of the function into the client at Onone? Will it be impossible to call from a debugger with optimization enabled? I've been burned by this in C++. Ben > On Oct 2, 2017, at 1:31 PM, Slava Pestov via swift-evolution

Re: [swift-evolution] Yet Another Access Control Pitch: Flexible Scoping

Hi Erica, I think this proposal needs to address how allowing arbitrary identifiers to become declaration modifiers would work during parsing. Custom accessgroups may not be in the same file - or even module - as the code they effect, meaning that foo bar func myFunction() {} cannot be

Re: [swift-evolution] [Review] SE-0116: Import Objective-C id as Swift Any type

Hey Joe, I’m +1 on the overall direction, but I have some questions/concerns about the "Ambivalent dynamic casting from Any” section. 1) When you suggest that `x as String` succeeds but `x as NSString` fails, I assume this would only be true *after* SE-0083, since otherwise we’d be violating

Re: [swift-evolution] [Pitch] #warning

> On Jun 1, 2016, at 10:54 AM, Jordan Rose via swift-evolution > wrote: > >> >> On May 29, 2016, at 13:20, Chris Lattner via swift-evolution >> > wrote: >> >>> On May 29, 2016, at 12:58 PM, Erica Sadun