Re: [swift-evolution] Revisiting SE-0110

My guess is that core team is planning to accept *patterns* in closure parameter clause. e.g.: let dict = ["foo": 1, "bar": 2] let result = dict.map { ((k, v) : (key: String, value: Int)) in ... } ^^ pattern When the compiler see this expression: dict.map { k

Re: [swift-evolution] [Pitch] Introducing role keywords to reduce hard-to-find bugs

> On Jun 14, 2017, at 11:46 PM, Dave Abrahams via swift-evolution > wrote: > > > on Wed Jun 14 2017, Chris Lattner wrote: > >>> On Jun 14, 2017, at 10:11 AM, Erica Sadun via swift-evolution >>> wrote: >>> >>> Some pals and I have been kicking an idea around about introducing >>> better way

Re: [swift-evolution] [Pitch] Introducing role keywords to reduce hard-to-find bugs

Erica, any thoughts on only having default and making it an error in a future version of Swift like was discussed on this thread? The idea seems to have a few supporters. > On 16 Jun 2017, at 15:33, Erica Sadun via swift-evolution > wrote: > > >> On Jun 14, 2017, at 11:46 PM, Dave Abrahams v

Re: [swift-evolution] [Pitch] Introducing role keywords to reduce hard-to-find bugs

As we say in our introduction, we're pitching the most conservative approach. The proposal was designed for minimal language impact. It chooses a conservative approach that can be phased in first over time and language release over more succinct alternatives that would impact existing code base

Re: [swift-evolution] [Pitch] Introducing role keywords to reduce hard-to-find bugs

Okay, I undertand. I’m just worried that the proposal is a net negative if the keywords stay optional. I’ll mention it in more detail once we get to the review period. Thanks for the work on the proposal!! > On 16 Jun 2017, at 16:33, Erica Sadun wrote: > > As we say in our introduction, we're

[swift-evolution] floating point numbers implicit conversion

Hello, Appr. a year ago I suggested to allow implicit conversion between floating point number types, that is between Float, CGFloat Double..Float80 … (Note that CGFloat IS a Double on 64-bit systems btw), E.g I am currently making things using SceneKit 3D, wich obviously involves a lot of fl

[swift-evolution] Variable with generic protocol type

Hello. Sorry, but C# code: interface IValidator { bool validate(T value); } IValidator validator; Easy, simple and clear. Swift: protocol PValidator { associatedtype ValidateType func validate(value: ValidateType) -> Bool } var validator:

Re: [swift-evolution] floating point numbers implicit conversion

Implicit promotion has been brought up on the list before, many times over many years. The scale and implications of the change not to be underestimated. To give a taste of what would be involved, consider that new integer protocols were recently implemented that allow heterogeneous comparison; th

Re: [swift-evolution] The state and the future of function types in Swift 4

> On Jun 14, 2017, at 3:29 PM, Vladimir.S via swift-evolution > wrote: > > I do understand that core team is very busy, but I hope they'll find a minute > to reply in couple of words to this message. Even "we are still thinking > about this" would be great. Of course any other's opinion is al

Re: [swift-evolution] Variable with generic protocol type

As I understand it, and someone please correct me if I'm wrong, you've just described *existentials*, which Swift doesn't fully support yet but which are on the Generics Manifesto. It would be nice to declare or cast a variable as 'conforms to protocol X with associated type known to be Y' or 'con

Re: [swift-evolution] floating point numbers implicit conversion

Has it been proposed to eventually make CGFloat into a typealias for Double to reduce the amount of explicit conversion necessary? (I realize as a proposal this would be better suited for corelibs-libfoundation) - For Apple platforms, eventually CGFloat will *always* be a Double value, as Swift

Re: [swift-evolution] Revisiting SE-0110

> On Jun 15, 2017, at 7:17 PM, Xiaodi Wu via swift-evolution > wrote: > > > On Thu, Jun 15, 2017 at 19:03 Víctor Pimentel > wrote: > On 16 Jun 2017, at 01:55, Xiaodi Wu via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > >> On Thu, Jun 15, 2017 at

Re: [swift-evolution] [Pitch] Introducing role keywords to reduce hard-to-find bugs

> On Jun 16, 2017, at 8:44 AM, David Hart wrote: > > Okay, I undertand. I’m just worried that the proposal is a net negative if > the keywords stay optional. I’ll mention it in more detail once we get to the > review period. > > Thanks for the work on the proposal!! I believe a breaking chan

Re: [swift-evolution] [Pitch] Introducing role keywords to reduce hard-to-find bugs

The described problem might be one of the most famous itches of the language, but imho the bar for new keywords* should be higher than that — and there are alternatives: First, I guess many would like to see this to be valid Swift: protocol Foo { func bar() { print("Defa

Re: [swift-evolution] [Pitch] Introducing role keywords to reduce hard-to-find bugs

> On Jun 16, 2017, at 12:21 PM, Tino Heth <2...@gmx.de> wrote: > > The described problem might be one of the most famous itches of the language, > but imho the bar for new keywords* should be higher than that — and there are > alternatives: > > First, I guess many would like to see this to be

Re: [swift-evolution] [Pitch] Introducing role keywords to reduce hard-to-find bugs

> On Jun 16, 2017, at 1:14 PM, Erica Sadun via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > >> On Jun 16, 2017, at 8:44 AM, David Hart > > wrote: >> >> Okay, I undertand. I’m just worried that the proposal is a net negative if >> the keywords sta

Re: [swift-evolution] [Pitch] Introducing role keywords to reduce hard-to-find bugs

I’d support the breaking change here to allow the language to evolve properly instead of introducing halve baked opt-ins and workarounds for issues that totally deserve a fix. The first thought that I had when reading the proposal the first time was, that extend does not add any benefit to the l

Re: [swift-evolution] [Pitch] Introducing role keywords to reduce hard-to-find bugs

I’ve already mentioned this in this thread. This is one of the missing features from the generics manifesto, however it’s (almost) a syntactic sugar only. It means that if we would enforce default in Swift 4, then having default implementation directly inside protocols would be really a syntacti

Re: [swift-evolution] [Pitch] Introducing role keywords to reduce hard-to-find bugs

On Fri, Jun 16, 2017 at 14:06 Paul Cantrell via swift-evolution < swift-evolution@swift.org> wrote: > On Jun 16, 2017, at 1:14 PM, Erica Sadun via swift-evolution < > swift-evolution@swift.org> wrote: > > On Jun 16, 2017, at 8:44 AM, David Hart wrote: > > Okay, I undertand. I’m just worried that

Re: [swift-evolution] [Pitch] Introducing role keywords to reduce hard-to-find bugs

> On Jun 16, 2017, at 2:26 PM, Xiaodi Wu wrote: > > On Fri, Jun 16, 2017 at 14:06 Paul Cantrell via swift-evolution > mailto:swift-evolution@swift.org>> wrote: >> On Jun 16, 2017, at 1:14 PM, Erica Sadun via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >>> On Jun 16, 2017,

Re: [swift-evolution] [Pitch] Introducing role keywords to reduce hard-to-find bugs

On Fri, Jun 16, 2017 at 14:42 Paul Cantrell wrote: > On Jun 16, 2017, at 2:26 PM, Xiaodi Wu wrote: > > On Fri, Jun 16, 2017 at 14:06 Paul Cantrell via swift-evolution < > swift-evolution@swift.org> wrote: > >> On Jun 16, 2017, at 1:14 PM, Erica Sadun via swift-evolution < >> swift-evolution@swif

Re: [swift-evolution] Revisiting SE-0110

> On Jun 16, 2017, at 11:13 AM, Paul Cantrell via swift-evolution > wrote: > >> >> On Jun 15, 2017, at 7:17 PM, Xiaodi Wu via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> >> On Thu, Jun 15, 2017 at 19:03 Víctor Pimentel > > wrote: >> On 16

Re: [swift-evolution] Revisiting SE-0110

> On Jun 16, 2017, at 1:21 PM, Mark Lacey wrote: > >> >> On Jun 16, 2017, at 11:13 AM, Paul Cantrell via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >>> >>> On Jun 15, 2017, at 7:17 PM, Xiaodi Wu via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>>

Re: [swift-evolution] Revisiting SE-0110

> On Jun 16, 2017, at 3:43 PM, Mark Lacey wrote: > > >> On Jun 16, 2017, at 1:21 PM, Mark Lacey > > wrote: >> >>> >>> On Jun 16, 2017, at 11:13 AM, Paul Cantrell via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> On Jun 15, 2017, at

Re: [swift-evolution] The state and the future of function types in Swift 4

On 16.06.2017 19:29, Douglas Gregor wrote: On Jun 14, 2017, at 3:29 PM, Vladimir.S via swift-evolution wrote: I do understand that core team is very busy, but I hope they'll find a minute to reply in couple of words to this message. Even "we are still thinking about this" would be great. O

Re: [swift-evolution] Revisiting SE-0110

> On Jun 16, 2017, at 2:09 PM, Paul Cantrell wrote: > >> >> On Jun 16, 2017, at 3:43 PM, Mark Lacey > > wrote: >> >> >>> On Jun 16, 2017, at 1:21 PM, Mark Lacey >> > wrote: >>> On Jun 16, 2017, at 11:13 AM, Paul Cantrell vi

Re: [swift-evolution] floating point numbers implicit conversion

> On Jun 16, 2017, at 10:35 AM, David Waite via swift-evolution > wrote: > > Has it been proposed to eventually make CGFloat into a typealias for Double > to reduce the amount of explicit conversion necessary? (I realize as a > proposal this would be better suited for corelibs-libfoundation)

Re: [swift-evolution] floating point numbers implicit conversion

> On Jun 16, 2017, at 4:34 PM, Greg Parker > wrote: > > >> On Jun 16, 2017, at 10:35 AM, David Waite via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> Has it been proposed to eventually make CGFloat into a typealias for Double >> to reduce the a

Re: [swift-evolution] Followup after in-the-field feedback for SE-0170

> On Jun 14, 2017, at 13:59, Philippe Hausler via swift-evolution > wrote: > > > >> On Jun 14, 2017, at 1:47 PM, Dave Abrahams via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> >> on Wed Jun 14 2017, Philippe Hausler > > wrote: >> >>

Re: [swift-evolution] Followup after in-the-field feedback for SE-0170

Those cases will produce `nil`. "Should" is a matter of expectation, but I think that it’s reasonable behavior since it feels truer to the intent the `exactly:` methods. On 16 Jun 2017, at 16:23, Jordan Rose via swift-evolution wrote: > On Jun 14, 2017, at 13:59, Philippe Hausler via swift-evo

Re: [swift-evolution] Revisiting SE-0110

> On Jun 16, 2017, at 5:23 PM, Mark Lacey wrote: > > >> On Jun 16, 2017, at 2:09 PM, Paul Cantrell > > wrote: >> >>> >>> On Jun 16, 2017, at 3:43 PM, Mark Lacey >> > wrote: >>> >>> On Jun 16, 2017, at 1:21 PM, Mark Lacey >>>

Re: [swift-evolution] Revisiting SE-0110

Keep in mind that once the latest proposal about enum cases is implemented, these will be at least notionally no longer tuple labels but rather a sugared way of spelling part of the case name. The rules surrounding labels during case matching have only just been revised and approved and have not ev

Re: [swift-evolution] Revisiting SE-0110

Under these not-yet-implemented plans, if associated value labels are no longer tuple labels, then how will pattern matching work? And what existing pattern matching code will break / continue to work? P > On Jun 16, 2017, at 10:22 PM, Xiaodi Wu wrote: > > Keep in mind that once the latest pr

Re: [swift-evolution] Revisiting SE-0110

See: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170417/035972.html On Fri, Jun 16, 2017 at 22:32 Paul Cantrell wrote: > Under these not-yet-implemented plans, if associated value labels are no > longer tuple labels, then how will pattern matching work? And what existing > p