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

I come from a perspective similar to Johannes, in that: for my work we are interested in the performance improvements of cross-module optimization and specialization but we regularly rebuild frameworks along with apps and explicitly don’t need ABI versioning. Unlike him, I’m not that concerned

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

> On Dec 1, 2017, at 9:11 AM, Ben Langmuir via swift-evolution > wrote: > Hey Doug, > > I'm very much in favour of reducing the scope of associated type inference. > Can you outline why you believe that (3) is necessary? If I am following > correctly, if we had

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

Hi Doug, > On Nov 30, 2017, at 4:28 PM, Douglas Gregor via swift-evolution > wrote: > > I think this approach is more predictable and more implementable than the > current model. I’m curious whether the above makes sense to someone other > than me, and whether it

Re: [swift-evolution] [Review #2] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

Mostly as a matter of historical interest: The hard-coding of collection operators for KVC in Cocoa was more of a scope of documentation or API style decision than anything. The original implementation of KVC came from Enterprise Objects Framework (which then became WebObjects), and in both of

Re: [swift-evolution] [swift-dev] Endgame for Swift 3

> On Jul 15, 2016, at 10:35 PM, Patrick Pijnappel via swift-dev > wrote: > > Isn't half of this done, or something? I seem to remember seeing code about > it, and I think there may even be a hidden switch to enable what is there. > > The parsing code seems to be in

Re: [swift-evolution] [Proposal Draft] Literal Syntax Protocols

I’m honestly shocked that y’all (that I’ve seen) haven’t come up with Syntax.LiterallyIntegerLiteral yet. > On Jun 28, 2016, at 8:39 PM, Sean Heber via swift-evolution > wrote: > > Arg. Dang it! > > Syntax.ExpressibleAsIntegerLiteral > Syntax.FromIntegerLiteral >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

I think that Jon has exactly described my view on this proposal. Thanks, Jon. -1. -- Greg > On Jun 4, 2016, at 12:17 AM, Jon Shier via swift-evolution > wrote: > > The suitability of “where” as the keyword in these clauses is a > completely separate

Re: [swift-evolution] [Review] SE-0043 Declare variables in 'case' labels with multiple patterns

> On Mar 16, 2016, at 10:55 AM, Chris Lattner via swift-evolution > wrote: > > The review of “Declare variables in 'case' labels with multiple patterns” > begins now and runs through March 21, 2016. The proposal is available here: > > >

Re: [swift-evolution] Epic: Typesafe calculations

First, of all, I’d love to have a “newtype” equivalent in Swift: +1. But also wanted to mention that my current pattern for this sort of code is to use structs, which has the added advantage (or disadvantage, depending upon your particular use case) of being able to easily specify fewer and