Re: [swift-evolution] [Review] SE-0142: Permit where clauses to constrain associated types

+111eleventyone Also, FWIW, strong +1 for everything in the generics manifesto, too. Sent from my iPhone > On Sep 23, 2016, at 18:50, Douglas Gregor via swift-evolution > wrote: > > Hello Swift community, > > The review of SE-0142: "Permit where clauses to constrain associated types" > begin

Re: [swift-evolution] [Review] SE-0142: Permit where clauses to constrain associated types

Sent from my iPhone > On Sep 24, 2016, at 6:55 PM, Nate Cook wrote: > > >> https://github.com/apple/swift-evolution/blob/master/proposals/0142-associated-types-constraints.md > >> What is your evaluation of the proposal? > [Smiling Face With Heart-Shaped Eyes Emoji] > > One of the examples

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0142: Permit where clauses to constrain associated types

Sent from my iPhone > On Sep 24, 2016, at 12:58 PM, Drew Crawford via swift-evolution > wrote: > > This is the #1 Swift feature I have wanted for the past 2 years. > > One thing I would like to see (perhaps out of scope for this proposal) is the > natural extension for generic parameters: >

Re: [swift-evolution] Three questions about a more "dynamic" Swift for InfoQ

> On Sep 26, 2016, at 3:29 PM, sergio via swift-evolution > wrote: > > HI all, > > a debate has recently taken place within the Objective-C/Swift dev community > concerning the lack in Swift of something “equivalent” to Objective-C runtime > programming. When using Swift exclusively, there s

Re: [swift-evolution] [Proposal draft] Conditional conformances

+1. I have one purely bureaucratic concern that I couldn't quite find answers to on a read through: Orphan instances and more generally cross-module uniqueness of instances are not mentioned. What's the policy here? Are we locally unique with respect to imported modules or globally unique wi

[swift-evolution] [Proposal draft] Conditional conformances

Conditional conformances Proposal: SE- Author: Doug Gregor Review Manager: TBD Status: Awaiting review During the review process, add the fo

Re: [swift-evolution] [proposal draft] new syntax to access a given case's payload

Being a power user of this feature, I don’t think the existing syntax is cumbersome enough to warrant this kind of shortcut. I really like being able to guard case let .dict(book) = data else { // bail out } guard case let .dict(author) = book["author"] ?? .null else { // bail ou

Re: [swift-evolution] Three questions about a more "dynamic" Swift for InfoQ

Von meinem iPhone gesendet > Am 26.09.2016 um 23:32 schrieb Robert Widmann via swift-evolution > : > > > > ~Robert Widmann > > 2016/09/26 16:29、sergio via swift-evolution > のメッセージ: > >> HI all, >> >> a debate has recently taken place within the Objective-C/Swift dev community >> concer

Re: [swift-evolution] Should Swift apply "statement scope" for ARC

> On Sep 25, 2016, at 3:19 AM, John Holdsworth wrote: > > >> On 25 Sep 2016, at 04:07, Michael Gottesman > > wrote: >> >>> init(imageProducer:ImageProducer) { >>> withExtendedLifetime(CanvasBase()) { >>> super.init(javaObject: $0.javaObject)

Re: [swift-evolution] Three questions about a more "dynamic" Swift for InfoQ

~Robert Widmann 2016/09/26 16:29、sergio via swift-evolution のメッセージ: > HI all, > > a debate has recently taken place within the Objective-C/Swift dev community > concerning the lack in Swift of something “equivalent” to Objective-C runtime > programming. When using Swift exclusively, there s

Re: [swift-evolution] class/struct inner member access scope classifier

Just to weigh in here, I too am enjoying Swift 3 greatly. However, my experience with access modifiers is rather different. I am very glad that `internal` is the default: this reduces extraneous noise for the common case, and makes it really easy for new programmers to jump in. Furthermore, I am

[swift-evolution] Three questions about a more "dynamic" Swift for InfoQ

HI all, a debate has recently taken place within the Objective-C/Swift dev community concerning the lack in Swift of something “equivalent” to Objective-C runtime programming. When using Swift exclusively, there seems to be no easy equivalent for Cocoa fundamental design patterns such as the Re

Re: [swift-evolution] SE-0138 UnsafeRawBufferPointer

> On 14 Sep 2016, at 18:08, Andrew Trick via swift-evolution > wrote: > > >> On Sep 10, 2016, at 5:53 PM, Andrew Trick wrote: >> >> https://github.com/apple/swift-evolution/blob/master/proposals/0138-unsaferawbufferpointer.md >> >> The review period has been extended until September 14. The

[swift-evolution] class/struct inner member access scope classifier

Hello! Hope you are all OK! Using and converting To Swift 3.0 with many advantages and very little problems.OK, thanks to all ! also for the reasonably smart converter. Yes, yes, yes, I’m still missing the classical for ;; loop (don’t wake me up again plse :o) but overall it is quite good! I a

Re: [swift-evolution] Source-breaking proposals?

on Sun Sep 25 2016, Karl wrote: >> On 25 Sep 2016, at 18:38, Anton Zhilin via swift-evolution >> wrote: >> >> Do I miss something, or proposals with source-breaking changes still can't >> be submitted? >> When will corresponsing guidelines be out? Are there any plans on that >> matter? >> _

Re: [swift-evolution] [Review] SE-0141: Availability by Swift version

Re: Is the "Versioned API" design in docs/LibraryEvolution.rst not intended for the Swift standard library?

Re: [swift-evolution] SE-0138 UnsafeRawBufferPointer

> On 14 Sep 2016, at 17:08, Andrew Trick via swift-evolution > wrote: > >> On Sep 10, 2016, at 5:53 PM, Andrew Trick wrote: >> >> https://github.com/apple/swift-evolution/blob/master/proposals/0138-unsaferawbufferpointer.md >> >> The review period has been extended until September 14. The >

Re: [swift-evolution] [proposal draft] new syntax to access a given case's payload

While I don’t have time to get into detail right now, you may be interested in an approach I used for a JSON framework: http://github.com/swiftrien/swifterjson In that approach I used the unix pipe operator “|” to chain a series of JSON accesses. In your example that would be written as: guard l

[swift-evolution] [proposal draft] new syntax to access a given case's payload

Summary The aim of this proposal is to offer a new syntax to ease some uses of enums with payload. Situation to improve: Enums makes it possible to have explicate typing where it was not possible before. A classic example of that is filling a dictionary with data coming from a file or a stream

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0142: Permit where clauses to constrain associated types

> The review of SE-0142: "Permit where clauses to constrain associated types" > begins now and runs through September 30, 2016. The proposal is available > here: > https://github.com/apple/swift-evolution/blob/master/proposals/0142-associated-types-constraints.md > What is your evaluation of the

Re: [swift-evolution] Propagating Optionals

> On 26 Sep 2016, at 00:26, William Sumner via swift-evolution > wrote: > >> >> let roomCount = john.residence.numberOfRooms >> >> // error: value of optional type 'Residence?' not unwrapped; did >> you mean to use '!' or '?'? >> >> As general rule of thumb, whenever I get an error and the

Re: [swift-evolution] Equatable auto-write func == Proposal

Hi, Am 2016-09-26 12:53, schrieb Francisco Costa via swift-evolution: +1 for making enums with payloads Equatable by default. Right now this requires lots of copy-paste boiler plate that can easily result in bugs. Of course, making structs and enums Equatable should be much easier (the same i

Re: [swift-evolution] Equatable auto-write func == Proposal

+1 for making enums with payloads Equatable by default. Right now this requires lots of copy-paste boiler plate that can easily result in bugs. As for the general struct case, I think there could be a default implementation but we should be able to overwrite `==` if we need to. Doesn't seem sensib

Re: [swift-evolution] Propagating Optionals

> On 25 Sep 2016, at 21:19, Trans via swift-evolution > wrote: > > "john.residence.numberOfRooms" could just behave one way or the other While I understand where you're coming from, I think the problem is that whichever version we specified as a guess would be wrong some of the time anyway,

Re: [swift-evolution] [Review] SE-0141: Availability by Swift version

Sorry this should have gone to the list... Sent from my iPhone > On 24 Sep 2016, at 09:19, Goffredo Marocchi wrote: > > Strong 1+, Swift would benefit from being abbot less dogmatic at compile time > and allow for more runtime flexibility especially with regards to third party > libraries. >

Re: [swift-evolution] [Review] SE-0141: Availability by Swift version

> What is your evaluation of the proposal? Seems like it will be greatly appreciated in the future for library authors. > Is the problem being addressed significant enough to warrant a change to > Swift? Yes, it will gives us a little bit more flexibility to break source/binary compatibility. >