Re: [swift-evolution] [Idea] Generic associated types

On Sun, Mar 12, 2017 at 1:39 AM, Karl Wagner wrote: > > On 12 Mar 2017, at 08:21, Xiaodi Wu wrote: > > Sorry, I'm confused. The following works: > > ``` > protocol Promise { > associatedtype Result > } > > protocol Scanner { > associatedtype

Re: [swift-evolution] [Idea] Generic associated types

> On 12 Mar 2017, at 08:21, Xiaodi Wu wrote: > > Sorry, I'm confused. The following works: > > ``` > protocol Promise { > associatedtype Result > } > > protocol Scanner { > associatedtype ScannerPromise : Promise > func frobnicate(_: T) -> ScannerPromise > where

Re: [swift-evolution] [Idea] Generic associated types

Sorry, I'm confused. The following works: ``` protocol Promise { associatedtype Result } protocol Scanner { associatedtype ScannerPromise : Promise func frobnicate(_: T) -> ScannerPromise where ScannerPromise.Result == T } ``` Why does it matter if `ScannerPromise` is generic

Re: [swift-evolution] [Idea] Generic associated types

> On 12 Mar 2017, at 06:51, Austin Zheng wrote: > > I think you want higher-kinded types. > https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#higher-kinded-types > >

Re: [swift-evolution] [Idea] Generic associated types

I think you want higher-kinded types. https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#higher-kinded-types Best, Austin > On Mar 11, 2017, at 9:49 PM, Karl Wagner via swift-evolution

[swift-evolution] [Idea] Generic associated types

I have a model like this: protocol Promise { associatedtype Result } protocol Scanner { associatedtype ScanPromise: Promise func promiseScan(from: Offset, until: (Offset, Item) -> T?) -> ScanPromise // where Result == T? } The thing that I’m trying to express is: whichever type

Re: [swift-evolution] Assignment to 'let' constant in defer blocks

> On Mar 10, 2017, at 9:33 PM, David Sweeris via swift-evolution > wrote: > > Is this a feature or a bug? Low priority bug IMO. -Chris > class Foo { > let bar: Int > init?(someConditionBasedOnInputData: Bool) { > var localBar: Int = 0 >

Re: [swift-evolution] [pitch] Variadic Arguments should accept Arrays

I read Haravikk's proposal a second time. I think I see the advantage of being able to use it with other types besides array. I also found disambiguating with the trailing comma to be intuitive. On the other hand I did not find it so intuitive to use @variadic and @nonVariadic to

Re: [swift-evolution] Infer types of default function parameters

> On Mar 11, 2017, at 3:17 PM, Jaden Geller via swift-evolution > wrote: > > As I understood it, omitting the type would work identically to `let` > declarations. A string literal without a type defaults to `String`. Treating > it as a generic function is a bad idea

Re: [swift-evolution] Infer types of default function parameters

Ahh, misunderstanding then. I had thought they were suggesting this was the default value of the typealias. Thanks for clearing that up, Jaden Geller > On Mar 11, 2017, at 5:08 PM, Robert Widmann wrote: > > You may be missing/misspelling the typealias declaration.

Re: [swift-evolution] Infer types of default function parameters

You may be missing/misspelling the typealias declaration. This has been in Policy.swift for a while now, and I can reproduce this as far back as 2.2 in the Bluemix sandbox. ~Robert Widmann > On Mar 11, 2017, at 7:41 PM, Jaden Geller via swift-evolution > wrote: >

Re: [swift-evolution] [swift-build-dev] [Review] SE-0158 Package Manager Manifest API Redesign

On Thu, Mar 9, 2017 at 12:34 AM, Ankit Aggarwal via swift-evolution < swift-evolution@swift.org> wrote: > > >> +1, although I don’t know why we're supporting this: >> >> // 1.5.8 ..< 2.0.0.package(url: "/SwiftyJSON", from: "1.5.8"), >> >> when, at least as far as I can tell, this: >> >> // 1.5.8

Re: [swift-evolution] Infer types of default function parameters

> On Mar 11, 2017, at 3:22 PM, Ben Cohen wrote: > >> >> On Mar 11, 2017, at 1:17 PM, Jaden Geller via swift-evolution >> > wrote: >> >> >> >> On Mar 11, 2017, at 12:20 PM, David Sweeris via swift-evolution

Re: [swift-evolution] Infer types of default function parameters

> On Mar 11, 2017, at 1:17 PM, Jaden Geller via swift-evolution > wrote: > > > > On Mar 11, 2017, at 12:20 PM, David Sweeris via swift-evolution > > wrote: > >> >>> On Mar 11, 2017, at 12:57 AM,

Re: [swift-evolution] Infer types of default function parameters

On Mar 11, 2017, at 12:20 PM, David Sweeris via swift-evolution > wrote: > >> On Mar 11, 2017, at 12:57 AM, Jean-Daniel via swift-evolution >> > wrote: >> >> -1 >> >>

Re: [swift-evolution] Infer types of default function parameters

> On Mar 11, 2017, at 12:57 AM, Jean-Daniel via swift-evolution > wrote: > > -1 > > It would be inconsistent to allow it for deterministic literals (String) and > not for non deterministic literal (int which can be either a Int, Uint, > Float, …) If I’m not

Re: [swift-evolution] [Draft] Fix ExpressibleByStringInterpolation

On Sat, Mar 11, 2017 at 5:34 AM, Brent Royal-Gordon wrote: > > On Mar 10, 2017, at 11:17 PM, Jacob Bandes-Storch > wrote: > > > > I'm confused by this example — was > > ExpressibleByFailableStringInterpolation's > init() supposed to be failable here?

Re: [swift-evolution] Assignment to 'let' constant in defer blocks

> On Mar 11, 2017, at 9:49 AM, and...@arnopoulos.io wrote: > > How would that work for a subclass, if all properties of a class need to be > initialized before the parent's initializer is called? > > -Andrew > > On Mar 11, 2017, at 8:46 AM, Derrick Ho via swift-evolution >

Re: [swift-evolution] Assignment to 'let' constant in defer blocks

> On Mar 11, 2017, at 7:46 AM, Derrick Ho wrote: > > Seems like it should work. Maybe it is a bug that should be reported to SR. > > Does this error occur for non-failable initializers? Yep ___ swift-evolution mailing list

Re: [swift-evolution] Assignment to 'let' constant in defer blocks

How would that work for a subclass, if all properties of a class need to be initialized before the parent's initializer is called? -Andrew > On Mar 11, 2017, at 8:46 AM, Derrick Ho via swift-evolution > wrote: > > Seems like it should work. Maybe it is a bug that

Re: [swift-evolution] [pitch] Variadic Arguments should accept Arrays

> I'd find it fantastic if they added > > var list: String... = 1, 2,3,4,5 If this list taught me anything, that it is that there is an incredible diversity what people like or dislike ;-) But would you really prefer that (wait a moment: String??? ;-) over var list: [Int] = 1, 2, 3 or boring

Re: [swift-evolution] Assignment to 'let' constant in defer blocks

Seems like it should work. Maybe it is a bug that should be reported to SR. Does this error occur for non-failable initializers? On Sat, Mar 11, 2017 at 12:33 AM David Sweeris via swift-evolution < swift-evolution@swift.org> wrote: > Is this a feature or a bug? > > class Foo { > let bar: Int

Re: [swift-evolution] Infer types of default function parameters

Previously: > On 10 Mar 2017, at 21:40, Kilian Koeltzsch

Re: [swift-evolution] [pitch] Variadic Arguments should accept Arrays

I'd find it fantastic if they added var list: String... = 1, 2,3,4,5 However if they remove Variadic arguments then apple would need to remove it from their apis. To name a few... print NSPredicate(format:) UIAlertView Removing variadic arguments would be a breaking change though. They would

Re: [swift-evolution] Infer types of default function parameters

+1 I like that python style shorthand. On Sat, Mar 11, 2017 at 6:36 AM Daniel Leping via swift-evolution < swift-evolution@swift.org> wrote: > I'm always positive with shorthand declarations, though this is a good > example of ambiguity pron case. > > Signatures are signatures. Let's not mess

Re: [swift-evolution] [Draft] Fix ExpressibleByStringInterpolation

> On Mar 10, 2017, at 11:17 PM, Jacob Bandes-Storch wrote: > > I'm confused by this example — was ExpressibleByFailableStringInterpolation's > init() supposed to be failable here? Ugh, yes, I'm sorry. That should have been: protocol

Re: [swift-evolution] Infer types of default function parameters

I'm always positive with shorthand declarations, though this is a good example of ambiguity pron case. Signatures are signatures. Let's not mess with them. On Sat, 11 Mar 2017 at 11:19 Haravikk via swift-evolution < swift-evolution@swift.org> wrote: > > On 10 Mar 2017, at 21:40, Kilian

Re: [swift-evolution] [pitch] Variadic Arguments should accept Arrays

>>> foo(["a", "b", "c"] as String...) >> >> I like this > > +1 I really don't get this: We have methods like NSLayoutConstraint.activate(_ constraints: [NSLayoutConstraint]), which works with an array, declares its parameter to be array and is called with an array. Quite simple. On the

Re: [swift-evolution] Infer types of default function parameters

> On 10 Mar 2017, at 21:40, Kilian Koeltzsch via swift-evolution > wrote: > > Hi all, > > I sent the message below to swift-users@ ~a day ago, but this might be a > better place to ask and gather some discussion. It is a rather minor > suggestion and I'm just

Re: [swift-evolution] Infer types of default function parameters

-1 It would be inconsistent to allow it for deterministic literals (String) and not for non deterministic literal (int which can be either a Int, Uint, Float, …) > Le 10 mars 2017 à 22:40, Kilian Koeltzsch via swift-evolution > a écrit : > > Hi all, > > I sent

Re: [swift-evolution] Infer types of default function parameters

0 Its not something I would use, but I don’t see why not. Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Balancingrock Project: http://swiftfire.nl > On 10 Mar 2017, at 22:40, Kilian Koeltzsch via swift-evolution >