Re: [swift-evolution] Mark protocol methods with their protocol

> Am 23.09.2016 um 12:47 schrieb Vladimir.S : > >> On 23.09.2016 11:05, Maximilian Hünenberger wrote: >> I'd also say that one or two keywords are superior than the protocol naming >> approach in terms of implementation simplicity (for the core team). >> >> My suggestions: >>

Re: [swift-evolution] Propagating Optionals

On Sep 25, 2016, at 4:19 PM, Trans via swift-evolution wrote:Basically "john.residence.numberOfRooms" is a completely wasted_expression_ -- it's meaningless.Not true; it's an attempt to access the `numberOfRooms` property on `Optional`. That property doesn't exist, but

Re: [swift-evolution] Mark UnicodeScalar.utf16 and UnicodeScalar.UTF16View as public

on Sun Sep 25 2016, Chris Lattner wrote: > +1, assuming Dave Abrahams agrees. > > -Chris Now that our comments have been addressed, I'm all for merging it. >> On Sep 23, 2016, at 6:02 AM, Robert Widmann via swift-evolution >> wrote: >> >> +1. This is a bug fix

Re: [swift-evolution] Propagating Optionals

> On Sep 25, 2016, at 2:19 PM, Trans via swift-evolution > wrote: > > As I've been learning Swift recently, one aspect of the language > jumped out at me with a "code smell". Namely, the way Optionals are > handled. For starters, just consider how long this chapter

[swift-evolution] Propagating Optionals

As I've been learning Swift recently, one aspect of the language jumped out at me with a "code smell". Namely, the way Optionals are handled. For starters, just consider how long this chapter is:

Re: [swift-evolution] Mark UnicodeScalar.utf16 and UnicodeScalar.UTF16View as public

+1, assuming Dave Abrahams agrees. -Chris > On Sep 23, 2016, at 6:02 AM, Robert Widmann via swift-evolution > wrote: > > +1. This is a bug fix in my mind, evolution is merely a formality. > > Ship it > > ~Robert Widmann > > 2016/09/22 18:59、Eli Perkins via

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

> On 25 Sep 2016, at 21:45, Drew Crawford wrote: > >> I think this is already part of the Generics Manifesto: >> https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md >> > So is this

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

I think this is already part of the Generics Manifesto:  https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md So is this proposal.  The proposal's "Motivation" is lifted from the Arbitrary Requirements in Protocols section: 

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

> On 24 Sep 2016, at 21:58, 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] Source-breaking proposals?

> 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? >

[swift-evolution] Source-breaking proposals?

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? ___ swift-evolution mailing list swift-evolution@swift.org

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

What is your evaluation of the proposal? +1 Is the problem being addressed significant enough to warrant a change to Swift? Yes Does this proposal fit well with the feel and direction of Swift? Yes If you have used other languages or libraries with a similar feature, how do you feel

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

What is your evaluation of the proposal? +1 Is the problem being addressed significant enough to warrant a change to Swift? Yes. A thousand times yes. Does this proposal fit well with the feel and direction of Swift? Yes. If you have used other languages or libraries with a similar

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

on Fri Sep 23 2016, Douglas Gregor wrote: > What is your evaluation of the proposal? It's ought to be obvious, but +1; when can I have it? > Is the problem being addressed significant enough to warrant a change > to Swift? Indeed. > Does this proposal fit well

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

> On 25 Sep 2016, at 04:07, Michael Gottesman wrote: > >> init(imageProducer:ImageProducer) { >> withExtendedLifetime(CanvasBase()) { >> super.init(javaObject: $0.javaObject) >> } >> image = createImage(imageProducer) >> } >> >>

Re: [swift-evolution] [Idea] Use optionals for non-optional parameters

Oops, completely missed about 57 messages in the meat of this discussion, so apologies if what I said was already suggested. On Sun, Sep 25, 2016 at 4:35 AM Dennis Lysenko wrote: > Could take a page out of Kotlin's book: > > x.let { foo(it) } // default argument name

Re: [swift-evolution] [Idea] Use optionals for non-optional parameters

Could take a page out of Kotlin's book: x.let { foo(it) } // default argument name that isn't $0 IMO, this syntax looks better as a one liner than "if x? { foo(x) }". The edge case here, with foo and bar being optional-returning functions, becomes: (foo(42), bar(43)).let { x, y in foo(x, y) }