Re: [swift-evolution] Improved Trailing Closure Syntax

on Wed Dec 28 2016, Nicholas Maccharoli wrote: > Swift Evolution, > > Swift's API Design Guidelines are really good in my opinion, but I believe > there is > ambiguity with current trailing closure syntax. > > Take for example if there were three variations of a

Re: [swift-evolution] Move placement of 'throws' statement

on Wed Dec 28 2016, Chris Lattner wrote: >> On Dec 28, 2016, at 9:52 AM, Dave Abrahams wrote: >> >>> it would be ambiguous to move the ‘throws’ keyword to the end of the >>> function type, because you'd get: >>> > >>> let x : (_ a : Int) -> (_ b: Float) -> Double

Re: [swift-evolution] Improved Trailing Closure Syntax

You can do this now. Since you can get a reference to the function you want by writing something like let function = subscribe(onNext:), you can do so and immediately call it: struct Event: CustomStringConvertible { var description: String { return "an event" } } func

[swift-evolution] Improved Trailing Closure Syntax

Swift Evolution, Swift's API Design Guidelines are really good in my opinion, but I believe there is ambiguity with current trailing closure syntax. Take for example if there were three variations of a `subscribe`function: func subscribe(onNext block: @escaping (Event) -> Void) { ... }

Re: [swift-evolution] Move placement of 'throws' statement

> On Dec 28, 2016, at 9:52 AM, Dave Abrahams wrote: > >> it would be ambiguous to move the ‘throws’ keyword to the end of the >> function type, because you'd get: >> >> let x : (_ a : Int) -> (_ b: Float) -> Double throws throws > > I see. > > We *could* say that

Re: [swift-evolution] Move placement of 'throws' statement

> On Dec 28, 2016, at 7:47 PM, Xiaodi Wu via swift-evolution > wrote: > > I thought there is already a pending proposal on typed throws? There was, I vaguely recall that it was by Russ? I don’t see any open PRs for it. I’m personally a big fan of typed throws,

Re: [swift-evolution] Move placement of 'throws' statement

+1 for optional type definition. As someone also coming from Java, I agree that its implementation is less than ideal. When I first suggested moving the `throws` statement, I thought the decision on whether or not to declare (even optionally) the exception types had already been made. I see now

Re: [swift-evolution] [Pitch] Add the DefaultConstructible protocol to the standard library

> On Dec 28, 2016, at 14:24, Xiaodi Wu wrote: > >> On Wed, Dec 28, 2016 at 5:21 PM, Anton Zhilin wrote: >> What about “Rust way”? >> >> protocol Default { >> static var `default`: Self { get } >> } >> >> protocol Setupable { >> mutable

Re: [swift-evolution] [Pitch] Add the DefaultConstructible protocol to the standard library

On Wed, Dec 28, 2016 at 5:21 PM, Anton Zhilin wrote: > What about “Rust way”? > > protocol Default { > static var `default`: Self { get } > } > > protocol Setupable { > mutable func setup(with params: Params) > } > > func setupArray(type: T.Type, params: Params)

Re: [swift-evolution] [Pitch] Add the DefaultConstructible protocol to the standard library

What about “Rust way”? protocol Default { static var `default`: Self { get } } protocol Setupable { mutable func setup(with params: Params) } func setupArray(type: T.Type, params: Params) -> [T] where T: Default & Setupable { return (1...42).map { i in var next =

Re: [swift-evolution] Move placement of 'throws' statement

-1 for addressing this now. Typed throws will undoubtedly affect this change and the two issues should be addressed at the same time. As a Java veteran, I agree with the sentiment to avoid the Java exception typing mechanism which complicates using and maintaining large projects. Knowing the

Re: [swift-evolution] Move placement of 'throws' statement

TLDR: I support moving throws, and also think that ‘typed throws’ should fit for Phase 2, at least. let x : (_ a : Int) -> (_ b: Float) throws -> Double throws Count me in those who cried in anger :) -- I see why current syntax is very logical for currying: let x:

Re: [swift-evolution] URL Literals

> On Dec 28, 2016, at 11:36, Xiaodi Wu via swift-evolution > wrote: > >> On Wed, Dec 28, 2016 at 2:29 PM, Micah Hainline via swift-evolution >> wrote: >> > SE-0039 says that resourceName should be a static-string-literal >> >> It

Re: [swift-evolution] URL Literals

I think the way it's set up it probably WOULD run, but it should still probably be a compile error. I like that we have the concept of static-string-literal in the language definition, but I'm having a bit of a hard time tracking it through the compiler. Of course, these are problems probably not

Re: [swift-evolution] URL Literals

> SE-0039 says that resourceName should be a static-string-literal It compiles just fine for me in my project. My next question was going to be do we actually need a change in the language spec, or can we call fixing that a bug, I think you're answering my question for me before I even had to ask

Re: [swift-evolution] URL Literals

On Wed, Dec 28, 2016 at 2:08 PM, Micah Hainline via swift-evolution < swift-evolution@swift.org> wrote: > As an aide to learning I've been playing around with implementation of > some of these concepts in the compiler and a few things popped up that > I'm not happy with. > > First, regarding the

Re: [swift-evolution] URL Literals

As an aide to learning I've been playing around with implementation of some of these concepts in the compiler and a few things popped up that I'm not happy with. First, regarding the way #fileLiteral works, it necessitates the addition of URL.init(fileReferenceLiteralResourceName:) which takes a

Re: [swift-evolution] Move placement of 'throws' statement

> On 28 déc. 2016, at 10:52, Dave Abrahams via swift-evolution > wrote: > > on Tue Dec 27 2016, Chris Lattner wrote: > >> it would be ambiguous to move the ‘throws’ keyword to the end of the >> function type, because you'd get: >> >> let x : (_ a : Int) -> (_

Re: [swift-evolution] Move placement of 'throws' statement

on Wed Dec 28 2016, Goffredo Marocchi wrote: > I sense s disturbance in the force as if hundreds of pure functional > programmers cried in anger ;). Remember: Your focus determines your reality. > >> On 28 Dec 2016, at 17:52, Dave Abrahams via swift-evolution >>

Re: [swift-evolution] Move placement of 'throws' statement

I sense s disturbance in the force as if hundreds of pure functional programmers cried in anger ;). Sent from my iPhone > On 28 Dec 2016, at 17:52, Dave Abrahams via swift-evolution > wrote: > > >> on Tue Dec 27 2016, Chris Lattner wrote: >> >> On Dec 26, 2016,

Re: [swift-evolution] Move placement of 'throws' statement

on Tue Dec 27 2016, Chris Lattner wrote: > On Dec 26, 2016, at 2:55 PM, Dave Abrahams via swift-evolution > wrote: >>> >>> // Move `throws` to the end >>> func baz() -> String throws >> >> I agree that reads much better. > > This doesn’t work unless you’re willing

Re: [swift-evolution] Replace named returns with `out` parameters?

-1 On Wed, Dec 28, 2016 at 9:37 AM Tony Allevato via swift-evolution < swift-evolution@swift.org> wrote: > –1. I'm not sure there's a reason to draw a line from > removal-of-tuple-splat to removal-of-tuple-returns, other than the idea > that they both involve tuples. In a lot of languages,

Re: [swift-evolution] Replace named returns with `out` parameters?

–1. I'm not sure there's a reason to draw a line from removal-of-tuple-splat to removal-of-tuple-returns, other than the idea that they both involve tuples. In a lot of languages, purely-"out" parameters are a workaround for the fact that the language wasn't designed to allow functions to return

Re: [swift-evolution] Replace named returns with `out` parameters?

Accidentally sent this offlist (why no 'reply to' header?) -thislooksfun (tlf) > On Dec 28, 2016, at 9:52 AM, thislooksfun wrote: > > This already basically exists in the form `inout` > // Define the function > func position(x: inout Int, y: inout Int) { > x = 0 >

Re: [swift-evolution] Replace named returns with `out` parameters?

Totally against out params. Returning tuples is way more logical & understandable BR Dominik Web: https://pich.info Twitter: @DaijDjan Facebook: Dominik.Pich > On 28 Dec 2016, at 15:06, Daniel Leping via swift-evolution > wrote: > > -1 here. What's wrong with

Re: [swift-evolution] Replace named returns with `out` parameters?

-1 here. What's wrong with tuples? Don't kill functional approach On Wed, 28 Dec 2016 at 19:35 Micah Hainline via swift-evolution < swift-evolution@swift.org> wrote: > You haven't really explained what problem this solves, and it would have > to be a pretty big one to justify such a change. > >

Re: [swift-evolution] Replace named returns with `out` parameters?

You haven't really explained what problem this solves, and it would have to be a pretty big one to justify such a change. I'm -1 on this, until a compelling argument is made. This feels like just liking the syntax of another language and wanting it in Swift. > On Dec 28, 2016, at 5:09 AM,

[swift-evolution] Replace named returns with `out` parameters?

Some people on the list wondered, why we have moved from tuples in function parameters, but multiple returns are still implemented using tuples? The following code still compiles: func position() -> (x: Int, y: Int) { return (x: 0, y: 0) } let (y, x) = position() (Maybe it’s a bad example,

Re: [swift-evolution] [Proposal] Change (Dispatch)Data.withUnsafeBytes to use UnsafeMutableBufferPointer

+1 Always in favour of consistency/uniformity (even if source-breaking changes are needed) ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution