Re: [swift-evolution] Smart KeyPaths

Sent from my iPhone > On 30 Mar 2017, at 01:13, Michael J LeHew Jr via swift-evolution > wrote: > > Thanks for the feedback everyone! We have pushed a changed a bit ago to the > proposal reflecting these desires. > >

Re: [swift-evolution] Smart KeyPaths

Sent from my iPhone > On Mar 29, 2017, at 6:32 PM, Brent Royal-Gordon via swift-evolution > wrote: > >>> On Mar 29, 2017, at 6:21 PM, Jonathan Hull via swift-evolution >>> wrote: >>> >>> I would love it if we found a way to retain

Re: [swift-evolution] Smart KeyPaths

> On Mar 29, 2017, at 7:08 PM, Joe Groff wrote: > > >> On Mar 29, 2017, at 7:00 PM, James Berry wrote: >> >>> >>> On Mar 29, 2017, at 5:37 PM, Joe Groff wrote: >>> >>> On Mar 29, 2017, at 5:26 PM, Michael J LeHew Jr via

Re: [swift-evolution] Smart KeyPaths

> On Mar 29, 2017, at 7:05 PM, Joe Groff wrote: > > KeyPath objects themselves have properties, so key1 could be a member of > KeyPath. This doesn't seem workable. Yeah, someone pointed that out to me privately. One solution would be to make it so that an uninterrupted

Re: [swift-evolution] Smart KeyPaths

> On Mar 29, 2017, at 7:00 PM, James Berry wrote: > >> >> On Mar 29, 2017, at 5:37 PM, Joe Groff wrote: >> >> >>> On Mar 29, 2017, at 5:26 PM, Michael J LeHew Jr via swift-evolution >>> wrote: >>> >>> On Mar 29,

Re: [swift-evolution] Smart KeyPaths

> On Mar 29, 2017, at 6:32 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> On Mar 29, 2017, at 6:21 PM, Jonathan Hull via swift-evolution >> wrote: >> >>> I would love it if we found a way to retain something as concise as that

Re: [swift-evolution] Smart KeyPaths

> On Mar 29, 2017, at 6:45 PM, Jonathan Hull via swift-evolution > wrote: > >> >> On Mar 29, 2017, at 6:32 PM, Brent Royal-Gordon >> wrote: >> >>> On Mar 29, 2017, at 6:21 PM, Jonathan Hull via swift-evolution >>>

Re: [swift-evolution] Smart KeyPaths

> On Mar 29, 2017, at 5:37 PM, Joe Groff wrote: > > >> On Mar 29, 2017, at 5:26 PM, Michael J LeHew Jr via swift-evolution >> wrote: >> >> >>> On Mar 29, 2017, at 5:12 PM, James Berry wrote: >>> Referencing Key

Re: [swift-evolution] [Pitch] String revision proposal #1

This looks great. The restored conformances to *Collection will be huge. Is this to be the first of several or the only major part of the manifesto to be delivered in Swift 4? Nits on naming: are we calling it Substring or SubString (à la SubSequence)? and shouldn't it be UnicodeParsedResult

Re: [swift-evolution] Smart KeyPaths

> On Mar 29, 2017, at 8:45 PM, Douglas Gregor via swift-evolution > wrote: > > > > Sent from my iPhone > > On Mar 29, 2017, at 4:52 PM, Brent Royal-Gordon > wrote: > >>> On Mar 29, 2017, at 4:13 PM,

Re: [swift-evolution] Smart KeyPaths

> On Mar 29, 2017, at 9:32 PM, Brent Royal-Gordon via swift-evolution > wrote: >> On Mar 29, 2017, at 6:21 PM, Jonathan Hull via swift-evolution >> > wrote: >> >>> I would love it if we found a way to

Re: [swift-evolution] Smart KeyPaths

> On Mar 29, 2017, at 6:32 PM, Brent Royal-Gordon > wrote: > >> On Mar 29, 2017, at 6:21 PM, Jonathan Hull via swift-evolution >> > wrote: >> >>> I would love it if we found a way to retain something as

Re: [swift-evolution] Smart KeyPaths

Sent from my iPhone > On Mar 29, 2017, at 4:52 PM, Brent Royal-Gordon > wrote: > >> On Mar 29, 2017, at 4:13 PM, Michael J LeHew Jr via swift-evolution >> wrote: >> >> Thanks for the feedback everyone! We have pushed a changed a bit ago

Re: [swift-evolution] Smart KeyPaths

> On Mar 29, 2017, at 6:21 PM, Jonathan Hull via swift-evolution > wrote: > >> I would love it if we found a way to retain something as concise as that >> shorthand. I'm working on a library where users will specify a collection >> of key paths pairs. This

Re: [swift-evolution] Smart KeyPaths

> On Mar 29, 2017, at 6:08 PM, Matthew Johnson via swift-evolution > wrote: > > The one big loss I see from the original proposal is that the current design > does not allow us to create a type context that provides something as concise > as the original dot

Re: [swift-evolution] Smart KeyPaths

Sent from my iPad > On Mar 29, 2017, at 7:32 PM, Joe Groff via swift-evolution > wrote: > > >> On Mar 29, 2017, at 5:29 PM, Michael J LeHew Jr wrote: >> >> On Mar 29, 2017, at 4:52 PM, Brent Royal-Gordon

Re: [swift-evolution] Smart KeyPaths

> On Mar 29, 2017, at 5:26 PM, Michael J LeHew Jr via swift-evolution > wrote: > > >> On Mar 29, 2017, at 5:12 PM, James Berry wrote: >> >>> Referencing Key Paths >>> >>> Forming a KeyPath borrows from the same syntax added in Swift 3 to

[swift-evolution] [Pitch] String revision proposal #1

Hi Swift Evolution, Below is a pitch for the first part of the String revision. This covers a number of changes that would allow the basic internals to be overhauled. Online version here:

Re: [swift-evolution] Smart KeyPaths

> On Mar 29, 2017, at 5:29 PM, Michael J LeHew Jr wrote: > > >> On Mar 29, 2017, at 4:52 PM, Brent Royal-Gordon >> wrote: >> >>> On Mar 29, 2017, at 4:13 PM, Michael J LeHew Jr via swift-evolution >>> wrote: >>> >>>

Re: [swift-evolution] Smart KeyPaths

> On Mar 29, 2017, at 4:52 PM, Brent Royal-Gordon > wrote: > >> On Mar 29, 2017, at 4:13 PM, Michael J LeHew Jr via swift-evolution >> > wrote: >> >> Thanks for the feedback everyone! We have pushed a

Re: [swift-evolution] Smart KeyPaths

> On Mar 29, 2017, at 5:12 PM, James Berry wrote: > >> Referencing Key Paths >> >> Forming a KeyPath borrows from the same syntax added in Swift 3 to confirm >> the existence of a given key path, only now producing concrete values >> instead of Strings. Optionals are

Re: [swift-evolution] Smart KeyPaths

> On Mar 29, 2017, at 7:12 PM, James Berry via swift-evolution > wrote: > >> Referencing Key Paths >> >> Forming a KeyPath borrows from the same syntax added in Swift 3 to confirm >> the existence of a given key path, only now producing concrete values >> instead

Re: [swift-evolution] Smart KeyPaths

> Referencing Key Paths > > Forming a KeyPath borrows from the same syntax added in Swift 3 to confirm > the existence of a given key path, only now producing concrete values instead > of Strings. Optionals are handled via optional-chaining. Multiply dotted > expressions are allowed as well,

Re: [swift-evolution] Disallowing unreachable code

> On Mar 29, 2017, at 4:21 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> On Mar 29, 2017, at 4:14 PM, Brent Royal-Gordon >> wrote: >> >>> On Mar 29, 2017, at 8:11 AM, John McCall via swift-evolution >>>

Re: [swift-evolution] Disallowing unreachable code

> On Mar 29, 2017, at 8:11 AM, John McCall via swift-evolution > wrote: > >> On Mar 29, 2017, at 9:15 AM, Alex Blewitt wrote: >>> On 29 Mar 2017, at 14:10, Jonathan Hull wrote: >>> >>> I think the idea is that it also adds a

Re: [swift-evolution] Disallowing many expressions with unused result (@error_unused_result?)

> On Mar 24, 2017, at 3:57 PM, Peter Dillinger via swift-evolution > wrote: > > I recently criticized Swift 3 for allowing many expressions with no side > effects as statements, in this blog post: >

Re: [swift-evolution] Smart KeyPaths

> On Mar 29, 2017, at 4:13 PM, Michael J LeHew Jr via swift-evolution > wrote: > > Thanks for the feedback everyone! We have pushed a changed a bit ago to the > proposal reflecting these desires. > > https://github.com/apple/swift-evolution/pull/644/files >

Re: [swift-evolution] Disallowing unreachable code

> On Mar 29, 2017, at 4:14 PM, Brent Royal-Gordon > wrote: > >> On Mar 29, 2017, at 8:11 AM, John McCall via swift-evolution >> > wrote: >> >> I was suggesting that it would be a useful addition to the

Re: [swift-evolution] Disallowing unreachable code

> On Mar 29, 2017, at 8:11 AM, John McCall via swift-evolution > wrote: > > I was suggesting that it would be a useful addition to the language, not that > it > necessarily needed new compiler support. Personally, what I'd like to see is for the existing

Re: [swift-evolution] Smart KeyPaths

Thanks for the feedback everyone! We have pushed a changed a bit ago to the proposal reflecting these desires. https://github.com/apple/swift-evolution/pull/644/files -Michael > On Mar 29, 2017, at 2:49 PM, Douglas Gregor wrote: > > >> On Mar 17, 2017, at 10:04 AM,

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

> On Mar 29, 2017, at 3:00 PM, Douglas Gregor via swift-evolution > wrote: > > > * @implicitobjc added to a class implicitly makes members of that class *and > all of its subclasses* @objc if they can be exposed to Objective-C > * @implicitobjc added to a class

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

> On Mar 23, 2017, at 2:06 AM, Slava Pestov via swift-evolution > wrote: > > Here’s an idea for working around the problem of the lack of static knowledge > during migration. Probably it’s kind of tacky and won’t get much traction in > it’s current form, but it

Re: [swift-evolution] Smart KeyPaths

> On Mar 17, 2017, at 10:04 AM, Michael LeHew via swift-evolution > wrote: > > Hi friendly swift-evolution folks, > > The Foundation and Swift team would like for you to consider the following > proposal: The Swift core team discussed this proposal draft and had

Re: [swift-evolution] [Pitch] Allow closures/default params to satisfy protocol requirements

I would be in favor of some sugar allowing optional methods eventually. I am kind of waiting to see how the reflection API shakes out. I know there was some sort of argument on the list before about it being bad design to have optional methods, but I still really like it as a pattern. In

Re: [swift-evolution] Disallowing unreachable code

> On Mar 24, 2017, at 3:54 PM, Peter Dillinger via swift-evolution > wrote: > > I don't see anything directly relevant to this in the archives, and I haven't > prepared a detailed proposal. But I'm raising the general idea because I > recently criticized Swift 3

Re: [swift-evolution] [swift-build-dev] [Draft] Package Manager Custom Targets Layout

> On Mar 29, 2017, at 10:56, Ankit Aggarwal wrote: > > We discussed variadic overloads during the manifest redesign proposal but > ultimately rejected it. We could add an overload for a singular source file > (instead of variadic) but I think its simpler to just have

Re: [swift-evolution] [swift-build-dev] [Draft] Package Manager Custom Targets Layout

We discussed variadic overloads during the manifest redesign proposal but ultimately rejected it. We could add an overload for a singular source file (instead

Re: [swift-evolution] [swift-build-dev] [Draft] Package Manager Custom Targets Layout

On Mar 29, 2017, at 10:19, Ankit Aggarwal via swift-build-dev wrote: > The proposal is updated with this change. What do we think about adding convenience inits that take a single parameter in place of the []s, for when we're only passing one value? The down side

Re: [swift-evolution] [swift-build-dev] [Draft] Package Manager Custom Targets Layout

Oops, I had pressed reply instead reply all. The proposal is updated with this change. On Mon, Mar 27, 2017 at 12:32 PM, Ankit Aggarwal

Re: [swift-evolution] Disallowing unreachable code

> On Mar 29, 2017, at 12:55 AM, Peter Dillinger > wrote: >>> On Mar 28, 2017, at 9:40 PM, Peter Dillinger >>> wrote: Agreed, we have the right design here. The go community has shown the result of taking a hard line

Re: [swift-evolution] Disallowing unreachable code

> On Mar 29, 2017, at 9:15 AM, Alex Blewitt wrote: >> On 29 Mar 2017, at 14:10, Jonathan Hull > > wrote: >> >> I think the idea is that it also adds a warning so you can find it later. > > @available(*, deprecated, message: "Don't

Re: [swift-evolution] Disallowing unreachable code

> On 29 Mar 2017, at 14:10, Jonathan Hull wrote: > > I think the idea is that it also adds a warning so you can find it later. @available(*, deprecated, message: "Don't forget to implement this") func unimplemented(_ file:String = #file,_ line:Int = #line) -> T {

Re: [swift-evolution] Disallowing unreachable code

I think the idea is that it also adds a warning so you can find it later. > On Mar 29, 2017, at 6:06 AM, Alex Blewitt wrote: > > On 29 Mar 2017, at 11:38, Jonathan Hull via swift-evolution > > wrote: >> >> >>> On

Re: [swift-evolution] Disallowing unreachable code

On 29 Mar 2017, at 11:38, Jonathan Hull via swift-evolution wrote: > > >> On Mar 27, 2017, at 11:27 AM, John McCall via swift-evolution >> > wrote: >> >> In fact, we should probably double-down on this

Re: [swift-evolution] Disallowing unreachable code

> On Mar 27, 2017, at 11:27 AM, John McCall via swift-evolution > wrote: > > In fact, we should probably double-down on this design and add an > "unimplemented" expression that always triggers warnings and just traps if > you try to evaluate it. That expression

Re: [swift-evolution] Disallowing unreachable code

> On 24 Mar 2017, at 22:54, Peter Dillinger via swift-evolution > wrote: > > I don't see anything directly relevant to this in the archives, and I haven't > prepared a detailed proposal. But I'm raising the general idea because I > recently criticized Swift 3 for

Re: [swift-evolution] Disallowing unreachable code

> On Mar 28, 2017, at 9:55 PM, Peter Dillinger via swift-evolution > wrote: > >>> Missing 'try' is a fatal issue? >> >> That could be argued I suppose, I was referring to unreachable code, unused >> variables, >> variables that are never mutated, etc. > > And what

Re: [swift-evolution] [Pitch] Allow closures/default params to satisfy protocol requirements

I will consider your advice, it’s actually a replay good one. :) I guess it was the iOS development influence from Objective-C that let me write such not swifty delegates. --  Adrian Zubarev Sent with Airmail Am 29. März 2017 um 04:07:38, Slava Pestov (spes...@apple.com) schrieb: On Mar

Re: [swift-evolution] Disallowing unreachable code

On Mar 28, 2017, at 21:55, Peter Dillinger via swift-evolution wrote: On Mar 28, 2017, at 9:40 PM, Peter Dillinger wrote: Agreed, we have the right design here. The go community has shown the result of taking