> On Nov 11, 2017, at 7:02 AM, Joe Groff via swift-evolution > <[email protected]> wrote: > > > > On Nov 10, 2017, at 8:35 PM, Chris Lattner via swift-evolution > <[email protected] <mailto:[email protected]>> wrote: > >> >>> On Nov 10, 2017, at 6:12 PM, Slava Pestov via swift-evolution >>> <[email protected] <mailto:[email protected]>> wrote: >>> >>> >>> >>>> On Nov 10, 2017, at 6:10 PM, Matthew Johnson via swift-evolution >>>> <[email protected] <mailto:[email protected]>> wrote: >>>> >>>> Setting this aside, I’m very curious to hear whether type providers >>>> influence your thinking after you’ve had a chance to look into them. I >>>> have always thought they were very cool. >>> >>> I’m in favor of solving this problem with something like type providers >>> also. The required compiler changes would be significant but would also >>> clean up the interface between the ClangImporter, Sema and Serialization. >>> If done right it would be a net gain that would benefit all users, instead >>> of just adding YetAnotherCornerCase™ that makes implementation maintainers >>> curse and scream. >> >> I find it ironic that you’re talking pejoratively about a feature that has >> very narrow impact, complaining about how much of an impact on the compiler >> it would have, and then pine for a hugely invasive feature - one that would >> cause a ton of code churn, and probably wouldn’t actually be enough to >> eliminate the special cases in place because of ObjC interop. > > You underestimate the impact this would have on function call type checking, > but since this is an additive, non-ABI-stability feature, I have trouble > considering it a candidate for Swift 5,
The guidelines for Swift 5 are publicly documented here: https://github.com/apple/swift-evolution/blob/master/README.md#evolution-process-for-swift-5 <https://github.com/apple/swift-evolution/blob/master/README.md#evolution-process-for-swift-5> This is relevant and seems reasonable to me: Syntactic additions. Syntactic changes do not increase the expressive power of the language but do increase its complexity. Consequently, such changes must be extremely well-motivated and will be subject to additional scrutiny. We will expect proposals to include concrete data about how wide spread the positive impact will be. I explicitly point out that this is a sugar change. > so I don't think there's a time constraint forcing us to consider the > "narrow" vs "huge" dimension. What's the best thing for the language and > tools in the long term? This is a feature that influences the semantics of > potentially any call site in all Swift code, which we'd have to live with > forever if we accepted it now. Opening up the compiler architecture to make > custom importers easier to write is a great solution to a ton of problems, > including yours I think, without adding complexity to the core language. > Experience in .NET land seems to show it's a great technique for integrating > dynamic systems with static type systems, without poking unnecessary holes in > the static language's type system As I mentioned, I’m not familiar with F# type providers. As I told you upthread, I will read about them and respond with an informed opinion when I have time. -Chris
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
