Re: [swift-evolution] Idea: Properties in Failable Initializers less verbose

Makes sense. Off the top of my head, I can imagine the following two operators: `optional?^` throws some default error if nil `optional ??^ error` throws `error` if nil You could have optional throwing chaining as well — basically everywhere the language currently offers a choice of graceful op

[swift-evolution] [Accepted] SE-0183 - Substring performance affordances

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0183-substring-affordances.md The review of SE-0183 - “Substring performance affordances” ran from July 18...21, 2017. As expected, feedback was light but positive. Thanks to Ben Cohen for driving this effort forwar

Re: [swift-evolution] Idea: Properties in Failable Initializers less verbose

> On Jul 26, 2017, at 9:55 AM, Robert Bennett wrote: > > Is there a reason that a throwing unwrap function/operator isn’t part of the > standard library? Seems like it would be handy to be able to have a one-liner > for attempting to unwrap and throw if it’s nil. ?! would be the wrong name, s

Re: [swift-evolution] Idea: Properties in Failable Initializers less verbose

Is there a reason that a throwing unwrap function/operator isn’t part of the standard library? Seems like it would be handy to be able to have a one-liner for attempting to unwrap and throw if it’s nil. Something like postfix operator .?! extension Optional { static postfix func .?!(op

Re: [swift-evolution] [RFC] Definitive Initialization and Incompatibilities with Fixed-size Arrays

Right now, it's marked as "maybe" in the generic manifesto . > There are a number of features that get discussed from time-to-time, while > they could fit into Swift's generics system, it's not clear t

Re: [swift-evolution] Idea: Properties in Failable Initializers less verbose

> On Jul 25, 2017, at 2:44 AM, philohan95 via swift-evolution > wrote: > > I think the current way to initiate models in a Failable Initializer > `init?()` is overly verbose and should be shortened down so less boilerplate > should be needed. > > The current way: > > ``` > let someProperty:

Re: [swift-evolution] Idea: Properties in Failable Initializers less verbose

+1. > On 25. Jul 2017, at 18:30, Taylor Swift via swift-evolution > wrote: > > I’d be in favor of this. > > On Tue, Jul 25, 2017 at 5:44 AM, philohan95 via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > I think the current way to initiate models in a Failable Initializer > `

Re: [swift-evolution] [pitch] CopyInitializable for value-type semantics

I like the idea of Clonable, because it involves the least amount of boilerplate and I do certainly agree that not having to care about whether or not the object is a value type or a reference type is good for robust generic programming. However, there are two problems that I see with it: * The

Re: [swift-evolution] Idea: Properties in Failable Initializers less verbose

This was one of the issues I tried to address in my proposal about factory initializers (based on all previous discussions on that topic). I’d love to see this happen, but much like the reason why I didn’t push the factory initializers proposal to review, I think now’s not the time for this. The

Re: [swift-evolution] Moving from Swift 2 to 4

> On 26 Jul 2017, at 14:37, Jonathan Hull via swift-evolution > wrote: > > Is there a reason why the migration only applies to Swift 3? I have some > older files which I haven’t gotten around to upgrading until now, and Xcode > Beta says I need to migrate them with an older version of Xcode.

[swift-evolution] Moving from Swift 2 to 4

Is there a reason why the migration only applies to Swift 3? I have some older files which I haven’t gotten around to upgrading until now, and Xcode Beta says I need to migrate them with an older version of Xcode. Right now, I still have that older version, but once Xcode gets upgraded in the

Re: [swift-evolution] [idea] errors in properties

> On Jul 26, 2017, at 8:21 AM, Ben Rimmington wrote: > > Brent Royal-Gordon has written a draft proposal: > > > I totally love it! I’m even OK with wrapping stored properties into computed

Re: [swift-evolution] [Pitch] Small bit of sugar for enum case with Void associated value

+1 to this I not only support the case in question, but I 100% support any proposal that would push to compiler to completely remove any distinction from isomorphic tuples, by always reducing the tuple to the simplest form (this kind of discussion also took place in the thread about the SE110 r