[swift-evolution] Could enums have their rawValue type inferred?

[Eric Miller]

> automatically cast rawValue when assigning an enum value to
a variable or argument of the type of the enum's raw value

That's exactly what I'm thinking, Leonardo. I was a little bit trying to
avoid specifics because I don't understand the differences between
autocasting and inference.

There's a small miscommunication though--I've built api to accept the enum
type. Signature:

static func fadeIn(view: UIView?, withSpeed: Animate.transitionSpeed =
Animate.transitionSpeed.fast)

The goal was to provide my users with a good default and an easy set of
configurable options at the call site like `.fast`, `.normal`, `.slow`.

(unrelated: +1 on inferring type of function params with default values, I
hit this all the time)

Calling:

Animate.fadeIn(myView, withSpeed: .slow)

Works great.

This library of methods is a facade for CABasicAnimation or UIView
animations which take an NSTimeInterval, and that's where the "autocasting"
would come into play.



------------------------------

Message: 31
Date: Fri, 13 May 2016 16:58:06 -0300
From: Leonardo Pessoa <me at lmpessoa.com>
To: Swift-evolution <swift-evolution at swift.org>
Subject: Re: [swift-evolution] Could enums have their rawValue type
        inferred?
Message-ID:
        <CANTOS57wksMRzUAMq0ncf1QAd82vhudf21tnea6wHjhBOFr1PA at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Eric, I think I understood your proposal. If I may explain in other words
it would be "to automatically cast rawValue when assigning an enum value to
a variable or argument of the type of the enum's raw value", am I right? I
think this would imply a little more inference and type checking rules from
the compiler and maybe even take a little longer to fully compile code. I'm
not sure it's feasible but from your examples, I can see how it enhances
readability of the code, so I'm +1 for it. My only concern is that you
would still need to fully declare the enum's name where the value of the
enum is used. Taking from your own example

    Animate.fadeIn(view, withSpeed: .fast)

couldn't be called that way if withSpeed expects and NSTimeInterval because
the compiler won't know whether you're refering to transitionSpeed or to
ambientAnimationSpeed. You would still have to call it like

    Animate.fadeIn(view, withSpeed: transitionSpeed.fast)

even if you had only one possible enum value over all declared enums
because that would still force the compiler to search for each value over
all known enums to define where the value you're using comes from and make
sure there are no two enums with the same value.

Aside from that, I good with the idea.



On 13 May 2016 at 15:09, Eric Miller via swift-evolution <
swift-evolution at swift.org> wrote:

> This might open a larger can of worms than I imagine, but what do you
> folks think about using the `rawValue` of an enum when that rawValue is a
> fit for the expected type?
>
> Use case.
>
> I'm making an animation facade, and it has some speed presets:
>
> class Animate {
>   enum transitionSpeed: NSTimeInterval {
>     case fast = 0.15
>     case slow = 0.5
>   }
>   enum ambientAnimationSpeed: NSTimeInterval {
>     case fast = 1.0
>     case slow = 5.0
>   }
>   ...
> }
>
> I did them with static variables at first but that made the call site
> verbose. Compare:
>
> Animate.fadeIn(view, withSpeed: Animate.cfg.transitionFast)
> Animate.fadeIn(view, withSpeed: .fast)
>
> So, I like the enum approach better, but my library code has to use
> `rawValue` to do anything with the actual value, of course:
>
> static func fadeIn(view: UIView?, withSpeed duration:transitionSpeed =
> .fast) {
>   ...
>   UIView.animateWithDuration(duration.rawValue, animations: { })
> }
>
> It's not a serious issue, but the code is more clear and beautiful if it
> has just myIntent, rather than myIntent.rawValue.
>
> I've hit this issue when modeling other things, such as:
>
> * server fault codes
> * HTTP status codes
> * Currency codes
> * Days of the week
>
> Would it be appropriate to "autocast" to the rawValue of the enum when the
> rawValue's Type matches the type expectation of the API? Or would this
> introduce a bunch of type system uncertainty?
>
> Maybe this could be implemented as a protocol? It feels almost like the
> convenience of `CustomStringConvertible`'s `description` property.

On Fri, May 13, 2016 at 11:24 PM, <swift-evolution-request at swift.org> wrote:

> Send swift-evolution mailing list submissions to
>         swift-evolution at swift.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.swift.org/mailman/listinfo/swift-evolution
> or, via email, send a message with subject or body 'help' to
>         swift-evolution-request at swift.org
>
> You can reach the person managing the list at
>         swift-evolution-owner at swift.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of swift-evolution digest..."
>
>
> Today's Topics:
>
>    1. Re: [Pitch] merge types and protocols back together with
>       type<Type, Protocol, ...> (Vladimir.S)
>    2. Re: [Pitch] merge types and protocols back together with
>       type<Type, Protocol, ...> (Vladimir.S)
>    3. Re: [Pitch] merge types and protocols back together with
>       type<Type, Protocol, ...> (Ross O'Brien)
>    4. Re: Removing "_ in" from empty closures (Cole Campbell)
>    5. Re: [Review] SE-0084: Allow trailing commas in parameter
>       lists and tuples (Joe Groff)
>    6. Re: [Pitch] merge types and protocols back together with
>       type<Type, Protocol, ...> (Adrian Zubarev)
>    7. Re: [Review] SE-0084: Allow trailing commas in parameter
>       lists and tuples (Joe Groff)
>    8. Re: [Review] SE-0084: Allow trailing commas in parameter
>       lists and tuples (Vladimir.S)
>    9. Re: [Review] SE-0084: Allow trailing commas in    parameter
>       lists and tuples (Erica Sadun)
>   10. Re: [Pitch] merge types and protocols back together with
>       type<Type, Protocol, ...> (Adrian Zubarev)
>   11. Re: Removing "_ in" from empty closures (Erica Sadun)
>   12. Re: [swift-evolution-announce] [Review] SE-0041:  Updating
>       Protocol  Naming Conventions for Conversions (Pyry Jahkola)
>   13. Could enums have their rawValue type inferred? (Eric Miller)
>   14. Re: [Draft] Introducing StaticSelf,       an Invariant Self
>       (Nicola Salmoria)
>   15. Re: [Review] SE-0045: Add scan, prefix(while:),   drop(while:),
>       and iterate to the stdlib (Erica Sadun)
>   16. Re: [Review] SE-0075: Adding a Build      Configuration Import
>       Test (Pyry Jahkola)
>   17. [draft-proposal] allow access to the underlying   collection of
>       a slice (Max Moiseev)
>   18. Re: [Review] SE-0084: Allow trailing commas in parameter
>       lists and tuples (Joe Groff)
>   19. Interspersing guard let with guard boolean (Erica Sadun)
>   20. Re: Interspersing guard let with guard boolean (Joe Groff)
>   21. Re: Interspersing guard let with guard boolean (Erica Sadun)
>   22. Re: [Pitch] merge types and protocols back together with
>       type<Type, Protocol, ...> (Vladimir.S)
>   23. Re: [Review] SE-0088: Modernize libdispatch for   Swift 3
>       naming conventions (Matt Wright)
>   24. Re: [Draft] Introducing StaticSelf,       an Invariant Self
>       (Matthew Johnson)
>   25. Re: [Review] SE-0045: Add scan, prefix(while:), drop(while:),
>       and iterate to the stdlib (Kevin Ballard)
>   26. Re: [Pitch] merge types and protocols back together with
>       type<Type, Protocol, ...> (Adrian Zubarev)
>   27. Re: [Review] SE-0088: Modernize libdispatch for Swift 3
>       naming conventions (Jacob Bandes-Storch)
>   28. Re: [Review] SE-0088: Modernize libdispatch for Swift 3
>       naming conventions (Xiaodi Wu)
>   29. Re: [Review] SE-0088: Modernize libdispatch for   Swift 3
>       naming conventions (Matt Wright)
>   30. Re: [Review] SE-0088: Modernize libdispatch for   Swift 3
>       naming conventions (Matt Wright)
>   31. Re: Could enums have their rawValue type inferred?
>       (Leonardo Pessoa)
>   32. Re: Removing "_ in" from empty closures (Jacob Bandes-Storch)
>   33. Re: Removing "_ in" from empty closures (Matthew Johnson)
>   34. Re: [Draft] Introducing StaticSelf,       an Invariant Self (Joe
> Groff)
>   35. Re: Removing "_ in" from empty closures (Joe Groff)
>   36. Re: [Review] SE-0084: Allow trailing commas in parameter
>       lists and tuples (John Siracusa)
>   37. Re: [Pitch] merge types and protocols back together with
>       type<Type, Protocol, ...> (Vladimir.S)
>   38. Re: [Draft] Introducing StaticSelf, an Invariant Self (Vladimir.S)
>   39. Re: Removing "_ in" from empty closures (Matthew Johnson)
>   40. Re: [Review] SE-0088: Modernize libdispatch for   Swift   3
>       naming conventions (Matt Wright)
>   41. Re: [Pitch] merge types and protocols back together with
>       type<Type, Protocol, ...> (Adrian Zubarev)
>   42. Re: [Pitch] merge types and protocols back        together with
>       type<Type, Protocol, ...> (Matthew Johnson)
>   43. Re: [Draft] Introducing StaticSelf,       an Invariant Self
>       (Matthew Johnson)
>   44. Re: [Pitch] merge types and protocols back together with
>       type<Type, Protocol, ...> (Austin Zheng)
>   45. Re: [Review] SE-0081: Move where clause to end of declaration
>       (Jon Shier)
>   46. Re: [Pitch] Consistent bridging for NSErrors at   the language
>       boundary (Jon Shier)
>   47. Re: [Review] SE-0045: Add scan, prefix(while:),   drop(while:),
>       and iterate to the stdlib (Patrick Smith)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 13 May 2016 20:04:46 +0300
> From: "Vladimir.S" <svabox at gmail.com>
> To: Adrian Zubarev <adrian.zubarev at devandartist.com>
> Cc: swift-evolution <swift-evolution at swift.org>
> Subject: Re: [swift-evolution] [Pitch] merge types and protocols back
>         together with type<Type, Protocol, ...>
> Message-ID: <2f3fbb45-173f-15b4-492d-c059899d5482 at gmail.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> On 13.05.2016 19:38, Adrian Zubarev via swift-evolution wrote:
> > Why would you want to add all of these different formats where only one
> > could serve them all. This is redundant in my opinion.
> >
> > `struct<>` and `enum<>` would have same rules, only the first element
> would
> > be a different value-type. I might consider this as an alternative.
> >
>
> Actually, I fully support your idea and strongly +1 for `type<>` keyword. I
> don't believe it will confuse anyone as protocol<> does not confuse
> currently.
>
> But as I can see, the community(or core team) is strongly against of using
> `type` keyword.
> So, we have situation : protocol<> and .. all<> ? Will all<> include
> protocols also? Probably I'd support to remove protocol<> and introduce
> just all<> for all :-) But if we have protocol<> and can't have type<> - I
> asked why we can't for clarity and consistency have class<> struct<>
>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 13 May 2016 20:08:57 +0300
> From: "Vladimir.S" <svabox at gmail.com>
> To: Adrian Zubarev <adrian.zubarev at devandartist.com>
> Cc: swift-evolution <swift-evolution at swift.org>
> Subject: Re: [swift-evolution] [Pitch] merge types and protocols back
>         together with type<Type, Protocol, ...>
> Message-ID: <b8fdfea7-e174-718e-5b28-6ec373f1d8b4 at gmail.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Btw, if we'd have separate class<> and struct<> - we'd be able to have
> method to separate reference type from value type.
>
> We can write now : print(c is protocol<>)
>
> and we'd can:
>
> print(c is class<>)
> print(c is struct<>)
>
> Just thoughts..
>
> On 13.05.2016 20:04, Vladimir.S wrote:
> > On 13.05.2016 19:38, Adrian Zubarev via swift-evolution wrote:
> >> Why would you want to add all of these different formats where only one
> >> could serve them all. This is redundant in my opinion.
> >>
> >> `struct<>` and `enum<>` would have same rules, only the first element
> would
> >> be a different value-type. I might consider this as an alternative.
> >>
> >
> > Actually, I fully support your idea and strongly +1 for `type<>`
> keyword. I
> > don't believe it will confuse anyone as protocol<> does not confuse
> currently.
> >
> > But as I can see, the community(or core team) is strongly against of
> using
> > `type` keyword.
> > So, we have situation : protocol<> and .. all<> ? Will all<> include
> > protocols also? Probably I'd support to remove protocol<> and introduce
> > just all<> for all :-) But if we have protocol<> and can't have type<> -
> I
> > asked why we can't for clarity and consistency have class<> struct<>
>
>
> ------------------------------
>
> Message: 3
> Date: Fri, 13 May 2016 18:11:11 +0100
> From: "Ross O'Brien" <narrativium+swift at gmail.com>
> To: Adrian Zubarev <adrian.zubarev at devandartist.com>
> Cc: swift-evolution <swift-evolution at swift.org>
> Subject: Re: [swift-evolution] [Pitch] merge types and protocols back
>         together with type<Type, Protocol, ...>
> Message-ID:
>         <
> CAPUwzK55PQYDT4j1UBS69KSo410xKWR3js9dY1W8cBsjJshU6g at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> In reply to:
>
> Why would you want to add all of these different formats where only one
> could serve them all. This is redundant in my opinion.
>
> `struct<>` and `enum<>` would have same rules, only the first element would
> be a different value-type. I might consider this as an alternative.
>
> Correct me if I’m wrong with the redundancy.
>
>
> 'enum<>' might be valid, unless their functions (e.g. for 'init(rawValue:
> Int)' or 'allCases') are declared in explicit protocols which would
> implicitly cover enums and which other types could declare conformance to.
>
> 'struct<>' does seem redundant unless it becomes subtypeable. If you want a
> struct which conforms to several protocols, protocol<> already covers this.
> I know there's a discussion at the moment regarding the equivalent of an
> 'AnyObject' for value types, which might apply to this discussion, but I'm
> not sure how.
>
> A class in general would also a protocol<AnyObject, ...>. The benefit of
> 'type<>' is in its ability to extend the behaviours of several subclasses
> at once, e.g. type<UIViewController, UIScrollViewDelegate> covers all view
> controllers with scroll views, not just UITableViewController,
> UICollectionViewController, etc..
>
>
>
> ​
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/4ace2772/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 4
> Date: Fri, 13 May 2016 12:14:23 -0500
> From: Cole Campbell <cole.m.campbell at icloud.com>
> To: Joe Groff <jgroff at apple.com>
> Cc: Chris Lattner via swift-evolution <swift-evolution at swift.org>
> Subject: Re: [swift-evolution] Removing "_ in" from empty closures
> Message-ID: <4FC7FC81-FDF2-471D-8C0E-DA5A037AA6D3 at icloud.com>
> Content-Type: text/plain; charset=us-ascii
>
>
> > +1. In general, I think we should allow implicit arguments, without
> requiring the closure to use all the implicit $n variables like we do
> today. These should all be valid:
> >
> > let _: () -> () = {}
> > let _: (Int) -> () = {}
> > let _: (Int, Int) -> Int = { 5 }
> > let _: (Int, Int) -> Int = { $0 }
> > let _: (Int, Int) -> Int = { $1 }
>
> +1. This would be excellent.
>
> ------------------------------
>
> Message: 5
> Date: Fri, 13 May 2016 10:29:01 -0700
> From: Joe Groff <jgroff at apple.com>
> To: Erica Sadun <erica at ericasadun.com>
> Cc: Chris Lattner via swift-evolution <swift-evolution at swift.org>
> Subject: Re: [swift-evolution] [Review] SE-0084: Allow trailing commas
>         in parameter lists and tuples
> Message-ID: <304E28A1-D8D0-43A2-BF7A-FBAEF8828F6D at apple.com>
> Content-Type: text/plain; charset=utf-8
>
>
> > On May 13, 2016, at 7:04 AM, Erica Sadun <erica at ericasadun.com> wrote:
> >
> > On May 12, 2016, at 11:01 PM, Chris Lattner via swift-evolution <
> swift-evolution at swift.org> wrote:
> >> On May 12, 2016, at 4:50 PM, Joe Groff <jgroff at apple.com> wrote:
> >>>> You’re arguing that you want to read Swift code written like this?
> >>>
> >>> I wouldn't mind it.
> >>
> >> I personally find that style repulsive :-) and I haven’t seen swift
> code commonly doing it.  I’m not sure that we want to encourage it either.
> >>
> >
> > No. Tell us what you *really* think of the style. Don't hold back.[1]
> >
> >> If we were really concerned about this, a narrower way to solve the
> same problem would be to allow a comma before the ), but *only* when there
> is a newline between them.  I still don’t see why we’d want to encourage
> this though.
> >
> > I wouldn't object to this restriction. I cannot think of a situation
> where using ",)" -- that is the comma adjacent to a closing parenthesis --
> makes sense for any reason previously enumerated in support of this
> proposal.
>
> I don't see why we need to micromanage the situations where trailing
> commas are allowed. That's just unnecessarily increasing the fractal
> complexity of the language. We've delegated other style choices like
> requiring `self.` or brace formatting to linters; why does this one need to
> be legislated by the compiler?
>
> -Joe
>
> ------------------------------
>
> Message: 6
> Date: Fri, 13 May 2016 19:32:34 +0200
> From: Adrian Zubarev <adrian.zubarev at devandartist.com>
> To: swift-evolution at swift.org
> Subject: Re: [swift-evolution] [Pitch] merge types and protocols back
>         together with type<Type, Protocol, ...>
> Message-ID: <etPan.57360fb2.5ed02b43.6ab2 at DevAndArtist.fritz.box>
> Content-Type: text/plain; charset="utf-8"
>
> 'struct<>' does seem redundant unless it becomes subtypeable. If you want
> a struct which conforms to several protocols, protocol<> already covers
> this.
> I think this is not correct. Lets check this example:
>
> func foo(value: SomeProtocol) {
>
>     if let a = value as? struct<StructA, SomeProtocol> { /* do something
> with a */ }
>
>     else if let b = value as? struct<StructB, SomeProtocol> { /* do
> something with b */ }
>
> }
>
> In this scenario you’ll be able to access properties and functions from
> `StructA` or `StructB` which might not be covered by `SomeProtocol`.
> Everything is merged nicely into one instance. But you are right it depends
> on the use-case.
>
>
>
> Btw, if we'd have separate class<> and struct<> - we'd be able to
> have method to separate reference type from value type.
> We can write now : print(c is protocol<>)
> and we'd can:
> print(c is class<>)
> print(c is struct<>)
>
> True, I didn’t thought about that effect at the first glance, thank you
> for the hint. I will add this to the draft proposal tomorrow.
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/4a9f75e9/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 7
> Date: Fri, 13 May 2016 10:32:34 -0700
> From: Joe Groff <jgroff at apple.com>
> To: Matthew Johnson <matthew at anandabits.com>,   Matthew Johnson via
>         swift-evolution <swift-evolution at swift.org>
> Subject: Re: [swift-evolution] [Review] SE-0084: Allow trailing commas
>         in parameter lists and tuples
> Message-ID: <76E430C3-01EF-45B3-B00E-01490E75DCAA at apple.com>
> Content-Type: text/plain; charset=utf-8
>
>
> > On May 13, 2016, at 7:32 AM, Matthew Johnson via swift-evolution <
> swift-evolution at swift.org> wrote:
> >
> >
> >
> > Sent from my iPad
> >
> >> On May 13, 2016, at 9:19 AM, Vladimir.S <svabox at gmail.com> wrote:
> >>
> >>> On 13.05.2016 16:32, Matthew Johnson wrote:
> >>> I am, +1 on allowing new lines instead of commas.  I suggest you
> pursue a proposal on that.
> >>
> >> Unfortunately I have no ability for this right now, so someone who is
> interested in this could take the idea and create a 'formal' proposal.
> >>
> >>>
> >>> I am also +1 on the current proposal because it exists and will be
> pretty useful in some cases and I can't predict how long it might be until
> such a new line proposal would be approved.  I also think that the choice
> between them should be a style choice, not one made by the language (as
> with semicolon) and if anyone chooses commas they should have the utility
> of the current proposal available to them.
> >>
> >> Don't you feel like this proposal(SE-0084) should be extended to list
> of generic types at least, or even to allow trailing comma in any
> comma-separated list in Swift? I.e. you are saying +1, but probably the
> exact proposal should be improved to have your +1.
> >
> > I have no opinion on that.  I don't object to it being done in the name
> of consistency but can't think of any actual use cases either.
> >>
> >> Probably (if this is allowed) the author of this proposal (SE-0084) can
> add 'line-break separator feature' to his/her proposal and generalize the
> rule of trailing comma/line-breaks for any comma-separated list in Swift?
> >
> > That feels like a separate proposal to me.
>
> I agree, allowing commas to be elided at line breaks is an interesting
> direction that deserves its own discussion. One problem that immediately
> comes to my mind is commas in generic parameter lists. If commas aren't
> required in generic parameter lists, it becomes even more challenging to
> disambiguate with less-than/greater-than expressions at top level,
> compromising our ability to shed `.self` for this purpose.
>
> -Joe
>
> >>
> >> As I can see, the proposal SE-0084 'per se' has more negative comments
> than positive(even if some from @apple.com supports it) and I feel like
> extended proposal can have more support.
> >>
> >>>
> >>> Sent from my iPad
> >>>
> >>>> On May 13, 2016, at 1:24 AM, Vladimir.S via swift-evolution <
> swift-evolution at swift.org> wrote:
> >>>>
> >>>> IMO If we were *really* concerned about this, we should just allow
> line-break as separator in comma-separated lists.
> >>>>
> >>>>> On 13.05.2016 8:01, Chris Lattner via swift-evolution wrote:
> >>>>> If we were really concerned about this, a narrower way to solve the
> same problem would be to allow a comma before the ), but *only* when there
> is a newline between them.  I still don’t see why we’d want to encourage
> this though.
> >>>> _______________________________________________
> >>>> swift-evolution mailing list
> >>>> swift-evolution at swift.org
> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution
> >>>
> >>>
> >
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> ------------------------------
>
> Message: 8
> Date: Fri, 13 May 2016 20:42:10 +0300
> From: "Vladimir.S" <svabox at gmail.com>
> To: Joe Groff <jgroff at apple.com>
> Cc: swift-evolution <swift-evolution at swift.org>
> Subject: Re: [swift-evolution] [Review] SE-0084: Allow trailing commas
>         in parameter lists and tuples
> Message-ID: <d487fba4-581b-2c76-145e-b7b79477b395 at gmail.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Support. *all or nothing* :-)
>
> On 13.05.2016 20:29, Joe Groff via swift-evolution wrote:
> > I don't see why we need to micromanage the situations where trailing
> commas are allowed. That's just unnecessarily increasing the fractal
> complexity of the language. We've delegated other style choices like
> requiring `self.` or brace formatting to linters; why does this one need to
> be legislated by the compiler?
>
>
> ------------------------------
>
> Message: 9
> Date: Fri, 13 May 2016 11:46:39 -0600
> From: Erica Sadun <erica at ericasadun.com>
> To: Joe Groff <jgroff at apple.com>
> Cc: Chris Lattner via swift-evolution <swift-evolution at swift.org>
> Subject: Re: [swift-evolution] [Review] SE-0084: Allow trailing commas
>         in      parameter lists and tuples
> Message-ID: <A9ADA97C-DB1F-4556-A290-36BBE2357975 at ericasadun.com>
> Content-Type: text/plain; charset="utf-8"
>
>
> > On May 13, 2016, at 11:29 AM, Joe Groff <jgroff at apple.com> wrote:
> >
> >>
> >> On May 13, 2016, at 7:04 AM, Erica Sadun <erica at ericasadun.com> wrote:
> >>
> >> On May 12, 2016, at 11:01 PM, Chris Lattner via swift-evolution <
> swift-evolution at swift.org> wrote:
> >>> On May 12, 2016, at 4:50 PM, Joe Groff <jgroff at apple.com> wrote:
> >>>>> You’re arguing that you want to read Swift code written like this?
> >>>>
> >>>> I wouldn't mind it.
> >>>
> >>> I personally find that style repulsive :-) and I haven’t seen swift
> code commonly doing it.  I’m not sure that we want to encourage it either.
> >>>
> >>
> >> No. Tell us what you *really* think of the style. Don't hold back.[1]
> >>
> >>> If we were really concerned about this, a narrower way to solve the
> same problem would be to allow a comma before the ), but *only* when there
> is a newline between them.  I still don’t see why we’d want to encourage
> this though.
> >>
> >> I wouldn't object to this restriction. I cannot think of a situation
> where using ",)" -- that is the comma adjacent to a closing parenthesis --
> makes sense for any reason previously enumerated in support of this
> proposal.
> >
> > I don't see why we need to micromanage the situations where trailing
> commas are allowed. That's just unnecessarily increasing the fractal
> complexity of the language. We've delegated other style choices like
> requiring `self.` or brace formatting to linters; why does this one need to
> be legislated by the compiler?
> >
> > -Joe
>
> Mostly because I'm trying to play nice and get Chris to reconsider. I'd
> like to get the feature, I'm willing to compromise on the technicalities.
> Having it would make my coding life significantly easier and if a little
> micromanagement is involved, I'm not terribly fussed. When I need trailing
> commas, it's always at the ends of lines anyway.
>
> But since I don't want to undercut you, so I'd much prefer to step back
> and defer to your judgement on this.
>
> -- E
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/5fa7ba20/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 10
> Date: Fri, 13 May 2016 19:50:38 +0200
> From: Adrian Zubarev <adrian.zubarev at devandartist.com>
> To: swift-evolution at swift.org
> Subject: Re: [swift-evolution] [Pitch] merge types and protocols back
>         together with type<Type, Protocol, ...>
> Message-ID: <etPan.573613ee.5477cc5d.6ab2 at DevAndArtist.fritz.box>
> Content-Type: text/plain; charset="utf-8"
>
> 'struct<>' does seem redundant unless it becomes subtypeable. If you want
> a struct which conforms to several protocols, protocol<> already covers
> this.
> I think this is not correct. Lets check this example:
>
> func foo(value: SomeProtocol) {
>
>     if let a = value as? struct<StructA, SomeProtocol> { /* do something
> with a */ }
>
>     else if let b = value as? struct<StructB, SomeProtocol> { /* do
> something with b */ }
>
> }
>
> In this scenario you’ll be able to access properties and functions from
> `StructA` or `StructB` which might not be covered by `SomeProtocol`.
> Everything is merged nicely into one instance. But you are right it depends
> on the use-case.
>
>
> There is no need to include the protocol here.   Just do this:
>
> if let a = value as? StructA { use a }
>
> Whoops, I forgot that this will do the trick. I apologize for any
> confusion here, you are totally right.
>
> That been said, do we really need `type<>` aka. `all<>` for value types? I
> need to rethink this part of the proposal. Is there any use-case where we
> would need this (any scenario for the future Swift version also counts)?
>
> If we had `all<>` in Swift already for extendable reference types and one
> day structs would become subtypeable, this wouldn’t be a huge problem to
> upgrade `all<>` for structs I guess.
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/b51d2c61/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 11
> Date: Fri, 13 May 2016 11:48:30 -0600
> From: Erica Sadun <erica at ericasadun.com>
> To: Cole Campbell <cole.m.campbell at icloud.com>
> Cc: Chris Lattner via swift-evolution <swift-evolution at swift.org>
> Subject: Re: [swift-evolution] Removing "_ in" from empty closures
> Message-ID: <2F3D83D2-2785-4778-B7C1-91B0EF2381D1 at ericasadun.com>
> Content-Type: text/plain; charset=us-ascii
>
> On May 13, 2016, at 11:14 AM, Cole Campbell via swift-evolution <
> swift-evolution at swift.org> wrote:
> >
> >
> >> +1. In general, I think we should allow implicit arguments, without
> requiring the closure to use all the implicit $n variables like we do
> today. These should all be valid:
> >>
> >> let _: () -> () = {}
> >> let _: (Int) -> () = {}
> >> let _: (Int, Int) -> Int = { 5 }
> >> let _: (Int, Int) -> Int = { $0 }
> >> let _: (Int, Int) -> Int = { $1 }
> >
> > +1. This would be excellent.
>
> +1. Good riddance to bad code baggage.
>
> -- E
>
>
>
> ------------------------------
>
> Message: 12
> Date: Fri, 13 May 2016 21:03:19 +0300
> From: Pyry Jahkola <pyry.jahkola at iki.fi>
> To: Matthew Johnson <matthew at anandabits.com>
> Cc: swift-evolution at swift.org
> Subject: Re: [swift-evolution] [swift-evolution-announce] [Review]
>         SE-0041:        Updating Protocol       Naming Conventions for
> Conversions
> Message-ID: <1AAA5C78-073C-4515-80E6-AC64888FC725 at iki.fi>
> Content-Type: text/plain; charset="utf-8"
>
> Taking the suggested changes into account, here's my review.
>
> 1) +1, I think this is a reasonable way for naming this family of
> protocols.
>
> 2) The problem isn't huge, but I think it's worth fixing. So far, the
> naming of stdlib protocols has been somewhat inconsistent in this regard.
>
> 3) I've used other languages & stdlibs with similar naming schemes,
> although none of them used the words "initializable" and "representable".
> Common alternatives have been word compositions involving expressions such
> as "convertible", "from", "to", "bi(jective)", "can build". However, I
> think "init" is so central in Swift that the use of "Initializable" is well
> justified. "Representable" is slightly less so but self-explanatory IMO,
> and more so than "convertible" which could be understood either or both
> ways.
>
> 4) Quick reading.
>
> — Pyry
>
> > On 13 May 2016, Matthew Johnson wrote:
> >
> > While the community feedback on our SE-0041 proposal "Updating Protocol
> Naming Conventions for Conversions" (
> https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md
> <
> https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md>)
> has been positive about the need to establish conventions, feedback has
> been mixed to negative with regard to the specific conventions suggested in
> the proposal.
> >
> > With that in mind, Erica and I have been working on refactoring those
> recommendations. We put together the following update and invite the
> community to bikeshed further with us. We hope this offers the Swift core
> team the flexibility to accept our proposal "with revision" if an
> alternative garners more support. With luck, we'll reach a naming consensus
> during the review period.
> >
> > UPDATED APPROACH
> >
> > Our updated approach focuses on the two most important conventions: one
> for initialization and one for representation.
> >
> > 1. `Initializable`
> >
> > `Initializable` designates protocols that convert *from* a type or from
> an associated type mentioned in the protocol name, such as the current
> `<Type>LiteralConvertible` protocols.  This convention would include member
> requirements for initializers, factory methods, and any other way an
> instance can be imported to establish a new instance of the conforming type.
> >
> > For example, conforming to `ArrayLiteralInitializable` would allow a set
> to be created with `Set(arrayLiteral: <some array>)` and `var set: Set<T> =
> []`.
> >
> > This phrase replaces the `Creatable` form from our original proposal.
> >
> > 2. `Representable`
> >
> > `Representable` designates protocols whose primary purpose is to project
> *to* a type or associated type mentioned in the protocol name.  Items in
> the standard library that would be subsumed into this naming include
> `CustomStringConvertible`, `CustomDebugStringConvertible`, and
> `RawRepresentable`, which we imagine would become
> `CustomStringRepresentable`, `CustomDebugStringRepresentable`, and (as
> current) `RawRepresentable`.
> >
> > This second category groups together the `Convertible` and
> `Representable` categories from our original proposal and is predicated on
> the feedback from the design team review. The `Representable` designation
> does not promise bidirectional conversion although some `Representable`
> protocols may include requirements to allow attempted initialization *from*
> the type of the representation. Doing so falls outside the naming contract
> we are proposing.
> >
> > FUTURE DIRECTIONS
> >
> > We did not include a third category for bidirectional conversion in this
> update. We recognize that style of contract is rare in Swift. Lossless
> conversion does not appear in the standard library outside of
> `RawRepresentable`, which we agreed was better covered by `Representable`.
> If such a convention is needed or adopted, we reserve the `Isomorphic`
> designation for future use.
> >
> > Sent from my iPad
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/b88c8136/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 13
> Date: Fri, 13 May 2016 12:09:01 -0600
> From: Eric Miller <hi at simple.gy>
> To: swift-evolution at swift.org
> Subject: [swift-evolution] Could enums have their rawValue type
>         inferred?
> Message-ID:
>         <CAJaDgbjTQMo8keEa=
> 4+neJp_yPgRpi3rdsSnrAMmwJbonLQEKQ at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> This might open a larger can of worms than I imagine, but what do you folks
> think about using the `rawValue` of an enum when that rawValue is a fit for
> the expected type?
>
> Use case.
>
> I'm making an animation facade, and it has some speed presets:
>
> class Animate {
>   enum transitionSpeed: NSTimeInterval {
>     case fast = 0.15
>     case slow = 0.5
>   }
>   enum ambientAnimationSpeed: NSTimeInterval {
>     case fast = 1.0
>     case slow = 5.0
>   }
>   ...
> }
>
> I did them with static variables at first but that made the call site
> verbose. Compare:
>
> Animate.fadeIn(view, withSpeed: Animate.cfg.transitionFast)
> Animate.fadeIn(view, withSpeed: .fast)
>
> So, I like the enum approach better, but my library code has to use
> `rawValue` to do anything with the actual value, of course:
>
> static func fadeIn(view: UIView?, withSpeed duration:transitionSpeed =
> .fast) {
>   ...
>   UIView.animateWithDuration(duration.rawValue, animations: { })
> }
>
> It's not a serious issue, but the code is more clear and beautiful if it
> has just myIntent, rather than myIntent.rawValue.
>
> I've hit this issue when modeling other things, such as:
>
> * server fault codes
> * HTTP status codes
> * Currency codes
> * Days of the week
>
> Would it be appropriate to "autocast" to the rawValue of the enum when the
> rawValue's Type matches the type expectation of the API? Or would this
> introduce a bunch of type system uncertainty?
>
> Maybe this could be implemented as a protocol? It feels almost like the
> convenience of `CustomStringConvertible`'s `description` property.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/c7c83773/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 14
> Date: Fri, 13 May 2016 20:11:12 +0200
> From: Nicola Salmoria <nicola.salmoria at gmail.com>
> To: "Vladimir.S" <svabox at gmail.com>
> Cc: swift-evolution <swift-evolution at swift.org>
> Subject: Re: [swift-evolution] [Draft] Introducing StaticSelf,  an
>         Invariant Self
> Message-ID:
>         <CAMZYVZgE+gLH4w=xOaLa6DDP3KW3S6rggU8V5W=
> Ts93izu6T8g at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Fri, May 13, 2016 at 12:55 PM, Vladimir.S <svabox at gmail.com> wrote:
>
> > > I'm not convinced by this example.
> >
> > Probably my & Matthew's previous discussion in `[swift-evolution] [RFC]
> > #Self` topic will help you. I was trying there to find out (in primitive
> > examples) what Matthew is trying to achive with this `->StaticSelf` in
> > protocol.
> >
> > In two words - he wants to achieve requirement 'return Self class or any
> > of base classes', as current `->Self` requires 'strictly return Self
> class'
> >
>
> I think I understand what the request is, but I'm not sure if it's a
> problem worth solving, and if this would be the right solution.
>
> Going back to the example, let's say you have the requested
>
> protocol Fooable {
>     func foo() -> StaticSelf
> }
>
> class A: Fooable {
>     func foo() -> A { return A() }
> }
>
> class B: A {
> }
>
> How would you use foo() in generic code?
>
> func bar<T: Fooable>(_ x: T) -> X {
>     return x.foo()
> }
>
> What does bar() return? What do you put in place of X in its declaration?
> You can't use T, you can't use T.StaticSelf. So what's the purpose of
> having a protocol if you can't use it in generic code?
>
>
> Nicola
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/f33b31ad/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 15
> Date: Fri, 13 May 2016 12:08:22 -0600
> From: Erica Sadun <erica at ericasadun.com>
> To: Brent Royal-Gordon <brent at architechies.com>,        Chris Lattner
>         <clattner at apple.com>
> Cc: swift-evolution at swift.org
> Subject: Re: [swift-evolution] [Review] SE-0045: Add scan,
>         prefix(while:), drop(while:), and iterate to the stdlib
> Message-ID: <1FC733A8-6BE7-45A0-9579-841AE52B5BA9 at ericasadun.com>
> Content-Type: text/plain; charset="utf-8"
>
> On May 1, 2016, at 5:13 AM, Brent Royal-Gordon via swift-evolution <
> swift-evolution at swift.org> wrote:
> >
> >> The proposal has been updated as per feedback from the core team (
> https://github.com/apple/swift-evolution/pull/275). This includes
> removing some last vestiges of Swift 2 naming as well as replacing
> `iterate(_:apply:)` with an overloaded function `unfold(_:applying:)`.
> >
> > The proposal says this:
> >
> >       public func unfold<T, State>(_ initialState: State, applying:
> State -> (T, State)?) -> UnfoldSequence<T>
> >       public func unfold<T>(_ initialElement: T, apply: T -> T) ->
> UnfoldSequence<T>
> >
> > However, the comment implies that the second one should instead be this:
> >
> >       public func unfold<T>(_ initialElement: T, applying: T -> T?) ->
> UnfoldSequence<T>
> >
> > I'm not sure I like having these be overloaded on only the return type
> of the closure. Maybe we could do something like this?
> >
> >       public func unfold<T, State>(fromState initialState: State,
> applying: State -> (T, State)?) -> UnfoldSequence<T>
> >       public func unfold<T>(fromFirst initialElement: T, apply: T -> T)
> -> UnfoldSequence<T>
> >
> > That way you're calling either `unfold(fromState:applying:)` or
> `unfold(fromFirst:applying:)`. (Some further bikeshedding might be needed
> here—it's late and I'm tired.)
>
> I really don't want to see this discussion die as I have a vested interest
> in getting this functionality into
> Swift 3. So let me suggest that
>
> `sequence(_:, next:) -> AdHocSequence`
>
> might be a Swift acceptable solution.  We're not going to see fold/unfold
> pair happen. It's a given that
> `reduce` is a fixed point in Swift space and `sequence` well describes
> what this should be doing.
>
> So is it possible to push forward with `sequence`, whose only negative
> seems to be that it's not as well
> loved as `unfold`?
>
> -- Erica
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/07e13f7a/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 16
> Date: Fri, 13 May 2016 21:16:03 +0300
> From: Pyry Jahkola <pyry.jahkola at iki.fi>
> To: Erica Sadun <erica at ericasadun.com>
> Cc: swift-evolution <swift-evolution at swift.org>
> Subject: Re: [swift-evolution] [Review] SE-0075: Adding a Build
>         Configuration Import Test
> Message-ID: <95C947FC-C523-41C3-A385-44AFC469124E at iki.fi>
> Content-Type: text/plain; charset="utf-8"
>
> > On 13 May 2016, Erica Sadun wrote:
> >
> >> As per Pyry’s feedback, you could add a version:
> >>
> >> #if import Frobnication(<1.7.3) // <- Only added version constraint
> here.
> >> extension Knob : Frobnicatable { ... }
> >> #endif
> >
> > I have no problem with this but would need to defer to the build and
> language people to determine whether that's practical in today's Swift.
> Right now, there's a major-version mention in build packages but I'm not
> sure whether that information then propagates in a usable way. If it's
> possible, then yes, I'd rather add it in the initial design than as a later
> addition and I can extend Pyry's suggestion in "Future Directions".
>
> I already gave my +1 on the original proposal and if `canImport` is indeed
> easiest to implement we should get it going now.
>
> The `#if import Foo` blocks and conditional imports with version checks
> can easily be added at a later time without much complication or breakage,
> AFAICT. Good if you can include those in the "Future Directions" section.
>
> > p.s. Also on my Swift Bucket list: "import as".
>
> Splendid! I'd already forgotten about qualified imports and renaming!
> Those would be welcome additions too.
>
> — Pyry
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/9e170f04/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 17
> Date: Fri, 13 May 2016 11:19:08 -0700
> From: Max Moiseev <moiseev at apple.com>
> To: swift-evolution at swift.org
> Subject: [swift-evolution] [draft-proposal] allow access to the
>         underlying      collection of a slice
> Message-ID: <D32AAB4D-D21D-428D-AE52-BF0566DD825D at apple.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi everyone!
>
> Here is the proposal to allow access to the underlying collections of
> slices. Existing API of slice types is very minimal and as such prevents
> possible optimizations. Exposing the base collection via a public readonly
> property will make such optimizations possible.
>
> Max
>
> Adding a public base property to slices
>
> Proposal: SE-NNNN
> Author(s): Max Moiseev <https://github.com/moiseev>
> Status: Awaiting review
> Review manager: TBD
> Introduction
>
> Slice types provided by the standard library <
> https://github.com/apple/swift/blob/master/stdlib/public/core/Slice.swift.gyb>
> should allow public readonly access to their base collections to make
> efficient implementations of protocol requirements possible in conforming
> types.
>
> Motivation
>
> The MutableCollection protocol conformance requires providing an
> implementation of the following subscript:
>
> subscript(bounds: Range<Index>) -> SubSequence { get set }
> If the collection chooses to use one of a variety of slice types from the
> standard library as its SubSequence, the default implementation of a setter
> for this subscript will use the algorithm provided by the
> _writeBackMutableSlice <
> https://github.com/apple/swift/blob/master/stdlib/public/core/WriteBackMutableSlice.swift>
> function. This approach is fine for forward collections. It is quite
> possible, however, that the most efficient implementation of this setter
> would be to simply call the memcpy function. Unfortunately, slice API does
> not provide any way to reach to the underlying base collection, even though
> reference to it is stored in an internal property.
>
> Proposed solution
>
> We propose to export a public readonly property base, that will enable
> optimizations mentioned above. Here is how MutableRandomAccessSlice
> definition would look like:
>
> public struct MutableRandomAccessSlice<
>   Base : protocol<RandomAccessIndexable, MutableIndexable>
> > : RandomAccessCollection, MutableCollection {
>
>   /// The underlying collection of the slice
>   public var base: Base { get }
> }
> The same change is applicable to both mutable and immutable slice types.
>
> Impact on existing code
>
> The proposed change is purely additive and does not affect existing code.
>
> Alternatives considered
>
> Alternative for immutable slices would be to simply rename the already
> read-only _base property to base and make it public, but this way the
> change is not purely additive and might cause some damage inside the
> standard library code.
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/13768551/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 18
> Date: Fri, 13 May 2016 11:19:23 -0700
> From: Joe Groff <jgroff at apple.com>
> To: Erica Sadun <erica at ericasadun.com>
> Cc: Chris Lattner via swift-evolution <swift-evolution at swift.org>
> Subject: Re: [swift-evolution] [Review] SE-0084: Allow trailing commas
>         in parameter lists and tuples
> Message-ID: <B61AB4F9-B20C-4B6E-A205-9D465ABB2C2A at apple.com>
> Content-Type: text/plain; charset=utf-8
>
>
> > On May 13, 2016, at 10:46 AM, Erica Sadun <erica at ericasadun.com> wrote:
> >
> >
> >> On May 13, 2016, at 11:29 AM, Joe Groff <jgroff at apple.com> wrote:
> >>
> >>>
> >>> On May 13, 2016, at 7:04 AM, Erica Sadun <erica at ericasadun.com> wrote:
> >>>
> >>> On May 12, 2016, at 11:01 PM, Chris Lattner via swift-evolution <
> swift-evolution at swift.org> wrote:
> >>>> On May 12, 2016, at 4:50 PM, Joe Groff <jgroff at apple.com> wrote:
> >>>>>> You’re arguing that you want to read Swift code written like this?
> >>>>>
> >>>>> I wouldn't mind it.
> >>>>
> >>>> I personally find that style repulsive :-) and I haven’t seen swift
> code commonly doing it.  I’m not sure that we want to encourage it either.
> >>>>
> >>>
> >>> No. Tell us what you *really* think of the style. Don't hold back.[1]
> >>>
> >>>> If we were really concerned about this, a narrower way to solve the
> same problem would be to allow a comma before the ), but *only* when there
> is a newline between them.  I still don’t see why we’d want to encourage
> this though.
> >>>
> >>> I wouldn't object to this restriction. I cannot think of a situation
> where using ",)" -- that is the comma adjacent to a closing parenthesis --
> makes sense for any reason previously enumerated in support of this
> proposal.
> >>
> >> I don't see why we need to micromanage the situations where trailing
> commas are allowed. That's just unnecessarily increasing the fractal
> complexity of the language. We've delegated other style choices like
> requiring `self.` or brace formatting to linters; why does this one need to
> be legislated by the compiler?
> >>
> >> -Joe
> >
> > Mostly because I'm trying to play nice and get Chris to reconsider. I'd
> like to get the feature, I'm willing to compromise on the technicalities.
>
> Sorry, I replied to you, but my comments were more directed toward Chris.
>
> -Joe
>
> ------------------------------
>
> Message: 19
> Date: Fri, 13 May 2016 12:15:38 -0600
> From: Erica Sadun <erica at ericasadun.com>
> To: Chris Lattner via swift-evolution <swift-evolution at swift.org>,
>         alex at kempgen.de
> Subject: [swift-evolution] Interspersing guard let with guard boolean
> Message-ID: <A0645FEA-B666-4E3D-8DDC-8406CE86E813 at ericasadun.com>
> Content-Type: text/plain; charset=us-ascii
>
> Is there a technical reason that Swift cannot be expanded to allow
> arbitrary mixes of conditional binding and boolean assertions within a
> single compound guard statement?
>
> Thanks, -- E
>
>
>
> ------------------------------
>
> Message: 20
> Date: Fri, 13 May 2016 11:23:44 -0700
> From: Joe Groff <jgroff at apple.com>
> To: Erica Sadun <erica at ericasadun.com>
> Cc: Chris Lattner via swift-evolution <swift-evolution at swift.org>,
>         alex at kempgen.de
> Subject: Re: [swift-evolution] Interspersing guard let with guard
>         boolean
> Message-ID: <2F004069-682D-4C14-B9C4-158ACA735D0F at apple.com>
> Content-Type: text/plain; charset=us-ascii
>
>
> > On May 13, 2016, at 11:15 AM, Erica Sadun via swift-evolution <
> swift-evolution at swift.org> wrote:
> >
> > Is there a technical reason that Swift cannot be expanded to allow
> arbitrary mixes of conditional binding and boolean assertions within a
> single compound guard statement?
>
> No. You already can, we just have the somewhat strange rule that to
> separate `guard` conditions uses `,` before optional or pattern conditions,
> but `where` before boolean conditions:
>
>         guard x == 0,
>           let y = optional where
>           z == 2 {
>         }
>
> There's no technical reason we couldn't accept either 'where' or ','
> consistently.
>
> -Joe
>
> ------------------------------
>
> Message: 21
> Date: Fri, 13 May 2016 12:27:16 -0600
> From: Erica Sadun <erica at ericasadun.com>
> To: Joe Groff <jgroff at apple.com>, mike at mikeash.com
> Cc: Chris Lattner via swift-evolution <swift-evolution at swift.org>,
>         alex at kempgen.de
> Subject: Re: [swift-evolution] Interspersing guard let with guard
>         boolean
> Message-ID: <9E13E3A9-3FAC-4D14-B3E6-B0D4054069B0 at ericasadun.com>
> Content-Type: text/plain; charset=us-ascii
>
>
> > On May 13, 2016, at 12:23 PM, Joe Groff <jgroff at apple.com> wrote:
> >
> >
> >> On May 13, 2016, at 11:15 AM, Erica Sadun via swift-evolution <
> swift-evolution at swift.org> wrote:
> >>
> >> Is there a technical reason that Swift cannot be expanded to allow
> arbitrary mixes of conditional binding and boolean assertions within a
> single compound guard statement?
> >
> > No. You already can, we just have the somewhat strange rule that to
> separate `guard` conditions uses `,` before optional or pattern conditions,
> but `where` before boolean conditions:
> >
> >       guard x == 0,
> >         let y = optional where
> >         z == 2 {
> >       }
> >
> > There's no technical reason we couldn't accept either 'where' or ','
> consistently.
> >
> > -Joe
>
> Is it worth a proposal to allow both, for when the where clauses don't
> have to be semantically tied to the conditional binding?
>
> -- E
>
> /ccing  in Mike Ash so he can gloat
>
>
>
> ------------------------------
>
> Message: 22
> Date: Fri, 13 May 2016 21:34:58 +0300
> From: "Vladimir.S" <svabox at gmail.com>
> To: Adrian Zubarev <adrian.zubarev at devandartist.com>
> Cc: swift-evolution <swift-evolution at swift.org>
> Subject: Re: [swift-evolution] [Pitch] merge types and protocols back
>         together with type<Type, Protocol, ...>
> Message-ID: <66427699-ae82-5140-ac5f-7f97ce14cc4a at gmail.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Hmm..
>
> What about such synthetic scenario:
>
> at the moment of writing our code we have:
>
> public protocol MyProtocol {
>    func foo()
> }
>
> public struct StructA:MyProtocol {
>    func foo()
> }
>
> public struct StructB:MyProtocol {
>    func foo()
> }
>
> and have
>
> public protocol ExtraProtocol1 {
>    func bar()
> }
>
> public protocol ExtraProtocol2 {
>    func blort()
> }
>
> then we actually can have such code:
>
> func f(p: MyProtocol) {
>    if let a = p as? struct<StructA, ExtraProtocol1> {
>       a.foo()
>       a.bar()
>    }
>    else
>    if let b = p as? struct<StructB, ExtraProtocol2> {
>       b.foo()
>       b.blort()
>    }
> }
>
> as we can(as example) expect that in 3rd party code someone will do:
>
> extension StructA: ExtraProtocol1 {
>    func bar() {}
> }
>
> extension StructB: ExtraProtocol2 {
>    func blort() {}
> }
>
>
>
> On 13.05.2016 20:50, Adrian Zubarev via swift-evolution wrote:
> >>         'struct<>' does seem redundant unless it becomes subtypeable. If
> >>         you want a struct which conforms to several protocols,
> protocol<>
> >>         already covers this.
> >>
> >>     I think this is not correct. Lets check this example:
> >>
> >>     func foo(value: SomeProtocol) {
> >>
> >>         if let a = value as? struct<StructA, SomeProtocol> { /* do
> >>     something with a */ }
> >>
> >>         else if let b = value as? struct<StructB, SomeProtocol> { /* do
> >>     something with b */ }
> >>
> >>     }
> >>
> >>     In this scenario you’ll be able to access properties and functions
> >>     from `StructA` or `StructB` which might not be covered by
> >>     `SomeProtocol`. Everything is merged nicely into one instance. But
> >>     you are right it depends on the use-case.
> >>
> >>
> >> There is no need to include the protocol here.   Just do this:
> >>
> >> if let a = value as? StructA { use a }
> >>
> > Whoops, I forgot that this will do the trick. I apologize for any
> confusion
> > here, you are totally right.
> >
> > That been said, do we really need `type<>` aka. `all<>` for value types?
> I
> > need to rethink this part of the proposal. Is there any use-case where we
> > would need this (any scenario for the future Swift version also counts)?
> >
> > If we had `all<>` in Swift already for extendable reference types and one
> > day structs would become subtypeable, this wouldn’t be a huge problem to
> > upgrade `all<>` for structs I guess.
> >
> > --
> > Adrian Zubarev
> > Sent with Airmail
> >
> >
> >
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> >
>
>
> ------------------------------
>
> Message: 23
> Date: Fri, 13 May 2016 11:36:55 -0700
> From: Matt Wright <mww at apple.com>
> To: swift-evolution <swift-evolution at swift.org>
> Subject: Re: [swift-evolution] [Review] SE-0088: Modernize libdispatch
>         for     Swift 3 naming conventions
> Message-ID: <178CA219-60D2-4A43-96F3-86BA02DB7CBA at apple.com>
> Content-Type: text/plain; charset=utf-8
>
> [Apologies for the weird threading, I missed the original email to the
> list so I can’t reply to it directly]
>
> I just wanted to let the list know that I updated proposal SE-0088 to fix
> the typos and include a more complete listing of the Dispatch module after
> the transformations in the proposal have been applied. Additionally, I’ve
> been keeping up with some of the feedback in this review thread and looking
> to see which ones would be best applied to the proposal. Though it should
> be made clear, this particular update only covers fixing the
> inconsistencies in my original proposal and providing a more complete
> overview of the module layout.
>
> Similar to the changes in Foundation that are proposed on swift-evolution,
> I don’t expect all of the changes in libdispatch will be able to go through
> this process. As this is a large change (and, hopefully, a step forwards)
> to libdispatch I believe it is important to bring it to the swift-evolution
> list and take away your feedback for inclusion in future iterations of the
> module.
>
> Thanks again for your continued feedback,
> Matt
>
> > On Tue, May 10, 2016 at 9:39 PM, Chris Lattner via swift-evolution <
> swift-evolution at swift.org> wrote:
> > Hello Swift community,
> >
> > The review of "SE-0088: Modernize libdispatch for Swift 3 naming
> conventions" begins now and runs through May 17. The proposal is available
> here:
> >
> >
> https://github.com/apple/swift-evolution/blob/master/proposals/0088-libdispatch-for-swift3.md
> >
> > Reviews are an important part of the Swift evolution process. All
> reviews should be sent to the swift-evolution mailing list at
> >
> >         https://lists.swift.org/mailman/listinfo/swift-evolution
> >
> > or, if you would like to keep your feedback private, directly to the
> review manager.
> >
> > What goes into a review?
> >
> > The goal of the review process is to improve the proposal under review
> through constructive criticism and contribute to the direction of Swift.
> When writing your review, here are some questions you might want to answer
> in your review:
> >
> >         * What is your evaluation of the proposal?
> >         * Is the problem being addressed significant enough to warrant a
> change to Swift?
> >         * Does this proposal fit well with the feel and direction of
> Swift?
> >         * If you have used other languages or libraries with a similar
> feature, how do you feel that this proposal compares to those?
> >         * How much effort did you put into your review? A glance, a
> quick reading, or an in-depth study?
> >
> > More information about the Swift evolution process is available at
> >
> >         https://github.com/apple/swift-evolution/blob/master/process.md
> >
> > Thank you,
> >
> > -Chris Lattner
> > Review Manager
> >
> >
> >
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> >
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> ------------------------------
>
> Message: 24
> Date: Fri, 13 May 2016 14:06:23 -0500
> From: Matthew Johnson <matthew at anandabits.com>
> To: Nicola Salmoria <nicola.salmoria at gmail.com>
> Cc: swift-evolution <swift-evolution at swift.org>
> Subject: Re: [swift-evolution] [Draft] Introducing StaticSelf,  an
>         Invariant Self
> Message-ID: <6A1CC61D-1AB6-48C9-88E8-210DB4B85C89 at anandabits.com>
> Content-Type: text/plain; charset="utf-8"
>
>
> > On May 13, 2016, at 1:11 PM, Nicola Salmoria via swift-evolution <
> swift-evolution at swift.org> wrote:
> >
> >
> >
> > On Fri, May 13, 2016 at 12:55 PM, Vladimir.S <svabox at gmail.com <mailto:
> svabox at gmail.com>> wrote:
> > > I'm not convinced by this example.
> >
> > Probably my & Matthew's previous discussion in `[swift-evolution] [RFC]
> #Self` topic will help you. I was trying there to find out (in primitive
> examples) what Matthew is trying to achive with this `->StaticSelf` in
> protocol.
> >
> > In two words - he wants to achieve requirement 'return Self class or any
> of base classes', as current `->Self` requires 'strictly return Self class'
> >
> > I think I understand what the request is, but I'm not sure if it's a
> problem worth solving, and if this would be the right solution.
> >
> > Going back to the example, let's say you have the requested
> >
> > protocol Fooable {
> >     func foo() -> StaticSelf
> > }
> >
> > class A: Fooable {
> >     func foo() -> A { return A() }
> > }
> >
> > class B: A {
> > }
> >
> > How would you use foo() in generic code?
> >
> > func bar<T: Fooable>(_ x: T) -> X {
> >     return x.foo()
> > }
> >
> > What does bar() return? What do you put in place of X in its declaration?
> > You can't use T, you can't use T.StaticSelf. So what's the purpose of
> having a protocol if you can't use it in generic code?
>
> This is a good question.  Thank you very much for providing a concrete
> example along with the question.
>
> Let’s look at an example of what some of us have in mind:
>
> protocol StringCreatable {
>     static func createWithString(s: String) -> StaticSelf
> }
>
> extension NSURL: StringCreatable {
>     static func createWithString(s: String) -> StaticSelf {
>         // ...
>     }
> }
>
> func foo<Result: StringCreatable>(s: String) -> Result {
>     return Result.createWithString(s: s)
> }
>
> Obviously this will not work properly because we are not guaranteed that
> `createWithString` returns Result (that is only possible if the return type
> is Self).  We would have to do the following:
>
> protocol StringCreatable {
>     typealias ConformingType = StaticSelf
>     static func createWithString(s: String) -> StaticSelf
> }
>
> func foo<Result: StringCreatable where Result.ConformingType == Result>(s:
> String) -> Result {
>     return Result.createWithString(s: s)
> }
>
> This requires same type constraints.  I believe that is coming as part of
> “completing generics”.
>
> However, it also raises a question: if the conformance afforded to
> subclasses can’t actually be used in a useful manner they probably
> shouldn’t have that conformance in the first place.  If the conformance
> isn’t inherited then we don’t need StaticSelf at all (we can just use Self
> and still conform the visible class of a class cluster).  This is the point
> Joe has been making all along.  Working through the example has helped me
> understand this point of view better.
>
> I wonder if anyone has any other examples where subclass conformance would
> actually be useful.  If so, please share.  Those who are supporting this
> proposal: how do you envision using StaticSelf in your code?  What are some
> examples where you have had trouble due to the current limitations of the
> language?
>
> -Matthew
>
>
> >
> >
> > Nicola
> >
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/faddc0a1/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 25
> Date: Fri, 13 May 2016 12:07:29 -0700
> From: Kevin Ballard <kevin at sb.org>
> To: Erica Sadun <erica at ericasadun.com>, "Brent Royal-Gordon"
>         <brent at architechies.com>,       Chris Lattner <clattner at apple.com>
> Cc: swift-evolution at swift.org
> Subject: Re: [swift-evolution] [Review] SE-0045: Add scan,
>         prefix(while:), drop(while:), and iterate to the stdlib
> Message-ID:
>         <1463166449.928503.607214225.00CC8144 at webmail.messagingengine.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Fri, May 13, 2016, at 11:08 AM, Erica Sadun wrote:
> > On May 1, 2016, at 5:13 AM, Brent Royal-Gordon via swift-evolution
> <swift-
> > evolution at swift.org> wrote:
> >>
> >>> The proposal has been updated as per feedback from the core team
> >>> (https://github.com/apple/swift-evolution/pull/275). This includes
> >>> removing some last vestiges of Swift 2 naming as well as replacing
> >>> `iterate(_:apply:)` with an overloaded function
> >>> `unfold(_:applying:)`.
> >>
> >> The proposal says this:
> >>
> >>  public func unfold<T, State>(_ initialState: State, applying: State
> >>  -> (T, State)?) -> UnfoldSequence<T>
> >>  public func unfold<T>(_ initialElement: T, apply: T -> T) ->
> >>  UnfoldSequence<T>
> >>
> >> However, the comment implies that the second one should instead
> >> be this:
> >>
> >>  public func unfold<T>(_ initialElement: T, applying: T -> T?) ->
> >>  UnfoldSequence<T>
> >>
> >> I'm not sure I like having these be overloaded on only the return
> >> type of the closure. Maybe we could do something like this?
> >>
> >>  public func unfold<T, State>(fromState initialState: State,
> >>  applying: State -> (T, State)?) -> UnfoldSequence<T>
> >>  public func unfold<T>(fromFirst initialElement: T, apply: T -> T) ->
> >>  UnfoldSequence<T>
> >>
> >> That way you're calling either `unfold(fromState:applying:)` or
> >> `unfold(fromFirst:applying:)`. (Some further bikeshedding might be
> >> needed here—it's late and I'm tired.)
> >
> > I really don't want to see this discussion die as I have a vested
> > interest in getting this functionality into
> > Swift 3. So let me suggest that
> >
> > `sequence(_:, next:) -> AdHocSequence`
> >
> > might be a Swift acceptable solution.  We're not going to see
> > fold/unfold pair happen. It's a given that
> > `reduce` is a fixed point in Swift space and `sequence` well describes
> > what this should be doing.
> >
> > So is it possible to push forward with `sequence`, whose only negative
> > seems to be that it's not as well
> > loved as `unfold`?
>
> I do like `sequence`, though I'm not sold on the name AdHocSequence
> (just from that name it's hard to figure out what it does). An
> alternative is `expand`, which is nice because it pairs with `reduce`,
> but it's less obvious that it produces a sequence and the name isn't as
> good with the stateful version.
>
> As for return type name, we could go ahead and use UnfoldSequence<T>
> anyway even though the function isn't named `unfold`, because this name
> will make sense to people who do know what unfold is, and I'm not
> convinced we can have a meaningful name for people who don't (since
> SequenceSequence is too silly).
>
> So given that, I'll suggest the following:
>
> func sequence<T>(initial: T, next: T -> T?) -> UnfoldSequence<T>
> func sequence<T, State>(state: State, next: (inout State) -> T?) ->
> UnfoldSequence<T>
>
> I'm suggesting `sequence(initial:next:)` instead of the previously-
> suggested `sequence(from:applying:)` because the term "from" could
> equally well mean the first element or the state, whereas "initial"
> should make it more obvious that this value is the first element of the
> resulting sequence. And I'm using "next" as suggested by Erica because
> the function does return the next element, and it's similar to the
> IteratorProtocol method. I've also chosen to change the stateful version
> to use an inout parameter, as previously suggested, because it's
> equivalent to the State -> (T, State)? in functionality but is less
> likely to produce unwanted COW copies.
>
> -Kevin Ballard
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/6087ca3b/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 26
> Date: Fri, 13 May 2016 21:14:44 +0200
> From: Adrian Zubarev <adrian.zubarev at devandartist.com>
> To: swift-evolution at swift.org
> Subject: Re: [swift-evolution] [Pitch] merge types and protocols back
>         together with type<Type, Protocol, ...>
> Message-ID: <etPan.573627a4.578126f6.6ab2 at DevAndArtist.fritz.box>
> Content-Type: text/plain; charset="utf-8"
>
> As we can(as example) expect that in 3rd party code someone will do:
>
> extension StructA: ExtraProtocol1 {
> func bar() {}
> }
>
> extension StructB: ExtraProtocol2 {
> func blort() {}
> }
>
> Can we really do that? I mean, I thought about that myself but I came to
> the conclusion that this scenario is like: I was to lazy to couple this
> structs to my library protocols, will you do that for me?
>
> Sure one could think that this protocols might be optional but the `f(p:
> MyProtocol)` function will cover this scenario.
>
> Another interesting side-effect `struct<>`, `class<>` and `enum<>` will
> allow us to do is to distinguish between value and reference types for
> generics. I tried this differentiation types with protocols like
> `AnyReference` and `AnyValue` in another topic before (Should we rename
> "class" when referring to protocol conformance?), but I kinda like this new
> approach.
>
> Here is what I mean in detail:
>
> protocol SomeProtocol /* we can’t constraint it to value types at the
> moment, only `class`es works */ {}
>
> func foo<T>(value: struct<T, SomeProtocol>) { /* do some work */ }
>
> This function is pretty neat. (1) You can force the library user to create
> a struct with conformance to `SomeProtocol`. (2) This approach will accept
> any struct which conforms to that protocol.
>
> As I said in the protocol comment above protocols can only be constrained
> to classes at the moment, and this might change in the future. If we also
> had some sort of things for generics so the function from above might have
> looked like this:
>
> func foo<T: struct where T: SomeProtocol>(value: T) {}
>
> But it seems that such a thing won’t ever happen to Swift.
>
> Basically `struct<>`, `class<>` and `enum<>` will just enable this for us.
> `all<>` would accept any type at its first element.
>
> func foo<T /* add more constraints here */ >(value: all<T, SomeProtocol>)
> { /* T could be a reference type or value type */ }
>
> That been said, `all<>` could replace `protocol<>` where it is composed
> from protocols. `all<>` can only be used as a generic constraints if the
> first element is a protocol or a reference type.
>
> @Matthew: isn’t this somehow a step towards (generic) `PureValue` types?
>
> struct A<T> {
>
>     var value: struct<T> // if we drop the strict rule of at least one
> protocols
> }
>
> How does it sound to you?
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 13. Mai 2016 bei 20:34:59, Vladimir.S (svabox at gmail.com) schrieb:
>
> Hmm..
>
> What about such synthetic scenario:
>
> at the moment of writing our code we have:
>
> public protocol MyProtocol {
> func foo()
> }
>
> public struct StructA:MyProtocol {
> func foo()
> }
>
> public struct StructB:MyProtocol {
> func foo()
> }
>
> and have
>
> public protocol ExtraProtocol1 {
> func bar()
> }
>
> public protocol ExtraProtocol2 {
> func blort()
> }
>
> then we actually can have such code:
>
> func f(p: MyProtocol) {
> if let a = p as? struct<StructA, ExtraProtocol1> {
> a.foo()
> a.bar()
> }
> else
> if let b = p as? struct<StructB, ExtraProtocol2> {
> b.foo()
> b.blort()
> }
> }
>
>
>
>
> On 13.05.2016 20:50, Adrian Zubarev via swift-evolution wrote:
> >> 'struct<>' does seem redundant unless it becomes subtypeable. If
> >> you want a struct which conforms to several protocols, protocol<>
> >> already covers this.
> >>
> >> I think this is not correct. Lets check this example:
> >>
> >> func foo(value: SomeProtocol) {
> >>
> >> if let a = value as? struct<StructA, SomeProtocol> { /* do
> >> something with a */ }
> >>
> >> else if let b = value as? struct<StructB, SomeProtocol> { /* do
> >> something with b */ }
> >>
> >> }
> >>
> >> In this scenario you’ll be able to access properties and functions
> >> from `StructA` or `StructB` which might not be covered by
> >> `SomeProtocol`. Everything is merged nicely into one instance. But
> >> you are right it depends on the use-case.
> >>
> >>
> >> There is no need to include the protocol here. Just do this:
> >>
> >> if let a = value as? StructA { use a }
> >>
> > Whoops, I forgot that this will do the trick. I apologize for any
> confusion
> > here, you are totally right.
> >
> > That been said, do we really need `type<>` aka. `all<>` for value types?
> I
> > need to rethink this part of the proposal. Is there any use-case where we
> > would need this (any scenario for the future Swift version also counts)?
> >
> > If we had `all<>` in Swift already for extendable reference types and one
> > day structs would become subtypeable, this wouldn’t be a huge problem to
> > upgrade `all<>` for structs I guess.
> >
> > --
> > Adrian Zubarev
> > Sent with Airmail
> >
> >
> >
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/167979a4/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 27
> Date: Fri, 13 May 2016 19:24:31 +0000
> From: Jacob Bandes-Storch <jtbandes at gmail.com>
> To: Matt Wright <mww at apple.com>
> Cc: swift-evolution <swift-evolution at swift.org>
> Subject: Re: [swift-evolution] [Review] SE-0088: Modernize libdispatch
>         for Swift 3 naming conventions
> Message-ID:
>         <
> CADcs6kNjyOgbBWs-4Ho8Mc2882DRKHJbAhOrvk1sggb-_7audA at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> This looks great. Thanks for revising. I'm now a +1 on this.
>
> A couple more minor suggestions:
>
> - Consider renaming setTimer(...) to resetTimer() or just reset(), or
> something similar?
>
> - Consider making Semaphore's wait() throw an error, rather than returning
> non-zero, in the event of a timeout. Most common uses will be "try!
> wait()". Or you could have waitForever() be a separate, non-throwing
> function.
>
> Jacob Bandes-Storch
>
> On Fri, May 13, 2016 at 11:36 AM, Matt Wright via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> > [Apologies for the weird threading, I missed the original email to the
> > list so I can’t reply to it directly]
> >
> > I just wanted to let the list know that I updated proposal SE-0088 to fix
> > the typos and include a more complete listing of the Dispatch module
> after
> > the transformations in the proposal have been applied. Additionally, I’ve
> > been keeping up with some of the feedback in this review thread and
> looking
> > to see which ones would be best applied to the proposal. Though it should
> > be made clear, this particular update only covers fixing the
> > inconsistencies in my original proposal and providing a more complete
> > overview of the module layout.
> >
> > Similar to the changes in Foundation that are proposed on
> swift-evolution,
> > I don’t expect all of the changes in libdispatch will be able to go
> through
> > this process. As this is a large change (and, hopefully, a step forwards)
> > to libdispatch I believe it is important to bring it to the
> swift-evolution
> > list and take away your feedback for inclusion in future iterations of
> the
> > module.
> >
> > Thanks again for your continued feedback,
> > Matt
> >
> > > On Tue, May 10, 2016 at 9:39 PM, Chris Lattner via swift-evolution <
> > swift-evolution at swift.org> wrote:
> > > Hello Swift community,
> > >
> > > The review of "SE-0088: Modernize libdispatch for Swift 3 naming
> > conventions" begins now and runs through May 17. The proposal is
> available
> > here:
> > >
> > >
> >
> https://github.com/apple/swift-evolution/blob/master/proposals/0088-libdispatch-for-swift3.md
> > >
> > > Reviews are an important part of the Swift evolution process. All
> > reviews should be sent to the swift-evolution mailing list at
> > >
> > >         https://lists.swift.org/mailman/listinfo/swift-evolution
> > >
> > > or, if you would like to keep your feedback private, directly to the
> > review manager.
> > >
> > > What goes into a review?
> > >
> > > The goal of the review process is to improve the proposal under review
> > through constructive criticism and contribute to the direction of Swift.
> > When writing your review, here are some questions you might want to
> answer
> > in your review:
> > >
> > >         * What is your evaluation of the proposal?
> > >         * Is the problem being addressed significant enough to warrant
> a
> > change to Swift?
> > >         * Does this proposal fit well with the feel and direction of
> > Swift?
> > >         * If you have used other languages or libraries with a similar
> > feature, how do you feel that this proposal compares to those?
> > >         * How much effort did you put into your review? A glance, a
> > quick reading, or an in-depth study?
> > >
> > > More information about the Swift evolution process is available at
> > >
> > >
> https://github.com/apple/swift-evolution/blob/master/process.md
> > >
> > > Thank you,
> > >
> > > -Chris Lattner
> > > Review Manager
> > >
> > >
> > >
> > > _______________________________________________
> > > swift-evolution mailing list
> > > swift-evolution at swift.org
> > > https://lists.swift.org/mailman/listinfo/swift-evolution
> > >
> > > _______________________________________________
> > > swift-evolution mailing list
> > > swift-evolution at swift.org
> > > https://lists.swift.org/mailman/listinfo/swift-evolution
> >
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/25063811/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 28
> Date: Fri, 13 May 2016 19:29:06 +0000
> From: Xiaodi Wu <xiaodi.wu at gmail.com>
> To: Matt Wright <mww at apple.com>, swift-evolution
>         <swift-evolution at swift.org>
> Subject: Re: [swift-evolution] [Review] SE-0088: Modernize libdispatch
>         for Swift 3 naming conventions
> Message-ID:
>         <
> CAGY80umC-paivBJ3Ci3MPp_j+Ex_QrYe7LFNmN+2TYMB4J53wQ at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> More nits:
>
> setHighWater(highWater:) and its ilk should should probably be
> setHighWater(_:) and so on (I include among these setInterval(interval:),
> setTargetQueue(queue:), etc.)
>
> Similarly, in terms of conforming to Swift guidelines, I notice many
> instances where labels repeat the parameter type, especially
> DispatchWalltime. For instance, setTimer(walltime: DispatchWalltime,
> leeway: DispatchTimeInterval)--not sure what to suggest here other than
> point out that the first label is redundant.
> On Fri, May 13, 2016 at 11:36 Matt Wright via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> > [Apologies for the weird threading, I missed the original email to the
> > list so I can’t reply to it directly]
> >
> > I just wanted to let the list know that I updated proposal SE-0088 to fix
> > the typos and include a more complete listing of the Dispatch module
> after
> > the transformations in the proposal have been applied. Additionally, I’ve
> > been keeping up with some of the feedback in this review thread and
> looking
> > to see which ones would be best applied to the proposal. Though it should
> > be made clear, this particular update only covers fixing the
> > inconsistencies in my original proposal and providing a more complete
> > overview of the module layout.
> >
> > Similar to the changes in Foundation that are proposed on
> swift-evolution,
> > I don’t expect all of the changes in libdispatch will be able to go
> through
> > this process. As this is a large change (and, hopefully, a step forwards)
> > to libdispatch I believe it is important to bring it to the
> swift-evolution
> > list and take away your feedback for inclusion in future iterations of
> the
> > module.
> >
> > Thanks again for your continued feedback,
> > Matt
> >
> > > On Tue, May 10, 2016 at 9:39 PM, Chris Lattner via swift-evolution <
> > swift-evolution at swift.org> wrote:
> > > Hello Swift community,
> > >
> > > The review of "SE-0088: Modernize libdispatch for Swift 3 naming
> > conventions" begins now and runs through May 17. The proposal is
> available
> > here:
> > >
> > >
> >
> https://github.com/apple/swift-evolution/blob/master/proposals/0088-libdispatch-for-swift3.md
> > >
> > > Reviews are an important part of the Swift evolution process. All
> > reviews should be sent to the swift-evolution mailing list at
> > >
> > >         https://lists.swift.org/mailman/listinfo/swift-evolution
> > >
> > > or, if you would like to keep your feedback private, directly to the
> > review manager.
> > >
> > > What goes into a review?
> > >
> > > The goal of the review process is to improve the proposal under review
> > through constructive criticism and contribute to the direction of Swift.
> > When writing your review, here are some questions you might want to
> answer
> > in your review:
> > >
> > >         * What is your evaluation of the proposal?
> > >         * Is the problem being addressed significant enough to warrant
> a
> > change to Swift?
> > >         * Does this proposal fit well with the feel and direction of
> > Swift?
> > >         * If you have used other languages or libraries with a similar
> > feature, how do you feel that this proposal compares to those?
> > >         * How much effort did you put into your review? A glance, a
> > quick reading, or an in-depth study?
> > >
> > > More information about the Swift evolution process is available at
> > >
> > >
> https://github.com/apple/swift-evolution/blob/master/process.md
> > >
> > > Thank you,
> > >
> > > -Chris Lattner
> > > Review Manager
> > >
> > >
> > >
> > > _______________________________________________
> > > swift-evolution mailing list
> > > swift-evolution at swift.org
> > > https://lists.swift.org/mailman/listinfo/swift-evolution
> > >
> > > _______________________________________________
> > > swift-evolution mailing list
> > > swift-evolution at swift.org
> > > https://lists.swift.org/mailman/listinfo/swift-evolution
> >
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/4644df43/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 29
> Date: Fri, 13 May 2016 12:44:59 -0700
> From: Matt Wright <mww at apple.com>
> To: Xiaodi Wu <xiaodi.wu at gmail.com>
> Cc: swift-evolution <swift-evolution at swift.org>
> Subject: Re: [swift-evolution] [Review] SE-0088: Modernize libdispatch
>         for     Swift 3 naming conventions
> Message-ID: <96D2038A-FB04-47FF-B7CF-85923D50AD2A at apple.com>
> Content-Type: text/plain; charset=utf-8
>
>
> > On May 13, 2016, at 12:29 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
> >
> > More nits:
> >
> > setHighWater(highWater:) and its ilk should should probably be
> setHighWater(_:) and so on (I include among these setInterval(interval:),
> setTargetQueue(queue:), etc.)
>
> I suspect setHighWater and setLowWater can probably become
> setLimit(highWater:) setLimit(lowWater:). setTargetQueue ->
> setTarget(queue:) seems like an obvious change but something about it
> doesn’t sit particularly right with me. I will think about this further.
> There were both very useful bits feedback on these names though, thank you!
>
> > Similarly, in terms of conforming to Swift guidelines, I notice many
> instances where labels repeat the parameter type, especially
> DispatchWalltime. For instance, setTimer(walltime: DispatchWalltime,
> leeway: DispatchTimeInterval)--not sure what to suggest here other than
> point out that the first label is redundant.
>
> setTimer() in particular has a setTimer(start:,…) and
> setTimer(walltime:,…) that are distinct, perhaps the latter could be
> `walltimeStart:`. While there was an earlier argument for removing Walltime
> as a typed concept, we believe it is advantageous to keep different “types”
> of time as separate distinct Swift types in the module.
>
> > On Fri, May 13, 2016 at 11:36 Matt Wright via swift-evolution <
> swift-evolution at swift.org> wrote:
> > [Apologies for the weird threading, I missed the original email to the
> list so I can’t reply to it directly]
> >
> > I just wanted to let the list know that I updated proposal SE-0088 to
> fix the typos and include a more complete listing of the Dispatch module
> after the transformations in the proposal have been applied. Additionally,
> I’ve been keeping up with some of the feedback in this review thread and
> looking to see which ones would be best applied to the proposal. Though it
> should be made clear, this particular update only covers fixing the
> inconsistencies in my original proposal and providing a more complete
> overview of the module layout.
> >
> > Similar to the changes in Foundation that are proposed on
> swift-evolution, I don’t expect all of the changes in libdispatch will be
> able to go through this process. As this is a large change (and, hopefully,
> a step forwards) to libdispatch I believe it is important to bring it to
> the swift-evolution list and take away your feedback for inclusion in
> future iterations of the module.
> >
> > Thanks again for your continued feedback,
> > Matt
> >
> > > On Tue, May 10, 2016 at 9:39 PM, Chris Lattner via swift-evolution <
> swift-evolution at swift.org> wrote:
> > > Hello Swift community,
> > >
> > > The review of "SE-0088: Modernize libdispatch for Swift 3 naming
> conventions" begins now and runs through May 17. The proposal is available
> here:
> > >
> > >
> https://github.com/apple/swift-evolution/blob/master/proposals/0088-libdispatch-for-swift3.md
> > >
> > > Reviews are an important part of the Swift evolution process. All
> reviews should be sent to the swift-evolution mailing list at
> > >
> > >         https://lists.swift.org/mailman/listinfo/swift-evolution
> > >
> > > or, if you would like to keep your feedback private, directly to the
> review manager.
> > >
> > > What goes into a review?
> > >
> > > The goal of the review process is to improve the proposal under review
> through constructive criticism and contribute to the direction of Swift.
> When writing your review, here are some questions you might want to answer
> in your review:
> > >
> > >         * What is your evaluation of the proposal?
> > >         * Is the problem being addressed significant enough to warrant
> a change to Swift?
> > >         * Does this proposal fit well with the feel and direction of
> Swift?
> > >         * If you have used other languages or libraries with a similar
> feature, how do you feel that this proposal compares to those?
> > >         * How much effort did you put into your review? A glance, a
> quick reading, or an in-depth study?
> > >
> > > More information about the Swift evolution process is available at
> > >
> > >
> https://github.com/apple/swift-evolution/blob/master/process.md
> > >
> > > Thank you,
> > >
> > > -Chris Lattner
> > > Review Manager
> > >
> > >
> > >
> > > _______________________________________________
> > > swift-evolution mailing list
> > > swift-evolution at swift.org
> > > https://lists.swift.org/mailman/listinfo/swift-evolution
> > >
> > > _______________________________________________
> > > swift-evolution mailing list
> > > swift-evolution at swift.org
> > > https://lists.swift.org/mailman/listinfo/swift-evolution
> >
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> ------------------------------
>
> Message: 30
> Date: Fri, 13 May 2016 12:51:34 -0700
> From: Matt Wright <mww at apple.com>
> To: Jacob Bandes-Storch <jtbandes at gmail.com>
> Cc: swift-evolution <swift-evolution at swift.org>
> Subject: Re: [swift-evolution] [Review] SE-0088: Modernize libdispatch
>         for     Swift 3 naming conventions
> Message-ID: <82629D20-E9E7-4B06-8E13-3ADBDB225099 at apple.com>
> Content-Type: text/plain; charset=utf-8
>
>
> > On May 13, 2016, at 12:24 PM, Jacob Bandes-Storch <jtbandes at gmail.com>
> wrote:
> >
> > This looks great. Thanks for revising. I'm now a +1 on this.
> >
> > A couple more minor suggestions:
> >
> > - Consider renaming setTimer(...) to resetTimer() or just reset(), or
> something similar?
>
> setTimer addresses both the initial setup as well as setting it again. I’m
> not sure reset is a good name for it.
>
> > - Consider making Semaphore's wait() throw an error, rather than
> returning non-zero, in the event of a timeout. Most common uses will be
> "try! wait()". Or you could have waitForever() be a separate, non-throwing
> function.
>
> Throwing an error here seems like a sensible improvement.
>
> >
> > Jacob Bandes-Storch
> >
> > On Fri, May 13, 2016 at 11:36 AM, Matt Wright via swift-evolution <
> swift-evolution at swift.org> wrote:
> > [Apologies for the weird threading, I missed the original email to the
> list so I can’t reply to it directly]
> >
> > I just wanted to let the list know that I updated proposal SE-0088 to
> fix the typos and include a more complete listing of the Dispatch module
> after the transformations in the proposal have been applied. Additionally,
> I’ve been keeping up with some of the feedback in this review thread and
> looking to see which ones would be best applied to the proposal. Though it
> should be made clear, this particular update only covers fixing the
> inconsistencies in my original proposal and providing a more complete
> overview of the module layout.
> >
> > Similar to the changes in Foundation that are proposed on
> swift-evolution, I don’t expect all of the changes in libdispatch will be
> able to go through this process. As this is a large change (and, hopefully,
> a step forwards) to libdispatch I believe it is important to bring it to
> the swift-evolution list and take away your feedback for inclusion in
> future iterations of the module.
> >
> > Thanks again for your continued feedback,
> > Matt
> >
> > > On Tue, May 10, 2016 at 9:39 PM, Chris Lattner via swift-evolution <
> swift-evolution at swift.org> wrote:
> > > Hello Swift community,
> > >
> > > The review of "SE-0088: Modernize libdispatch for Swift 3 naming
> conventions" begins now and runs through May 17. The proposal is available
> here:
> > >
> > >
> https://github.com/apple/swift-evolution/blob/master/proposals/0088-libdispatch-for-swift3.md
> > >
> > > Reviews are an important part of the Swift evolution process. All
> reviews should be sent to the swift-evolution mailing list at
> > >
> > >         https://lists.swift.org/mailman/listinfo/swift-evolution
> > >
> > > or, if you would like to keep your feedback private, directly to the
> review manager.
> > >
> > > What goes into a review?
> > >
> > > The goal of the review process is to improve the proposal under review
> through constructive criticism and contribute to the direction of Swift.
> When writing your review, here are some questions you might want to answer
> in your review:
> > >
> > >         * What is your evaluation of the proposal?
> > >         * Is the problem being addressed significant enough to warrant
> a change to Swift?
> > >         * Does this proposal fit well with the feel and direction of
> Swift?
> > >         * If you have used other languages or libraries with a similar
> feature, how do you feel that this proposal compares to those?
> > >         * How much effort did you put into your review? A glance, a
> quick reading, or an in-depth study?
> > >
> > > More information about the Swift evolution process is available at
> > >
> > >
> https://github.com/apple/swift-evolution/blob/master/process.md
> > >
> > > Thank you,
> > >
> > > -Chris Lattner
> > > Review Manager
> > >
> > >
> > >
> > > _______________________________________________
> > > swift-evolution mailing list
> > > swift-evolution at swift.org
> > > https://lists.swift.org/mailman/listinfo/swift-evolution
> > >
> > > _______________________________________________
> > > swift-evolution mailing list
> > > swift-evolution at swift.org
> > > https://lists.swift.org/mailman/listinfo/swift-evolution
> >
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> >
>
>
>
> ------------------------------
>
> Message: 31
> Date: Fri, 13 May 2016 16:58:06 -0300
> From: Leonardo Pessoa <me at lmpessoa.com>
> To: Swift-evolution <swift-evolution at swift.org>
> Subject: Re: [swift-evolution] Could enums have their rawValue type
>         inferred?
> Message-ID:
>         <
> CANTOS57wksMRzUAMq0ncf1QAd82vhudf21tnea6wHjhBOFr1PA at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Eric, I think I understood your proposal. If I may explain in other words
> it would be "to automatically cast rawValue when assigning an enum value to
> a variable or argument of the type of the enum's raw value", am I right? I
> think this would imply a little more inference and type checking rules from
> the compiler and maybe even take a little longer to fully compile code. I'm
> not sure it's feasible but from your examples, I can see how it enhances
> readability of the code, so I'm +1 for it. My only concern is that you
> would still need to fully declare the enum's name where the value of the
> enum is used. Taking from your own example
>
>     Animate.fadeIn(view, withSpeed: .fast)
>
> couldn't be called that way if withSpeed expects and NSTimeInterval because
> the compiler won't know whether you're refering to transitionSpeed or to
> ambientAnimationSpeed. You would still have to call it like
>
>     Animate.fadeIn(view, withSpeed: transitionSpeed.fast)
>
> even if you had only one possible enum value over all declared enums
> because that would still force the compiler to search for each value over
> all known enums to define where the value you're using comes from and make
> sure there are no two enums with the same value.
>
> Aside from that, I good with the idea.
>
>
>
> On 13 May 2016 at 15:09, Eric Miller via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> > This might open a larger can of worms than I imagine, but what do you
> > folks think about using the `rawValue` of an enum when that rawValue is a
> > fit for the expected type?
> >
> > Use case.
> >
> > I'm making an animation facade, and it has some speed presets:
> >
> > class Animate {
> >   enum transitionSpeed: NSTimeInterval {
> >     case fast = 0.15
> >     case slow = 0.5
> >   }
> >   enum ambientAnimationSpeed: NSTimeInterval {
> >     case fast = 1.0
> >     case slow = 5.0
> >   }
> >   ...
> > }
> >
> > I did them with static variables at first but that made the call site
> > verbose. Compare:
> >
> > Animate.fadeIn(view, withSpeed: Animate.cfg.transitionFast)
> > Animate.fadeIn(view, withSpeed: .fast)
> >
> > So, I like the enum approach better, but my library code has to use
> > `rawValue` to do anything with the actual value, of course:
> >
> > static func fadeIn(view: UIView?, withSpeed duration:transitionSpeed =
> > .fast) {
> >   ...
> >   UIView.animateWithDuration(duration.rawValue, animations: { })
> > }
> >
> > It's not a serious issue, but the code is more clear and beautiful if it
> > has just myIntent, rather than myIntent.rawValue.
> >
> > I've hit this issue when modeling other things, such as:
> >
> > * server fault codes
> > * HTTP status codes
> > * Currency codes
> > * Days of the week
> >
> > Would it be appropriate to "autocast" to the rawValue of the enum when
> the
> > rawValue's Type matches the type expectation of the API? Or would this
> > introduce a bunch of type system uncertainty?
> >
> > Maybe this could be implemented as a protocol? It feels almost like the
> > convenience of `CustomStringConvertible`'s `description` property.
> >
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/05a1d4c2/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 32
> Date: Fri, 13 May 2016 13:02:44 -0700
> From: Jacob Bandes-Storch <jtbandes at gmail.com>
> To: Erica Sadun <erica at ericasadun.com>
> Cc: Chris Lattner via swift-evolution <swift-evolution at swift.org>
> Subject: Re: [swift-evolution] Removing "_ in" from empty closures
> Message-ID:
>         <CADcs6kPHDONJd_1zVkrEuLBJUT8QsxU_kDcdY=
> hDf6EVOvEvnw at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> +1, seems logical to me:
>
>     let x: [T] = []
>     let x: [T:U] = [:]
>     let x: T->() = {}
>
> Jacob
>
> On Fri, May 13, 2016 at 10:48 AM, Erica Sadun via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> > On May 13, 2016, at 11:14 AM, Cole Campbell via swift-evolution <
> > swift-evolution at swift.org> wrote:
> > >
> > >
> > >> +1. In general, I think we should allow implicit arguments, without
> > requiring the closure to use all the implicit $n variables like we do
> > today. These should all be valid:
> > >>
> > >> let _: () -> () = {}
> > >> let _: (Int) -> () = {}
> > >> let _: (Int, Int) -> Int = { 5 }
> > >> let _: (Int, Int) -> Int = { $0 }
> > >> let _: (Int, Int) -> Int = { $1 }
> > >
> > > +1. This would be excellent.
> >
> > +1. Good riddance to bad code baggage.
> >
> > -- E
> >
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/1fc15c26/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 33
> Date: Fri, 13 May 2016 15:06:18 -0500
> From: Matthew Johnson <matthew at anandabits.com>
> To: Jacob Bandes-Storch <jtbandes at gmail.com>
> Cc: Chris Lattner via swift-evolution <swift-evolution at swift.org>
> Subject: Re: [swift-evolution] Removing "_ in" from empty closures
> Message-ID: <5F3F407C-B624-4596-9850-C8E059D5EE9A at anandabits.com>
> Content-Type: text/plain; charset="utf-8"
>
> Is anyone planning to write a proposal for this?
>
> Sent from my iPhone
>
> > On May 13, 2016, at 3:02 PM, Jacob Bandes-Storch via swift-evolution <
> swift-evolution at swift.org> wrote:
> >
> > +1, seems logical to me:
> >
> >     let x: [T] = []
> >     let x: [T:U] = [:]
> >     let x: T->() = {}
> >
> > Jacob
> >
> >> On Fri, May 13, 2016 at 10:48 AM, Erica Sadun via swift-evolution <
> swift-evolution at swift.org> wrote:
> >> On May 13, 2016, at 11:14 AM, Cole Campbell via swift-evolution <
> swift-evolution at swift.org> wrote:
> >> >
> >> >
> >> >> +1. In general, I think we should allow implicit arguments, without
> requiring the closure to use all the implicit $n variables like we do
> today. These should all be valid:
> >> >>
> >> >> let _: () -> () = {}
> >> >> let _: (Int) -> () = {}
> >> >> let _: (Int, Int) -> Int = { 5 }
> >> >> let _: (Int, Int) -> Int = { $0 }
> >> >> let _: (Int, Int) -> Int = { $1 }
> >> >
> >> > +1. This would be excellent.
> >>
> >> +1. Good riddance to bad code baggage.
> >>
> >> -- E
> >>
> >> _______________________________________________
> >> swift-evolution mailing list
> >> swift-evolution at swift.org
> >> https://lists.swift.org/mailman/listinfo/swift-evolution
> >
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/edf1fd63/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 34
> Date: Fri, 13 May 2016 13:12:10 -0700
> From: Joe Groff <jgroff at apple.com>
> To: Matthew Johnson <matthew at anandabits.com>
> Cc: Matthew Johnson via swift-evolution <swift-evolution at swift.org>
> Subject: Re: [swift-evolution] [Draft] Introducing StaticSelf,  an
>         Invariant Self
> Message-ID: <DA7FECEA-2E3D-45D9-BE6A-E95C859F5794 at apple.com>
> Content-Type: text/plain; charset=us-ascii
>
>
> > On May 13, 2016, at 9:06 AM, Matthew Johnson <matthew at anandabits.com>
> wrote:
> >
> >
> >> On May 13, 2016, at 10:55 AM, Joe Groff <jgroff at apple.com> wrote:
> >>
> >>
> >>> On May 13, 2016, at 8:18 AM, Matthew Johnson <matthew at anandabits.com>
> wrote:
> >>>
> >>> When I write a class Base with non-final methods that return instances
> of Base I can choose whether to state the return type as Self (covariant)
> or Base (invariant, under this proposal StaticSelf would also be an
> alternative way to state this).  If I choose to specify Base as the return
> type derived classes *may* override the method but are not required to.
> Further, if they *do* override the method they are allowed to choose
> whether their implementation returns Base or Derived.
> >>
> >> `StaticSelf` requirements by themselves don't even save you from
> covariance. If Base conforms to a protocol (with Self == Base), Derived
> inherits that conformance and also conforms (with Self == Derived). If
> `StaticSelf` always refers to the conforming type, then it must also be
> bindable to Base and Derived, so a base class must still use a
> covariant-returning method to satisfy the `StaticSelf` requirement.
> >
> > We are specifying that `StaticSelf` refers to the type that explicitly
> declares conformance.  If a class inherits conformance it refers to the
> base class which explicitly declared the conformance it is inheriting.
>
> That makes `StaticSelf` tricky to use in generic code. This would be
> invalid:
>
> protocol Makable {
>         static func make(value: Int) -> StaticSelf
> }
>
> func makeWithZero<T: Fooable>(x: Int) -> T {
>         return T.make(value: 0) // ERROR: T.StaticSelf may be a supertype
> of T so isn't convertible to T
> }
>
> `StaticSelf` in this model is effectively an associated type of the
> protocol, with a `Self: StaticSelf` constraint (if that were supported).
>
> -Joe
>
> ------------------------------
>
> Message: 35
> Date: Fri, 13 May 2016 13:16:31 -0700
> From: Joe Groff <jgroff at apple.com>
> To: Matthew Johnson <matthew at anandabits.com>
> Cc: Chris Lattner via swift-evolution <swift-evolution at swift.org>
> Subject: Re: [swift-evolution] Removing "_ in" from empty closures
> Message-ID: <4D375D91-F148-4B2A-9E14-DE8FBBC41384 at apple.com>
> Content-Type: text/plain; charset=us-ascii
>
>
> > On May 13, 2016, at 1:06 PM, Matthew Johnson via swift-evolution <
> swift-evolution at swift.org> wrote:
> >
> > Is anyone planning to write a proposal for this?
>
> Sounds like you just signed up!
>
> -Joe
>
> > Sent from my iPhone
> >
> > On May 13, 2016, at 3:02 PM, Jacob Bandes-Storch via swift-evolution <
> swift-evolution at swift.org> wrote:
> >
> >> +1, seems logical to me:
> >>
> >>     let x: [T] = []
> >>     let x: [T:U] = [:]
> >>     let x: T->() = {}
> >>
> >> Jacob
> >>
> >> On Fri, May 13, 2016 at 10:48 AM, Erica Sadun via swift-evolution <
> swift-evolution at swift.org> wrote:
> >> On May 13, 2016, at 11:14 AM, Cole Campbell via swift-evolution <
> swift-evolution at swift.org> wrote:
> >> >
> >> >
> >> >> +1. In general, I think we should allow implicit arguments, without
> requiring the closure to use all the implicit $n variables like we do
> today. These should all be valid:
> >> >>
> >> >> let _: () -> () = {}
> >> >> let _: (Int) -> () = {}
> >> >> let _: (Int, Int) -> Int = { 5 }
> >> >> let _: (Int, Int) -> Int = { $0 }
> >> >> let _: (Int, Int) -> Int = { $1 }
> >> >
> >> > +1. This would be excellent.
> >>
> >> +1. Good riddance to bad code baggage.
> >>
> >> -- E
> >>
> >> _______________________________________________
> >> swift-evolution mailing list
> >> swift-evolution at swift.org
> >> https://lists.swift.org/mailman/listinfo/swift-evolution
> >>
> >> _______________________________________________
> >> swift-evolution mailing list
> >> swift-evolution at swift.org
> >> https://lists.swift.org/mailman/listinfo/swift-evolution
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> ------------------------------
>
> Message: 36
> Date: Fri, 13 May 2016 17:07:44 -0400
> From: John Siracusa <siracusa at gmail.com>
> To: swift-evolution <swift-evolution at swift.org>
> Subject: Re: [swift-evolution] [Review] SE-0084: Allow trailing commas
>         in parameter lists and tuples
> Message-ID:
>         <CAJu6bqtOxv6FFoZVuynvJjTdzQimv+gSc9ZNDJZWOjwzGKvd=
> A at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Having used, more or less continuously for my 20 years as a professional
> programmer, both a language that allows trailing commas and one that does
> not, I come down pretty strongly on the side of allowing trailing commas
> (for all the reasons already stated in this thread). If it means requiring
> a newline after the last comma to make some people feel better about it, so
> be it.
>
> -John
>
>
>
> On Fri, May 13, 2016 at 1:46 PM, Erica Sadun via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> >
> > On May 13, 2016, at 11:29 AM, Joe Groff <jgroff at apple.com> wrote:
> >
> >
> > On May 13, 2016, at 7:04 AM, Erica Sadun <erica at ericasadun.com> wrote:
> >
> > On May 12, 2016, at 11:01 PM, Chris Lattner via swift-evolution <
> > swift-evolution at swift.org> wrote:
> >
> > On May 12, 2016, at 4:50 PM, Joe Groff <jgroff at apple.com> wrote:
> >
> > You’re arguing that you want to read Swift code written like this?
> >
> >
> > I wouldn't mind it.
> >
> >
> > I personally find that style repulsive :-) and I haven’t seen swift code
> > commonly doing it.  I’m not sure that we want to encourage it either.
> >
> >
> > No. Tell us what you *really* think of the style. Don't hold back.[1]
> >
> > If we were really concerned about this, a narrower way to solve the same
> > problem would be to allow a comma before the ), but *only* when there is
> a
> > newline between them.  I still don’t see why we’d want to encourage this
> > though.
> >
> >
> > I wouldn't object to this restriction. I cannot think of a situation
> where
> > using ",)" -- that is the comma adjacent to a closing parenthesis --
> makes
> > sense for any reason previously enumerated in support of this proposal.
> >
> >
> > I don't see why we need to micromanage the situations where trailing
> > commas are allowed. That's just unnecessarily increasing the fractal
> > complexity of the language. We've delegated other style choices like
> > requiring `self.` or brace formatting to linters; why does this one need
> to
> > be legislated by the compiler?
> >
> > -Joe
> >
> >
> > Mostly because I'm trying to play nice and get Chris to reconsider. I'd
> > like to get the feature, I'm willing to compromise on the technicalities.
> > Having it would make my coding life significantly easier and if a little
> > micromanagement is involved, I'm not terribly fussed. When I need
> trailing
> > commas, it's always at the ends of lines anyway.
> >
> > But since I don't want to undercut you, so I'd much prefer to step back
> > and defer to your judgement on this.
> >
> > -- E
> >
> >
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/ef8148fe/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 37
> Date: Sat, 14 May 2016 00:16:16 +0300
> From: "Vladimir.S" <svabox at gmail.com>
> To: Adrian Zubarev <adrian.zubarev at devandartist.com>
> Cc: swift-evolution <swift-evolution at swift.org>
> Subject: Re: [swift-evolution] [Pitch] merge types and protocols back
>         together with type<Type, Protocol, ...>
> Message-ID: <e4a00c9d-d327-1015-ab01-0ac4a689a114 at gmail.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> You asked for any example, I give it to you ;-)
> (as I said, it is syntactical, just to show that such struct<> can be used
> to test some struct for conforming to protocol, that was not conformed at
> writing time)
> Probably we can invent useful examples for this struct<> - but I don't
> believe it will be introduced in Swift ;-)
>
> On 13.05.2016 22:14, Adrian Zubarev via swift-evolution wrote:
> > Can we really do that? I mean, I thought about that myself but I came to
> > the conclusion that this scenario is like: I was to lazy to couple this
> > structs to my library protocols, will you do that for me?
>
>
> ------------------------------
>
> Message: 38
> Date: Sat, 14 May 2016 00:46:23 +0300
> From: "Vladimir.S" <svabox at gmail.com>
> To: Joe Groff <jgroff at apple.com>
> Cc: swift-evolution <swift-evolution at swift.org>
> Subject: Re: [swift-evolution] [Draft] Introducing StaticSelf, an
>         Invariant Self
> Message-ID: <cbc94f19-4c47-3859-fc27-05116dec50ae at gmail.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Seems like ->StaticSelf can actually only means returns the class for which
> protocol conformance was applied first(in hierarchy). I.e. some
> `->BaseSelf`.
> But in this case we need a method to get this 'base' class from protocol..
>
> something like(just pseudo code!):
>
> func makeWithZero<T: Makable >(x: Int) -> Makable(T).FirstConformedClass {
>         return T.make(value: 0)
> }
>
> or
>
> func makeWithZero<T: Makable >(x: Int) -> type<T.make(value:)> {
>         return T.make(value: 0)
> }
>
> I don't know if all of this makes sense at all ;-)
>
> On 13.05.2016 23:12, Joe Groff via swift-evolution wrote:
> >
> >> On May 13, 2016, at 9:06 AM, Matthew Johnson <matthew at anandabits.com>
> wrote:
> >>
> >>
> >>> On May 13, 2016, at 10:55 AM, Joe Groff <jgroff at apple.com> wrote:
> >>>
> >>>
> >>>> On May 13, 2016, at 8:18 AM, Matthew Johnson <matthew at anandabits.com>
> wrote:
> >>>>
> >>>> When I write a class Base with non-final methods that return
> instances of Base I can choose whether to state the return type as Self
> (covariant) or Base (invariant, under this proposal StaticSelf would also
> be an alternative way to state this).  If I choose to specify Base as the
> return type derived classes *may* override the method but are not required
> to.  Further, if they *do* override the method they are allowed to choose
> whether their implementation returns Base or Derived.
> >>>
> >>> `StaticSelf` requirements by themselves don't even save you from
> covariance. If Base conforms to a protocol (with Self == Base), Derived
> inherits that conformance and also conforms (with Self == Derived). If
> `StaticSelf` always refers to the conforming type, then it must also be
> bindable to Base and Derived, so a base class must still use a
> covariant-returning method to satisfy the `StaticSelf` requirement.
> >>
> >> We are specifying that `StaticSelf` refers to the type that explicitly
> declares conformance.  If a class inherits conformance it refers to the
> base class which explicitly declared the conformance it is inheriting.
> >
> > That makes `StaticSelf` tricky to use in generic code. This would be
> invalid:
> >
> > protocol Makable {
> >       static func make(value: Int) -> StaticSelf
> > }
> >
> > func makeWithZero<T: Fooable>(x: Int) -> T {
> >       return T.make(value: 0) // ERROR: T.StaticSelf may be a supertype
> of T so isn't convertible to T
> > }
> >
> > `StaticSelf` in this model is effectively an associated type of the
> protocol, with a `Self: StaticSelf` constraint (if that were supported).
> >
> > -Joe
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> >
>
>
> ------------------------------
>
> Message: 39
> Date: Fri, 13 May 2016 17:21:02 -0500
> From: Matthew Johnson <matthew at anandabits.com>
> To: Joe Groff <jgroff at apple.com>
> Cc: Chris Lattner via swift-evolution <swift-evolution at swift.org>
> Subject: Re: [swift-evolution] Removing "_ in" from empty closures
> Message-ID: <86DB53E1-6567-411B-8350-5C9794EEF39E at anandabits.com>
> Content-Type: text/plain;       charset=us-ascii
>
>
>
> Sent from my iPhone
>
> > On May 13, 2016, at 3:16 PM, Joe Groff <jgroff at apple.com> wrote:
> >
> >
> >> On May 13, 2016, at 1:06 PM, Matthew Johnson via swift-evolution <
> swift-evolution at swift.org> wrote:
> >>
> >> Is anyone planning to write a proposal for this?
> >
> > Sounds like you just signed up!
>
> Lol, sounds good.  Just don't want to duplicate efforts! :)
>
> >
> > -Joe
> >
> >> Sent from my iPhone
> >>
> >>> On May 13, 2016, at 3:02 PM, Jacob Bandes-Storch via swift-evolution <
> swift-evolution at swift.org> wrote:
> >>>
> >>> +1, seems logical to me:
> >>>
> >>>    let x: [T] = []
> >>>    let x: [T:U] = [:]
> >>>    let x: T->() = {}
> >>>
> >>> Jacob
> >>>
> >>> On Fri, May 13, 2016 at 10:48 AM, Erica Sadun via swift-evolution <
> swift-evolution at swift.org> wrote:
> >>>> On May 13, 2016, at 11:14 AM, Cole Campbell via swift-evolution <
> swift-evolution at swift.org> wrote:
> >>>>
> >>>>
> >>>>> +1. In general, I think we should allow implicit arguments, without
> requiring the closure to use all the implicit $n variables like we do
> today. These should all be valid:
> >>>>>
> >>>>> let _: () -> () = {}
> >>>>> let _: (Int) -> () = {}
> >>>>> let _: (Int, Int) -> Int = { 5 }
> >>>>> let _: (Int, Int) -> Int = { $0 }
> >>>>> let _: (Int, Int) -> Int = { $1 }
> >>>>
> >>>> +1. This would be excellent.
> >>>
> >>> +1. Good riddance to bad code baggage.
> >>>
> >>> -- E
> >>>
> >>> _______________________________________________
> >>> swift-evolution mailing list
> >>> swift-evolution at swift.org
> >>> https://lists.swift.org/mailman/listinfo/swift-evolution
> >>>
> >>> _______________________________________________
> >>> swift-evolution mailing list
> >>> swift-evolution at swift.org
> >>> https://lists.swift.org/mailman/listinfo/swift-evolution
> >> _______________________________________________
> >> swift-evolution mailing list
> >> swift-evolution at swift.org
> >> https://lists.swift.org/mailman/listinfo/swift-evolution
> >
>
>
>
> ------------------------------
>
> Message: 40
> Date: Fri, 13 May 2016 16:46:31 -0700
> From: Matt Wright <mww at apple.com>
> To: plx <plxswift at icloud.com>
> Cc: "swift-evolution at swift.org" <swift-evolution at swift.org>
> Subject: Re: [swift-evolution] [Review] SE-0088: Modernize libdispatch
>         for     Swift   3 naming conventions
> Message-ID: <7662E01E-8594-45E2-8ABE-2B9B22DA99F5 at apple.com>
> Content-Type: text/plain; charset=utf-8
>
>
> > On May 13, 2016, at 9:29 AM, plx via swift-evolution <
> swift-evolution at swift.org> wrote:
> >
> >
> >>      * What is your evaluation of the proposal?
> >
> > +1 conceptually, some quibbles.
> >
> > I agree with a few others that `synchronously` and `asynchronously`
> aren’t ideal; `dispatchSynchronously` or `dispatchSync` (or `performSync`
> or `performSynchronously`) all seem more-appropriate.
> >
> > I understand the impetus behind having fewer core methods, but IMHO the
> `dispatch_barrier_sync` and `dispatch_barrier_async` calls ought to have
> direct equivalents here (even if they are just sodlib-supplied conveniences
> that call through to the unified method).
>
> I don’t see having barrier as separate methods as a particularly good fit
> for Swift. Given that there are other options surrounding how a block
> operates when it is executed, it makes more sense as default parameters to
> the same methods. This avoids having to have variants of the block
> submission methods for both barrier, QoS, both, etc.
>
> >
> > I also don’t see `dispatch_apply` here anywhere; intentional? Ideally
> it’d be @noescape, but handling `throw` / `rethrow` for that function in
> this case seems complicated.
>
> This is here in the updated version, though I agree it’s not simple to
> handle throwing out of the block as multiple threads are executing the same
> code at once.
>
> >
> > This next one is subjective, but I find the placement of the
> group-related methods somewhat backwards vis-a-vis how I think of them in
> terms of the C-API.
>
> I suspect this can go either way but the block is still being executed on
> a given queue, you’re just associating the execution of that block with a
> given group. In my mind that lives on the queue, as the execution will
> still occur there. Contrasting this to notify, which requests that the
> group itself submits the notify block to the queue when the group itself is
> empty.
>
> >
> > EG: I think of `dispatch_group_async` as a “method” on a
> `dispatch_group`, so would’ve expected this:
> >
> > class DispatchGroup : DispatchObject {
> >
> >  // (actual name should match chosen name convention)
> >  func asynchronouslyDispatch(to queue: DispatchQueue, work:
> @convention(block) () -> Void)
> >
> >  // (actual name should match chosen name convention)
> >  func notify(on queue: DispatchQueue, using block: @convention(block) ()
> -> Void)
> >
> > }
> >
> > …(and presumably the API would have manual enter/leave/wait methods and
> so on exposed).
> >
> > I don’t feel strongly here but bring it up in case others feel similarly.
> >
> > I’m a little confused about the `DispatchSpecificKey<T>` class; is it
> anything more than a way to "smuggle in” a generic type parameter for the
> associated value?
>
> I think it’s a little stronger than “smuggle in” here, it allows the
> compiler to enforce that you have the same type going into setSpecific that
> you get out of getSpecific (or DispatchQueue.getSpecific) for a given key.
> The C API here forces you to cast away from void* and I think this is a
> good example of how the Swift equivalent API is helping make things safer.
>
> >
> > Also on queue-specifics, what is our expected story if we have custom
> destructors? Subclass `DispatchSpecificKey`?
>
> The value supplied to setSpecific is boxed inside a class that’s then
> retained. When the queue is deallocated, or the value is replaced then the
> box is released and normal Swift semantics for memory management will kick
> in on your boxed value. That way the API is still flexible enough to
> consume non-objects, like Ints, but also capable of taking references to
> classes too.
>
> >
> > For things like `Int` specifics, I assume this API is storing auto-boxed
> values…? Is there any way to side-step if we use want to store an unsafe
> pointer? It’s not a big deal for me if we can’t under this API, TBH, but
> I’d at least like to see this API’s implementation and costs spelled-out
> more explicitly.
> >
> > For `DispatchData`, is there a principled reason there isn’t something
> like this defined:
> >
> > struct DispatchDataSegment {
> >  let bytes: UnsafeBufferPointer<UInt8>
> >  let byteIndex: Int
> > }
> >
> > extension DispatchData {
> >
> >  /// Returns a sequence that enumerates the contiguous chunks,
> >  /// e.g. a sequence with elements of type `DispatchDataSegment`.
> >  ///
> >  /// Sequence-based eplacement-for `enumerateBytes(_:)`
> >  var segmentSequence: DispatchDataSegmentSequence { get }
> >
> > }
>
> This is a good path to investigate in future improvements here.
>
> >
> > …or something analogous (instead of the proposed use
> dispatch_data_apply?)?
> >
> > I don’t see any API yet for setting target queues, or getting queue
> labels. I know the proposal isn’t documenting the APIs in full but it’s
> hard to evaluate in that absence.
> >
> > I don’t see basic API on dispatch sources yet for things like setting
> event handlers, (etc.); again I know the APIs aren’t fully specified here
> but it’s hard to evaluate something that’s not fully specified.
>
> These should be present in today’s updated module listing.
>
> >
> >
> >>      * Is the problem being addressed significant enough to warrant a
> change to Swift?
> >>      * Does this proposal fit well with the feel and direction of Swift?
> >>      * If you have used other languages or libraries with a similar
> feature, how do you feel that this proposal compares to those?
> >>      * How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?
> >>
> >> More information about the Swift evolution process is available at
> >>
> >>      https://github.com/apple/swift-evolution/blob/master/process.md
> >>
> >> Thank you,
> >>
> >> -Chris Lattner
> >> Review Manager
> >>
> >>
> >>
> >> _______________________________________________
> >> swift-evolution mailing list
> >> swift-evolution at swift.org
> >> https://lists.swift.org/mailman/listinfo/swift-evolution
> >
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> ------------------------------
>
> Message: 41
> Date: Sat, 14 May 2016 01:50:37 +0200
> From: Adrian Zubarev <adrian.zubarev at devandartist.com>
> To: swift-evolution at swift.org
> Subject: Re: [swift-evolution] [Pitch] merge types and protocols back
>         together with type<Type, Protocol, ...>
> Message-ID: <etPan.5736684d.50456560.6ab2 at DevAndArtist.fritz.box>
> Content-Type: text/plain; charset="utf-8"
>
> If anyone is interested, I started a draft proposal with detailed design
> here:
> https://github.com/DevAndArtist/swift-evolution/blob/master/proposals/nnnn-merging-types-with-protocols.md
>
> I didn’t post it here, because it is a bit huge and could lose its
> markdown formats. `all<>` is always bold, because this is what we are
> interested in, but I provided all possible combinations if the other
> formats would exists (at least all combinations I could think of, anything
> else is derived from these).
>
> `class<>` etc. can be seen as a future direction (I would say), otherwise
> this would easily become out of scope for Swift 3. (I will  move `class<>`
> etc. from detailed design to future direction later.)
>
> I’d love to hear your feedback and strong arguments for the motivation
> part I could include into this proposal.
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 13. Mai 2016 bei 23:16:20, Vladimir.S (svabox at gmail.com) schrieb:
>
> You asked for any example, I give it to you ;-)
> (as I said, it is syntactical, just to show that such struct<> can be used
> to test some struct for conforming to protocol, that was not conformed at
> writing time)
> Probably we can invent useful examples for this struct<> - but I don't
> believe it will be introduced in Swift ;-)
>
> On 13.05.2016 22:14, Adrian Zubarev via swift-evolution wrote:
> > Can we really do that? I mean, I thought about that myself but I came to
> > the conclusion that this scenario is like: I was to lazy to couple this
> > structs to my library protocols, will you do that for me?
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://lists.swift.org/pipermail/swift-evolution/attachments/20160514/8100916d/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 42
> Date: Fri, 13 May 2016 19:16:50 -0500
> From: Matthew Johnson <matthew at anandabits.com>
> To: Adrian Zubarev <adrian.zubarev at devandartist.com>
> Cc: swift-evolution at swift.org
> Subject: Re: [swift-evolution] [Pitch] merge types and protocols back
>         together with type<Type, Protocol, ...>
> Message-ID: <99488013-D61B-4CD2-9671-3848838FCC8C at anandabits.com>
> Content-Type: text/plain; charset="utf-8"
>
>
> > On May 13, 2016, at 2:14 PM, Adrian Zubarev via swift-evolution <
> swift-evolution at swift.org> wrote:
> >
> >> As we can(as example) expect that in 3rd party code someone will do:
> >>
> >> extension StructA: ExtraProtocol1 {
> >> func bar() {}
> >> }
> >>
> >> extension StructB: ExtraProtocol2 {
> >> func blort() {}
> >> }
> >
> >
> > Can we really do that? I mean, I thought about that myself but I came to
> the conclusion that this scenario is like: I was to lazy to couple this
> structs to my library protocols, will you do that for me?
> >
> > Sure one could think that this protocols might be optional but the `f(p:
> MyProtocol)` function will cover this scenario.
> >
> > Another interesting side-effect `struct<>`, `class<>` and `enum<>` will
> allow us to do is to distinguish between value and reference types for
> generics. I tried this differentiation types with protocols like
> `AnyReference` and `AnyValue` in another topic before (Should we rename
> "class" when referring to protocol conformance? <
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160502/016286.html>),
> but I kinda like this new approach.
> >
> > Here is what I mean in detail:
> >
> > protocol SomeProtocol /* we can’t constraint it to value types at the
> moment, only `class`es works */ {}
> >
> > func foo<T>(value: struct<T, SomeProtocol>) { /* do some work */ }
> >
> > This function is pretty neat. (1) You can force the library user to
> create a struct with conformance to `SomeProtocol`. (2) This approach will
> accept any struct which conforms to that protocol.
> >
> > As I said in the protocol comment above protocols can only be
> constrained to classes at the moment, and this might change in the future.
> If we also had some sort of things for generics so the function from above
> might have looked like this:
> >
> > func foo<T: struct where T: SomeProtocol>(value: T) {}
> >
> > But it seems that such a thing won’t ever happen to Swift.
> >
> > Basically `struct<>`, `class<>` and `enum<>` will just enable this for
> us. `all<>` would accept any type at its first element.
> >
> > func foo<T /* add more constraints here */ >(value: all<T,
> SomeProtocol>) { /* T could be a reference type or value type */ }
> >
> > That been said, `all<>` could replace `protocol<>` where it is composed
> from protocols. `all<>` can only be used as a generic constraints if the
> first element is a protocol or a reference type.
> >
> > @Matthew: isn’t this somehow a step towards (generic) `PureValue` types?
>
> No.  These say nothing about semantics.  PureValue is all about the
> semantics of a type and has nothing to do with what mechanism is used to
> implement the type.
>
> >
> > struct A<T> {
> >
> >     var value: struct<T> // if we drop the strict rule of at least one
> protocols
> > }
> >
> > How does it sound to you?
> >
> > --
> > Adrian Zubarev
> > Sent with Airmail
> >
> > Am 13. Mai 2016 bei 20:34:59, Vladimir.S (svabox at gmail.com <mailto:
> svabox at gmail.com>) schrieb:
> >
> >> Hmm..
> >>
> >> What about such synthetic scenario:
> >>
> >> at the moment of writing our code we have:
> >>
> >> public protocol MyProtocol {
> >> func foo()
> >> }
> >>
> >> public struct StructA:MyProtocol {
> >> func foo()
> >> }
> >>
> >> public struct StructB:MyProtocol {
> >> func foo()
> >> }
> >>
> >> and have
> >>
> >> public protocol ExtraProtocol1 {
> >> func bar()
> >> }
> >>
> >> public protocol ExtraProtocol2 {
> >> func blort()
> >> }
> >>
> >> then we actually can have such code:
> >>
> >> func f(p: MyProtocol) {
> >> if let a = p as? struct<StructA, ExtraProtocol1> {
> >> a.foo()
> >> a.bar()
> >> }
> >> else
> >> if let b = p as? struct<StructB, ExtraProtocol2> {
> >> b.foo()
> >> b.blort()
> >> }
> >> }
> >>
> >>
> >>
> >>
> >> On 13.05.2016 20:50, Adrian Zubarev via swift-evolution wrote:
> >> >> 'struct<>' does seem redundant unless it becomes subtypeable. If
> >> >> you want a struct which conforms to several protocols, protocol<>
> >> >> already covers this.
> >> >>
> >> >> I think this is not correct. Lets check this example:
> >> >>
> >> >> func foo(value: SomeProtocol) {
> >> >>
> >> >> if let a = value as? struct<StructA, SomeProtocol> { /* do
> >> >> something with a */ }
> >> >>
> >> >> else if let b = value as? struct<StructB, SomeProtocol> { /* do
> >> >> something with b */ }
> >> >>
> >> >> }
> >> >>
> >> >> In this scenario you’ll be able to access properties and functions
> >> >> from `StructA` or `StructB` which might not be covered by
> >> >> `SomeProtocol`. Everything is merged nicely into one instance. But
> >> >> you are right it depends on the use-case.
> >> >>
> >> >>
> >> >> There is no need to include the protocol here. Just do this:
> >> >>
> >> >> if let a = value as? StructA { use a }
> >> >>
> >> > Whoops, I forgot that this will do the trick. I apologize for any
> confusion
> >> > here, you are totally right.
> >> >
> >> > That been said, do we really need `type<>` aka. `all<>` for value
> types? I
> >> > need to rethink this part of the proposal. Is there any use-case
> where we
> >> > would need this (any scenario for the future Swift version also
> counts)?
> >> >
> >> > If we had `all<>` in Swift already for extendable reference types and
> one
> >> > day structs would become subtypeable, this wouldn’t be a huge problem
> to
> >> > upgrade `all<>` for structs I guess.
> >> >
> >> > --
> >> > Adrian Zubarev
> >> > Sent with Airmail
> >> >
> >> >
> >> >
> >> > _______________________________________________
> >> > swift-evolution mailing list
> >> > swift-evolution at swift.org
> >> > https://lists.swift.org/mailman/listinfo/swift-evolution
> >> >
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> > https://lists.swift.org/mailman/listinfo/swift-evolution <
> https://lists.swift.org/mailman/listinfo/swift-evolution>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/0d832263/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 43
> Date: Fri, 13 May 2016 19:33:04 -0500
> From: Matthew Johnson <matthew at anandabits.com>
> To: Joe Groff <jgroff at apple.com>
> Cc: Matthew Johnson via swift-evolution <swift-evolution at swift.org>
> Subject: Re: [swift-evolution] [Draft] Introducing StaticSelf,  an
>         Invariant Self
> Message-ID: <E5E5D42D-5E98-4FD0-A29A-A4F228B4D558 at anandabits.com>
> Content-Type: text/plain; charset="utf-8"
>
>
> > On May 13, 2016, at 3:12 PM, Joe Groff <jgroff at apple.com> wrote:
> >
> >>
> >> On May 13, 2016, at 9:06 AM, Matthew Johnson <matthew at anandabits.com>
> wrote:
> >>
> >>
> >>> On May 13, 2016, at 10:55 AM, Joe Groff <jgroff at apple.com> wrote:
> >>>
> >>>
> >>>> On May 13, 2016, at 8:18 AM, Matthew Johnson <matthew at anandabits.com>
> wrote:
> >>>>
> >>>> When I write a class Base with non-final methods that return
> instances of Base I can choose whether to state the return type as Self
> (covariant) or Base (invariant, under this proposal StaticSelf would also
> be an alternative way to state this).  If I choose to specify Base as the
> return type derived classes *may* override the method but are not required
> to.  Further, if they *do* override the method they are allowed to choose
> whether their implementation returns Base or Derived.
> >>>
> >>> `StaticSelf` requirements by themselves don't even save you from
> covariance. If Base conforms to a protocol (with Self == Base), Derived
> inherits that conformance and also conforms (with Self == Derived). If
> `StaticSelf` always refers to the conforming type, then it must also be
> bindable to Base and Derived, so a base class must still use a
> covariant-returning method to satisfy the `StaticSelf` requirement.
> >>
> >> We are specifying that `StaticSelf` refers to the type that explicitly
> declares conformance.  If a class inherits conformance it refers to the
> base class which explicitly declared the conformance it is inheriting.
> >
> > That makes `StaticSelf` tricky to use in generic code. This would be
> invalid:
> >
> > protocol Makable {
> >       static func make(value: Int) -> StaticSelf
> > }
> >
> > func makeWithZero<T: Fooable>(x: Int) -> T {
> >       return T.make(value: 0) // ERROR: T.StaticSelf may be a supertype
> of T so isn't convertible to T
> > }
>
> I agree it’s a bit tricky.  But that’s better than not possible at all.
> You just need a typealias and a same type constraint to make this work as
> expected / desired:
>
> protocol Makable {
>         typealias RootMakable = StaticSelf
>         static func make(value: Int) -> StaticSelf
> }
>
> func makeWithZero<T: Makable where T == T.RootMakable>(x: Int) -> T {
>         return T.make(value: 0) // works now
> }
>
> Now that we have a typealias we can refer to the binding of StaticSelf and
> constrain it as necessary for whatever purpose we have in mind.  In some
> cases that will be a same type constraint so that our code works properly
> with class clusters.  I don’t have concrete examples of other use cases but
> can imagine use cases constraining the typealias to a protocol, for example.
>
> If we had control over inheritance of conformance at the point of
> conformance we probably wouldn’t be talking about StaticSelf.  But we don’t
> and this is a problem that has caused enough people trouble that it is
> worth solving.  StaticSelf does that in a general way that is also as a
> shorthand in types themselves and has consistent semantics in both use
> cases.
>
> IIRC the design of point-of-conformance control over inheritance of
> conformance is pretty thorny.  I wouldn’t mind seeing that feature
> eventually but don’t have any confidence that it will come soon.
>
> >
> > `StaticSelf` in this model is effectively an associated type of the
> protocol, with a `Self: StaticSelf` constraint (if that were supported).
>
> If you add that the associated type is automatically bound with the
> initial conformance (and cannot be modified by subclass conformances) then
> yes, you can look at it this way.
>
>
>
> >
> > -Joe
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/3276330a/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 44
> Date: Fri, 13 May 2016 21:06:11 -0700
> From: Austin Zheng <austinzheng at gmail.com>
> To: Matthew Johnson <matthew at anandabits.com>
> Cc: swift-evolution <swift-evolution at swift.org>
> Subject: Re: [swift-evolution] [Pitch] merge types and protocols back
>         together with type<Type, Protocol, ...>
> Message-ID:
>         <
> CANGnqV14+BLVHx7CZgoHfTKnQfpxDXFzp4mTWO4MFCFtZfKCAg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> This is certainly a detailed and well-considered proposal.
>
> I don't think the struct functionality makes much sense. There are two ways
> you can use the struct<...> construct:
>
> 1. struct<SomeConcreteStruct, Protocol1, Protocol2>. In this case the
> struct<...> representation is unnecessary; the protocols that are available
> to the user are known at compile-time, and structs can't have subtypes that
> conform to additional protocols like classes can. There is an example
> marked "func boo(value: struct<SomeStruct>) /* equivalent to */ func
> boo(value: SomeStruct)"; my question is why having more than two ways to
> express the same idea makes the language better, easier to use, etc.
>
> 2. struct<T, Protocol1, Protocol2>. In this case struct<...> is being used
> as an add-on to the generics system to denote a 'must be value type'
> constraint. However, I think a 'T : class'-like 'struct' constraint makes
> more sense, both because it fits better with the existing 'class'
> constraint and because it can be used anywhere the generic system allows a
> type parameter to be constrained. A generic 'struct' constraint would give
> the currently generics system as much expressive power as struct<...>.
>
> Overall, rather than having this be a separate feature I think it should be
> developed as part of the "Generalized Existentials" feature that is already
> on the roadmap for Swift 3. The cases where adding class<...>, struct<...>,
> etc can improve expressive power are covered by allowing variables to take
> existential types with constraints. The one big feature that Generalized
> Existentials should absorb from this proposal is allowing the
> representation of a concrete class type with protocol constraints
> (<MyClass, SomeProtocol, AnotherProtocol>).
>
> Best,
> Austin
>
>
>
> On Fri, May 13, 2016 at 5:16 PM, Matthew Johnson via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> >
> > On May 13, 2016, at 2:14 PM, Adrian Zubarev via swift-evolution <
> > swift-evolution at swift.org> wrote:
> >
> > As we can(as example) expect that in 3rd party code someone will do:
> >
> > extension StructA: ExtraProtocol1 {
> > func bar() {}
> > }
> >
> > extension StructB: ExtraProtocol2 {
> > func blort() {}
> > }
> >
> >
> > Can we really do that? I mean, I thought about that myself but I came to
> > the conclusion that this scenario is like: I was to lazy to couple this
> > structs to my library protocols, will you do that for me?
> >
> > Sure one could think that this protocols might be optional but the `f(p:
> > MyProtocol)` function will cover this scenario.
> >
> > Another interesting side-effect `struct<>`, `class<>` and `enum<>` will
> > allow us to do is to distinguish between value and reference types for
> > generics. I tried this differentiation types with protocols like
> > `AnyReference` and `AnyValue` in another topic before (Should we rename
> > "class" when referring to protocol conformance?
> > <
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160502/016286.html
> >),
> > but I kinda like this new approach.
> >
> > Here is what I mean in detail:
> >
> > protocol SomeProtocol /* we can’t constraint it to value types at the
> > moment, only `class`es works */ {}
> >
> > func foo<T>(value: struct<T, SomeProtocol>) { /* do some work */ }
> >
> > This function is pretty neat. (1) You can force the library user to
> create
> > a struct with conformance to `SomeProtocol`. (2) This approach will
> accept
> > any struct which conforms to that protocol.
> >
> > As I said in the protocol comment above protocols can only be constrained
> > to classes at the moment, and this might change in the future. If we also
> > had some sort of things for generics so the function from above might
> have
> > looked like this:
> >
> > func foo<T: struct where T: SomeProtocol>(value: T) {}
> >
> > But it seems that such a thing won’t ever happen to Swift.
> >
> > Basically `struct<>`, `class<>` and `enum<>` will just enable this for
> us.
> > `all<>` would accept any type at its first element.
> >
> > func foo<T /* add more constraints here */ >(value: all<T, SomeProtocol>)
> > { /* T could be a reference type or value type */ }
> >
> > That been said, `all<>` could replace `protocol<>` where it is composed
> > from protocols. `all<>` can only be used as a generic constraints if the
> > first element is a protocol or a reference type.
> >
> > @Matthew: isn’t this somehow a step towards (generic) `PureValue` types?
> >
> >
> > No.  These say nothing about semantics.  PureValue is all about the
> > semantics of a type and has nothing to do with what mechanism is used to
> > implement the type.
> >
> >
> > struct A<T> {
> >
> >     var value: struct<T> // if we drop the strict rule of at least one
> > protocols
> > }
> >
> > How does it sound to you?
> >
> > --
> > Adrian Zubarev
> > Sent with Airmail
> >
> > Am 13. Mai 2016 bei 20:34:59, Vladimir.S (svabox at gmail.com) schrieb:
> >
> > Hmm..
> >
> > What about such synthetic scenario:
> >
> > at the moment of writing our code we have:
> >
> > public protocol MyProtocol {
> > func foo()
> > }
> >
> > public struct StructA:MyProtocol {
> > func foo()
> > }
> >
> > public struct StructB:MyProtocol {
> > func foo()
> > }
> >
> > and have
> >
> > public protocol ExtraProtocol1 {
> > func bar()
> > }
> >
> > public protocol ExtraProtocol2 {
> > func blort()
> > }
> >
> > then we actually can have such code:
> >
> > func f(p: MyProtocol) {
> > if let a = p as? struct<StructA, ExtraProtocol1> {
> > a.foo()
> > a.bar()
> > }
> > else
> > if let b = p as? struct<StructB, ExtraProtocol2> {
> > b.foo()
> > b.blort()
> > }
> > }
> >
> >
> >
> >
> > On 13.05.2016 20:50, Adrian Zubarev via swift-evolution wrote:
> > >> 'struct<>' does seem redundant unless it becomes subtypeable. If
> > >> you want a struct which conforms to several protocols, protocol<>
> > >> already covers this.
> > >>
> > >> I think this is not correct. Lets check this example:
> > >>
> > >> func foo(value: SomeProtocol) {
> > >>
> > >> if let a = value as? struct<StructA, SomeProtocol> { /* do
> > >> something with a */ }
> > >>
> > >> else if let b = value as? struct<StructB, SomeProtocol> { /* do
> > >> something with b */ }
> > >>
> > >> }
> > >>
> > >> In this scenario you’ll be able to access properties and functions
> > >> from `StructA` or `StructB` which might not be covered by
> > >> `SomeProtocol`. Everything is merged nicely into one instance. But
> > >> you are right it depends on the use-case.
> > >>
> > >>
> > >> There is no need to include the protocol here. Just do this:
> > >>
> > >> if let a = value as? StructA { use a }
> > >>
> > > Whoops, I forgot that this will do the trick. I apologize for any
> > confusion
> > > here, you are totally right.
> > >
> > > That been said, do we really need `type<>` aka. `all<>` for value
> types?
> > I
> > > need to rethink this part of the proposal. Is there any use-case where
> we
> >
> > > would need this (any scenario for the future Swift version also
> counts)?
> >
> > >
> > > If we had `all<>` in Swift already for extendable reference types and
> one
> >
> > > day structs would become subtypeable, this wouldn’t be a huge problem
> to
> >
> > > upgrade `all<>` for structs I guess.
> > >
> > > --
> > > Adrian Zubarev
> > > Sent with Airmail
> > >
> > >
> > >
> > > _______________________________________________
> > > swift-evolution mailing list
> > > swift-evolution at swift.org
> > > https://lists.swift.org/mailman/listinfo/swift-evolution
> > >
> >
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> >
> >
> >
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/350b0db2/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 45
> Date: Sat, 14 May 2016 01:05:32 -0400
> From: Jon Shier <jon at jonshier.com>
> To: swift-evolution at swift.org
> Subject: Re: [swift-evolution] [Review] SE-0081: Move where clause to
>         end of  declaration
> Message-ID: <DC2A000A-6322-43A5-BD6D-2C405C745C89 at jonshier.com>
> Content-Type: text/plain; charset="utf-8"
>
> > * What is your evaluation of the proposal?
>
> -1
>
> No one has been able to explain how this change improves readability, it
> just seems like it’s supposed to be self evident. I would argue that it
> makes the generic definitions less readable by separating declarations and
> their relevant where clauses. At best this change just moves the already
> unreadable mass of text elsewhere, where it’s still unreadable.
> Furthermore, it trades this supposed readability of generic parameters for
> decreased readability of the actual function signature, since that
> signature’s now buried between the generic definitions and the where
> clauses. This is especially bad when declaring a single generic type that
> can easily fit on a single line, such as:
>
> func something<T: Decodable where T == T.DecodedType>(with something: T)
> -> String
>
> turns into this, which is less readable to me, as it hides important
> information between the generic information:
>
> func something<T: Decodable>(with something: T) -> String where T ==
> T.DecodedType
>
> Also, this proposal doesn’t explain how the definitions for generic types
> would change. Using the proposed grammar would be even worse on types. From:
>
> final class NetworkOperation<T: Decodable where T == T.DecodedType>:
> Operation,… {
>
> to:
>
> final class NetworkOperation<T: Decodable>: Operation,… where T ==
> T.DecodedType {
>
> The additional conformances types can have make this an especially bad use
> case for this proposal.
>
> >       * Is the problem being addressed significant enough to warrant a
> change to Swift?
>
> It can be a problem, but I don’t see how this proposal fixes it.
> Appropriate code styling, whether manual or provided by an IDE, could
> provide much better readability than this proposal ever could.
>
> >       * Does this proposal fit well with the feel and direction of Swift?
>
> Changes proposed for “readability” need to be closely scrutinized, as one
> programmer’s readable and another’s Perl. I don’t think this proposal meets
> the high standard this list has tried to set for things to the language.
>
> >       * If you have used other languages or libraries with a similar
> feature, how do you feel that this proposal compares to those?
>
> Java and C++’s generics, which are rather different. And despite what they
> may have intended, I don’t think generics in either language are used as
> much as in Swift.
>
> >       * How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?
>
> Read the proposal, the thread thus far, and considered my response.
>
>
>
> Jon
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://lists.swift.org/pipermail/swift-evolution/attachments/20160514/a80f432d/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 46
> Date: Sat, 14 May 2016 01:19:49 -0400
> From: Jon Shier <jon at jonshier.com>
> To: swift-evolution <swift-evolution at swift.org>
> Subject: Re: [swift-evolution] [Pitch] Consistent bridging for
>         NSErrors at     the language boundary
> Message-ID: <C1FE5542-1469-4ECB-B422-D4C7F013CA58 at jonshier.com>
> Content-Type: text/plain; charset="utf-8"
>
> Charles:
>         I appreciate the attempt to minimize a current pain point and I
> agree on most of your analysis of the current NSError bridging but I think
> your proposal is fundamentally flawed. By forcing the core error type to
> have properties from NSError, you’re essentially finalizing what all error
> types in Swift should look like. Error domains, codes, and info
> dictionaries are not Swift, and forcing every error produced in Swift to
> have those properties is a regression from the freedom ErrorType has given
> us. No native Swift error type I’ve seen so far has chosen to replicate
> those properties, and for good reason: they are a relic of C which have no
> place in Swift. There are far better error designs out there. If you want
> to propose a strong type of error for Swift, go ahead, but it should be
> thoroughly inspired by Swift, not driven by a desire to ease bridging to
> NSError.
>
>
>
> Jon Shier
>
>
> > On May 5, 2016, at 3:06 PM, Charles Srstka via swift-evolution <
> swift-evolution at swift.org> wrote:
> >
> > I formerly posted a less-fleshed-out version of this in the “Reducing
> bridging magic” thread, but I thought this might warrant its own pitch.
> What do you all think?
> >
> > MOTIVATION:
> >
> > Over the past couple of years, Swift has made great strides toward
> seamless interoperability with existing Objective-C APIs, and with SE-0005,
> SE-0033, SE-0057, SE-0062, SE-0064, and SE-0070, seems poised to become
> even better in that regard. However, there still exists one major pain
> point when going back and forth between Swift and Objective-C, and that
> lies in the area of error reporting. Passing errors between Objective-C and
> Swift APIs is currently quite awkward, for several reasons:
> >
> > - The Swift-approved mechanism for reporting errors is a protocol named
> ErrorType (ErrorProtocol in the latest sources). However, Objective-C
> represent errors using a class named NSError. In addition to being a
> reference type, which feels quite unnatural for an error object by Swift’s
> conventions, NSError follows a completely paradigm from what most
> ErrorProtocol objects use to store errors, using a string-based domain and
> and integer code, along with a userInfo dictionary to store information to
> be presented to the user. While the domain and code are available as
> methods on ErrorProtocol, they are prefixed with underscores, and there is
> no direct equivalent to userInfo.
> >
> > - Unlike other Objective-C classes like NSString and NSArray which are
> consistently bridged to value types when presenting Objective-C interfaces
> to Swift, the handling of NSError objects is inconsistent. Objective-C APIs
> which return an error by reference using an autoreleasing NSError **
> pointer are converted to use the Swift try/catch mechanism, presenting the
> returned error as an ErrorProtocol (which is actually an NSError).
> Similarly, Swift APIs using try/catch are presented to Objective-C as
> autoreleasing NSError ** pointers, and the ErrorProtocol-conforming error
> is converted to an NSError when it is called by Objective-C. However, when
> passing around error objects in any way other than these, the errors are
> not bridged. An Objective-C API that takes an NSError, such as NSApp’s
> -presentError: method, still leaves NSError as the type in the interface
> presented to Swift, as do the many asynchronous APIs in Cocoa that return
> an NSError as one of the arguments to a completion handler. Swift APIs that
> accept ErrorProtocols, on the other hand, are not presented to Objective-C
> at all, necessitating any such APIs also be declared to take NSErrors.
> >
> > - To convert ErrorProtocols to NSErrors, Swift provides a bridging
> mechanism, invoked via “as NSError”, which wraps the error in a private
> NSError subclass class called _SwiftNativeNSError. This subclass can be
> cast back to the original error type, thus returning the original wrapped
> error. When a Swift API that is marked “throws” is called from Objective-C
> and then throws an error, the same bridging mechanism is invoked. However,
> this bridging is not very useful, since Cocoa tends to use NSError’s
> userInfo dictionary to present error information to the user, and
> ErrorProtocol contains no equivalent to the userInfo dictionary. The result
> of this is that when a Swift API throws an error, and this error is passed
> to Cocoa, the user tends to get a generic error message instead of
> something actually useful.
> >
> > - The above problem means that a Swift developer must be very careful
> never to use “as NSError”, and to be sure to construct an NSError when
> throwing an error in an API that may be called from Objective-C, rather
> than simply throwing the error directly, or else the error will not be
> properly presented. If the developer makes a mistake here, it will not be
> known until runtime. I have personally wasted quite a bit of time trying to
> hunt down points in a complicated program where an error was accidentally
> converted to NSError via the bridge rather than explicitly.
> >
> > - The same problem also puts the Swift developer between a rock and a
> hard place, if they have other code that wants to check these errors. In a
> pure-Swift program, checking against a particular error can often be done
> simply via an equality check. If the error has been converted to NSError
> via the bridge, this also works, since the bridge will return the original
> Swift error when casted. However, if the API that threw the error has been
> conscientious about constructing an NSError to avoid the userInfo issue,
> the NSError will not be easily castable back to the original Swift error
> type. Instead, the developer will have to compare the NSError’s error
> domain and code. The code itself will have to have been assigned by the
> throwing API. As the domain is stringly-typed and the code will often be
> extraneous to the actual error definition, this is all very
> runtime-dependent and can easily become incorrect or out of sync, which
> will break the program’s error reporting.
> >
> > - The UI for creating NSError objects is extremely verbose, and
> eminently un-Swift-like, usually requiring two lines of code: one to
> construct a dictionary, with an extremely verbose
> key—NSLocalizedFailureReasonErrorKey—to indicate the actual error message
> text to the user, and one to construct the NSError object. The latter is
> itself quite verbose, requiring the developer to enter values for a domain
> and code which she typically does not care about, since ErrorProtocol
> provides decent enough default implementations for those values in most
> cases.
> >
> > - Due to bugs in the bridging mechanism, it is possible for a
> _SwiftNativeNSError to get run a second time through the bridge, which
> removes the userInfo dictionary altogether, once again result in incorrect
> error reporting.
> >
> > - The need for the “as NSError” bridging mechanism makes it more
> difficult to implement otherwise positive changes such as Joe Groff’s
> proposal to simplify the “as?” keyword (
> https://github.com/apple/swift-evolution/pull/289 <
> https://github.com/apple/swift-evolution/pull/289>).
> >
> > - Finally, the fact that Swift code that deals with errors must always
> be filled with either “as NSError” statements or explicit NSError
> initializations sprinkled through results in code that is quite a bit
> uglier than it needs to be.
> >
> > PROPOSED APPROACH:
> >
> > I propose consistently bridging NSError to a value type whenever it is
> exposed to Swift code via an API signature, and doing the equivalent in the
> opposite direction, similarly to how NSStrings and Strings are bridged to
> and from each other in API signatures.
> >
> > The benefits of this approach are many:
> >
> > 1. This is very similar to the bridging that already exists for
> String<->NSString, Array<->NSArray, when crossing the language boundary, so
> this improves the consistency of the language.
> >
> > 2. Special-case type checks would be mostly restricted to the special
> magic that the compiler inserts when crossing the boundary, thus reducing
> the potential for bugs.
> >
> > 3. NSError is no longer required to conform to ErrorProtocol, reducing
> the type checking that has to go on during the bridging process, also
> reducing the potential for bugs.
> >
> > 4. Since the is, as, as?, and as! operators would no longer be needed to
> bridge NSErrors to native errors and back, improvements to that mechanism
> such as (https://github.com/apple/swift-evolution/pull/289 <
> https://github.com/apple/swift-evolution/pull/289>) become viable, and
> the casting operators can be made to no longer act in ways that are often
> surprising and confusing.
> >
> > 5. The programmer never has to deal with NSError objects in Swift code
> again.
> >
> > DETAILED DESIGN:
> >
> > 1. Extend ErrorProtocol such that it has public, non-underscored methods
> for the domain, code, and userInfo. The first two of these retain their
> existing default implementations, whereas the last of these will have a
> default implementation that just returns an empty dictionary. The user can
> override any of these to provide more information as needed.
> >
> > 2. NSError’s conformance to ErrorProtocol is removed, since Swift code
> will generally no longer need to work directly with NSErrors.
> >
> > 3. A new private error value type is introduced that conforms to
> ErrorProtocol. Since this type will be private, its specific name is up to
> the implementers, but for the purpose of this example we will assume that
> it is named _ObjCErrorType. This type wraps an NSError, and forwards its
> domain, code, and userInfo properties to it.
> >
> > 4. The existing _SwiftNativeNSError class remains, and continues to work
> as it does currently, although it is extended to forward the userInfo
> property to the wrapped Swift error. Thus, this class now wraps a native
> Swift error and forwards the domain, code, and userInfo properties to it.
> >
> > 5. Objective-C APIs that return an NSError object present it as
> ErrorProtocol in the signature. When called by Swift, the type of the
> NSError is checked. If the type is _SwiftNativeNSError, the original Swift
> error is unwrapped and returned. Otherwise, the NSError is wrapped in an
> instance of _ObjCErrorType and returned as an ErrorProtocol.
> >
> > 6. Objective-C APIs that take NSError objects now show ErrorProtocol in
> their signatures as well. If an _ObjCErrorType is passed to one of these
> APIs, its wrapped NSError is unwrapped and passed to the API. Otherwise,
> the error is wrapped in a _SwiftNativeNSError and passed through to the API.
> >
> > 7. Swift errors would still be convertible to NSError, if the developer
> needed to do so manually. This could be done either via the current “as
> NSError” bridge, or via initializers and/or accessors on NSError.
> >
> > IMPACT ON EXISTING CODE:
> >
> > Required changes to existing code will mostly involve removing “as
> NSError” statements. Workarounds to the problem being addressed by this
> change will probably also want to be removed, as they will no longer be
> needed.
> >
> > ALTERNATIVES CONSIDERED:
> >
> > Do nothing, and let the terrorists win.
> >
> > Charles
> >
> >
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://lists.swift.org/pipermail/swift-evolution/attachments/20160514/480f784a/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 47
> Date: Sat, 14 May 2016 15:20:05 +1000
> From: Patrick Smith <pgwsmith at gmail.com>
> To: Kevin Ballard <kevin at sb.org>
> Cc: swift-evolution at swift.org
> Subject: Re: [swift-evolution] [Review] SE-0045: Add scan,
>         prefix(while:), drop(while:), and iterate to the stdlib
> Message-ID: <9264E8FF-0A0E-4CC9-BF8E-51E0B67B5752 at gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Would there be any issue with the return type being AnySequence? It’s used
> in other areas:
>
> LazySequence & FlattenSequence’s
> dropFirst(n: Int) -> AnySequence<Generator.Element>
> dropLast(n: Int) -> AnySequence<Generator.Element>
>
> No need to introduce another type, and it’s straight forward to implement
> with AnySequence.
>
>
> > On 14 May 2016, at 5:07 AM, Kevin Ballard via swift-evolution <
> swift-evolution at swift.org> wrote:
> >
> > On Fri, May 13, 2016, at 11:08 AM, Erica Sadun wrote:
> >> On May 1, 2016, at 5:13 AM, Brent Royal-Gordon via swift-evolution <
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> >>>
> >>>> The proposal has been updated as per feedback from the core team (
> https://github.com/apple/swift-evolution/pull/275 <
> https://github.com/apple/swift-evolution/pull/275>). This includes
> removing some last vestiges of Swift 2 naming as well as replacing
> `iterate(_:apply:)` with an overloaded function `unfold(_:applying:)`.
> >>>
> >>> The proposal says this:
> >>>
> >>>  public func unfold<T, State>(_ initialState: State, applying: State
> -> (T, State)?) -> UnfoldSequence<T>
> >>>  public func unfold<T>(_ initialElement: T, apply: T -> T) ->
> UnfoldSequence<T>
> >>>
> >>> However, the comment implies that the second one should instead be
> this:
> >>>
> >>>  public func unfold<T>(_ initialElement: T, applying: T -> T?) ->
> UnfoldSequence<T>
> >>>
> >>> I'm not sure I like having these be overloaded on only the return type
> of the closure. Maybe we could do something like this?
> >>>
> >>>  public func unfold<T, State>(fromState initialState: State, applying:
> State -> (T, State)?) -> UnfoldSequence<T>
> >>>  public func unfold<T>(fromFirst initialElement: T, apply: T -> T) ->
> UnfoldSequence<T>
> >>>
> >>> That way you're calling either `unfold(fromState:applying:)` or
> `unfold(fromFirst:applying:)`. (Some further bikeshedding might be needed
> here—it's late and I'm tired.)
> >>
> >>
> >> I really don't want to see this discussion die as I have a vested
> interest in getting this functionality into
> >> Swift 3. So let me suggest that
> >>
> >> `sequence(_:, next:) -> AdHocSequence`
> >>
> >> might be a Swift acceptable solution.  We're not going to see
> fold/unfold pair happen. It's a given that
> >> `reduce` is a fixed point in Swift space and `sequence` well describes
> what this should be doing.
> >>
> >> So is it possible to push forward with `sequence`, whose only negative
> seems to be that it's not as well
> >> loved as `unfold`?
> >
> > I do like `sequence`, though I'm not sold on the name AdHocSequence
> (just from that name it's hard to figure out what it does). An alternative
> is `expand`, which is nice because it pairs with `reduce`, but it's less
> obvious that it produces a sequence and the name isn't as good with the
> stateful version.
> >
> > As for return type name, we could go ahead and use UnfoldSequence<T>
> anyway even though the function isn't named `unfold`, because this name
> will make sense to people who do know what unfold is, and I'm not convinced
> we can have a meaningful name for people who don't (since SequenceSequence
> is too silly).
> >
> > So given that, I'll suggest the following:
> >
> >   func sequence<T>(initial: T, next: T -> T?) -> UnfoldSequence<T>
> >   func sequence<T, State>(state: State, next: (inout State) -> T?) ->
> UnfoldSequence<T>
> >
> > I'm suggesting `sequence(initial:next:)` instead of the
> previously-suggested `sequence(from:applying:)` because the term "from"
> could equally well mean the first element or the state, whereas "initial"
> should make it more obvious that this value is the first element of the
> resulting sequence. And I'm using "next" as suggested by Erica because the
> function does return the next element, and it's similar to the
> IteratorProtocol method. I've also chosen to change the stateful version to
> use an inout parameter, as previously suggested, because it's equivalent to
> the State -> (T, State)? in functionality but is less likely to produce
> unwanted COW copies.
> >
> > -Kevin Ballard
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://lists.swift.org/pipermail/swift-evolution/attachments/20160514/760d1ed4/attachment.html
> >
>
> ------------------------------
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> End of swift-evolution Digest, Vol 6, Issue 45
> **********************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160514/6c406fec/attachment.html>