<div dir="ltr"><div><span style="font-size:12.8px">> </span><span style="font-size:12.8px">automatically cast rawValue when assigning an enum value to</span></div><span style="font-size:12.8px">a variable or argument of the type of the enum's raw value</span><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">There's a small miscommunication though--I've built api to accept the enum type. Signature:</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">static func fadeIn(view: UIView?, withSpeed: Animate.transitionSpeed = Animate.transitionSpeed.fast)</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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`.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">(unrelated: +1 on inferring type of function params with default values, I hit this all the time)</span><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Calling:</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Animate.fadeIn(myView, withSpeed: .slow)</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Works great.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><br><div><span style="font-size:12.8px"><br></span></div>------------------------------</span><br style="font-size:12.8px"><br style="font-size:12.8px"><span style="font-size:12.8px">Message: 31</span><br style="font-size:12.8px"><span style="font-size:12.8px">Date: Fri, 13 May 2016 16:58:06 -0300</span><br style="font-size:12.8px"><span style="font-size:12.8px">From: Leonardo Pessoa <</span><a href="mailto:me@lmpessoa.com" style="font-size:12.8px">me@lmpessoa.com</a><span style="font-size:12.8px">></span><br style="font-size:12.8px"><span style="font-size:12.8px">To: Swift-evolution <</span><a href="mailto:swift-evolution@swift.org" style="font-size:12.8px">swift-evolution@swift.org</a><span style="font-size:12.8px">></span><br style="font-size:12.8px"><span style="font-size:12.8px">Subject: Re: [swift-evolution] Could enums have their rawValue type</span><br style="font-size:12.8px"><span style="font-size:12.8px"> inferred?</span><br style="font-size:12.8px"><span style="font-size:12.8px">Message-ID:</span><br style="font-size:12.8px"><span style="font-size:12.8px"> <</span><a href="mailto:CANTOS57wksMRzUAMq0ncf1QAd82vhudf21tnea6wHjhBOFr1PA@mail.gmail.com" style="font-size:12.8px">CANTOS57wksMRzUAMq0ncf1QAd82vhudf21tnea6wHjhBOFr1PA@mail.gmail.com</a><span style="font-size:12.8px">></span><br style="font-size:12.8px"><span style="font-size:12.8px">Content-Type: text/plain; charset="utf-8"</span><br style="font-size:12.8px"><br style="font-size:12.8px"><span style="font-size:12.8px">Eric, I think I understood your proposal. If I may explain in other words</span><br style="font-size:12.8px"><span style="font-size:12.8px">it would be "to automatically cast rawValue when assigning an enum value to</span><br style="font-size:12.8px"><span style="font-size:12.8px">a variable or argument of the type of the enum's raw value", am I right? I</span><br style="font-size:12.8px"><span style="font-size:12.8px">think this would imply a little more inference and type checking rules from</span><br style="font-size:12.8px"><span style="font-size:12.8px">the compiler and maybe even take a little longer to fully compile code. I'm</span><br style="font-size:12.8px"><span style="font-size:12.8px">not sure it's feasible but from your examples, I can see how it enhances</span><br style="font-size:12.8px"><span style="font-size:12.8px">readability of the code, so I'm +1 for it. My only concern is that you</span><br style="font-size:12.8px"><span style="font-size:12.8px">would still need to fully declare the enum's name where the value of the</span><br style="font-size:12.8px"><span style="font-size:12.8px">enum is used. Taking from your own example</span><br style="font-size:12.8px"><br style="font-size:12.8px"><span style="font-size:12.8px"> Animate.fadeIn(view, withSpeed: .fast)</span><br style="font-size:12.8px"><br style="font-size:12.8px"><span style="font-size:12.8px">couldn't be called that way if withSpeed expects and NSTimeInterval because</span><br style="font-size:12.8px"><span style="font-size:12.8px">the compiler won't know whether you're refering to transitionSpeed or to</span><br style="font-size:12.8px"><span style="font-size:12.8px">ambientAnimationSpeed. You would still have to call it like</span><br style="font-size:12.8px"><br style="font-size:12.8px"><span style="font-size:12.8px"> Animate.fadeIn(view, withSpeed: transitionSpeed.fast)</span><br style="font-size:12.8px"><br style="font-size:12.8px"><span style="font-size:12.8px">even if you had only one possible enum value over all declared enums</span><br style="font-size:12.8px"><span style="font-size:12.8px">because that would still force the compiler to search for each value over</span><br style="font-size:12.8px"><span style="font-size:12.8px">all known enums to define where the value you're using comes from and make</span><br style="font-size:12.8px"><span style="font-size:12.8px">sure there are no two enums with the same value.</span><br style="font-size:12.8px"><br style="font-size:12.8px"><span style="font-size:12.8px">Aside from that, I good with the idea.</span><br style="font-size:12.8px"><br style="font-size:12.8px"><br style="font-size:12.8px"><br style="font-size:12.8px"><span style="font-size:12.8px">On 13 May 2016 at 15:09, Eric Miller via swift-evolution <</span><br style="font-size:12.8px"><a href="mailto:swift-evolution@swift.org" style="font-size:12.8px">swift-evolution@swift.org</a><span style="font-size:12.8px">> wrote:</span><br style="font-size:12.8px"><br style="font-size:12.8px"><span style="font-size:12.8px">> This might open a larger can of worms than I imagine, but what do you</span><br style="font-size:12.8px"><span style="font-size:12.8px">> folks think about using the `rawValue` of an enum when that rawValue is a</span><br style="font-size:12.8px"><span style="font-size:12.8px">> fit for the expected type?</span><br style="font-size:12.8px"><span style="font-size:12.8px">></span><br style="font-size:12.8px"><span style="font-size:12.8px">> Use case.</span><br style="font-size:12.8px"><span style="font-size:12.8px">></span><br style="font-size:12.8px"><span style="font-size:12.8px">> I'm making an animation facade, and it has some speed presets:</span><br style="font-size:12.8px"><span style="font-size:12.8px">></span><br style="font-size:12.8px"><span style="font-size:12.8px">> class Animate {</span><br style="font-size:12.8px"><span style="font-size:12.8px">> enum transitionSpeed: NSTimeInterval {</span><br style="font-size:12.8px"><span style="font-size:12.8px">> case fast = 0.15</span><br style="font-size:12.8px"><span style="font-size:12.8px">> case slow = 0.5</span><br style="font-size:12.8px"><span style="font-size:12.8px">> }</span><br style="font-size:12.8px"><span style="font-size:12.8px">> enum ambientAnimationSpeed: NSTimeInterval {</span><br style="font-size:12.8px"><span style="font-size:12.8px">> case fast = 1.0</span><br style="font-size:12.8px"><span style="font-size:12.8px">> case slow = 5.0</span><br style="font-size:12.8px"><span style="font-size:12.8px">> }</span><br style="font-size:12.8px"><span style="font-size:12.8px">> ...</span><br style="font-size:12.8px"><span style="font-size:12.8px">> }</span><br style="font-size:12.8px"><span style="font-size:12.8px">></span><br style="font-size:12.8px"><span style="font-size:12.8px">> I did them with static variables at first but that made the call site</span><br style="font-size:12.8px"><span style="font-size:12.8px">> verbose. Compare:</span><br style="font-size:12.8px"><span style="font-size:12.8px">></span><br style="font-size:12.8px"><span style="font-size:12.8px">> Animate.fadeIn(view, withSpeed: Animate.cfg.transitionFast)</span><br style="font-size:12.8px"><span style="font-size:12.8px">> Animate.fadeIn(view, withSpeed: .fast)</span><br style="font-size:12.8px"><span style="font-size:12.8px">></span><br style="font-size:12.8px"><span style="font-size:12.8px">> So, I like the enum approach better, but my library code has to use</span><br style="font-size:12.8px"><span style="font-size:12.8px">> `rawValue` to do anything with the actual value, of course:</span><br style="font-size:12.8px"><span style="font-size:12.8px">></span><br style="font-size:12.8px"><span style="font-size:12.8px">> static func fadeIn(view: UIView?, withSpeed duration:transitionSpeed =</span><br style="font-size:12.8px"><span style="font-size:12.8px">> .fast) {</span><br style="font-size:12.8px"><span style="font-size:12.8px">> ...</span><br style="font-size:12.8px"><span style="font-size:12.8px">> UIView.animateWithDuration(</span><span style="font-size:12.8px">duration.rawValue, animations: { })</span><br style="font-size:12.8px"><span style="font-size:12.8px">> }</span><br style="font-size:12.8px"><span style="font-size:12.8px">></span><br style="font-size:12.8px"><span style="font-size:12.8px">> It's not a serious issue, but the code is more clear and beautiful if it</span><br style="font-size:12.8px"><span style="font-size:12.8px">> has just myIntent, rather than myIntent.rawValue.</span><br style="font-size:12.8px"><span style="font-size:12.8px">></span><br style="font-size:12.8px"><span style="font-size:12.8px">> I've hit this issue when modeling other things, such as:</span><br style="font-size:12.8px"><span style="font-size:12.8px">></span><br style="font-size:12.8px"><span style="font-size:12.8px">> * server fault codes</span><br style="font-size:12.8px"><span style="font-size:12.8px">> * HTTP status codes</span><br style="font-size:12.8px"><span style="font-size:12.8px">> * Currency codes</span><br style="font-size:12.8px"><span style="font-size:12.8px">> * Days of the week</span><br style="font-size:12.8px"><span style="font-size:12.8px">></span><br style="font-size:12.8px"><span style="font-size:12.8px">> Would it be appropriate to "autocast" to the rawValue of the enum when the</span><br style="font-size:12.8px"><span style="font-size:12.8px">> rawValue's Type matches the type expectation of the API? Or would this</span><br style="font-size:12.8px"><span style="font-size:12.8px">> introduce a bunch of type system uncertainty?</span><br style="font-size:12.8px"><span style="font-size:12.8px">></span><br style="font-size:12.8px"><span style="font-size:12.8px">> Maybe this could be implemented as a protocol? It feels almost like the</span><br style="font-size:12.8px"><span style="font-size:12.8px">> convenience of `CustomStringConvertible`'s `description` property.</span><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 13, 2016 at 11:24 PM, <span dir="ltr"><<a href="mailto:swift-evolution-request@swift.org" target="_blank">swift-evolution-request@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Send swift-evolution mailing list submissions to<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:swift-evolution-request@swift.org">swift-evolution-request@swift.org</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:swift-evolution-owner@swift.org">swift-evolution-owner@swift.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of swift-evolution digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: [Pitch] merge types and protocols back together with<br>
type<Type, Protocol, ...> (Vladimir.S)<br>
2. Re: [Pitch] merge types and protocols back together with<br>
type<Type, Protocol, ...> (Vladimir.S)<br>
3. Re: [Pitch] merge types and protocols back together with<br>
type<Type, Protocol, ...> (Ross O'Brien)<br>
4. Re: Removing "_ in" from empty closures (Cole Campbell)<br>
5. Re: [Review] SE-0084: Allow trailing commas in parameter<br>
lists and tuples (Joe Groff)<br>
6. Re: [Pitch] merge types and protocols back together with<br>
type<Type, Protocol, ...> (Adrian Zubarev)<br>
7. Re: [Review] SE-0084: Allow trailing commas in parameter<br>
lists and tuples (Joe Groff)<br>
8. Re: [Review] SE-0084: Allow trailing commas in parameter<br>
lists and tuples (Vladimir.S)<br>
9. Re: [Review] SE-0084: Allow trailing commas in parameter<br>
lists and tuples (Erica Sadun)<br>
10. Re: [Pitch] merge types and protocols back together with<br>
type<Type, Protocol, ...> (Adrian Zubarev)<br>
11. Re: Removing "_ in" from empty closures (Erica Sadun)<br>
12. Re: [swift-evolution-announce] [Review] SE-0041: Updating<br>
Protocol Naming Conventions for Conversions (Pyry Jahkola)<br>
13. Could enums have their rawValue type inferred? (Eric Miller)<br>
14. Re: [Draft] Introducing StaticSelf, an Invariant Self<br>
(Nicola Salmoria)<br>
15. Re: [Review] SE-0045: Add scan, prefix(while:), drop(while:),<br>
and iterate to the stdlib (Erica Sadun)<br>
16. Re: [Review] SE-0075: Adding a Build Configuration Import<br>
Test (Pyry Jahkola)<br>
17. [draft-proposal] allow access to the underlying collection of<br>
a slice (Max Moiseev)<br>
18. Re: [Review] SE-0084: Allow trailing commas in parameter<br>
lists and tuples (Joe Groff)<br>
19. Interspersing guard let with guard boolean (Erica Sadun)<br>
20. Re: Interspersing guard let with guard boolean (Joe Groff)<br>
21. Re: Interspersing guard let with guard boolean (Erica Sadun)<br>
22. Re: [Pitch] merge types and protocols back together with<br>
type<Type, Protocol, ...> (Vladimir.S)<br>
23. Re: [Review] SE-0088: Modernize libdispatch for Swift 3<br>
naming conventions (Matt Wright)<br>
24. Re: [Draft] Introducing StaticSelf, an Invariant Self<br>
(Matthew Johnson)<br>
25. Re: [Review] SE-0045: Add scan, prefix(while:), drop(while:),<br>
and iterate to the stdlib (Kevin Ballard)<br>
26. Re: [Pitch] merge types and protocols back together with<br>
type<Type, Protocol, ...> (Adrian Zubarev)<br>
27. Re: [Review] SE-0088: Modernize libdispatch for Swift 3<br>
naming conventions (Jacob Bandes-Storch)<br>
28. Re: [Review] SE-0088: Modernize libdispatch for Swift 3<br>
naming conventions (Xiaodi Wu)<br>
29. Re: [Review] SE-0088: Modernize libdispatch for Swift 3<br>
naming conventions (Matt Wright)<br>
30. Re: [Review] SE-0088: Modernize libdispatch for Swift 3<br>
naming conventions (Matt Wright)<br>
31. Re: Could enums have their rawValue type inferred?<br>
(Leonardo Pessoa)<br>
32. Re: Removing "_ in" from empty closures (Jacob Bandes-Storch)<br>
33. Re: Removing "_ in" from empty closures (Matthew Johnson)<br>
34. Re: [Draft] Introducing StaticSelf, an Invariant Self (Joe Groff)<br>
35. Re: Removing "_ in" from empty closures (Joe Groff)<br>
36. Re: [Review] SE-0084: Allow trailing commas in parameter<br>
lists and tuples (John Siracusa)<br>
37. Re: [Pitch] merge types and protocols back together with<br>
type<Type, Protocol, ...> (Vladimir.S)<br>
38. Re: [Draft] Introducing StaticSelf, an Invariant Self (Vladimir.S)<br>
39. Re: Removing "_ in" from empty closures (Matthew Johnson)<br>
40. Re: [Review] SE-0088: Modernize libdispatch for Swift 3<br>
naming conventions (Matt Wright)<br>
41. Re: [Pitch] merge types and protocols back together with<br>
type<Type, Protocol, ...> (Adrian Zubarev)<br>
42. Re: [Pitch] merge types and protocols back together with<br>
type<Type, Protocol, ...> (Matthew Johnson)<br>
43. Re: [Draft] Introducing StaticSelf, an Invariant Self<br>
(Matthew Johnson)<br>
44. Re: [Pitch] merge types and protocols back together with<br>
type<Type, Protocol, ...> (Austin Zheng)<br>
45. Re: [Review] SE-0081: Move where clause to end of declaration<br>
(Jon Shier)<br>
46. Re: [Pitch] Consistent bridging for NSErrors at the language<br>
boundary (Jon Shier)<br>
47. Re: [Review] SE-0045: Add scan, prefix(while:), drop(while:),<br>
and iterate to the stdlib (Patrick Smith)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Fri, 13 May 2016 20:04:46 +0300<br>
From: "Vladimir.S" <<a href="mailto:svabox@gmail.com">svabox@gmail.com</a>><br>
To: Adrian Zubarev <<a href="mailto:adrian.zubarev@devandartist.com">adrian.zubarev@devandartist.com</a>><br>
Cc: swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>><br>
Subject: Re: [swift-evolution] [Pitch] merge types and protocols back<br>
together with type<Type, Protocol, ...><br>
Message-ID: <<a href="mailto:2f3fbb45-173f-15b4-492d-c059899d5482@gmail.com">2f3fbb45-173f-15b4-492d-c059899d5482@gmail.com</a>><br>
Content-Type: text/plain; charset=utf-8; format=flowed<br>
<br>
On 13.05.2016 19:38, Adrian Zubarev via swift-evolution wrote:<br>
> Why would you want to add all of these different formats where only one<br>
> could serve them all. This is redundant in my opinion.<br>
><br>
> `struct<>` and `enum<>` would have same rules, only the first element would<br>
> be a different value-type. I might consider this as an alternative.<br>
><br>
<br>
Actually, I fully support your idea and strongly +1 for `type<>` keyword. I<br>
don't believe it will confuse anyone as protocol<> does not confuse currently.<br>
<br>
But as I can see, the community(or core team) is strongly against of using<br>
`type` keyword.<br>
So, we have situation : protocol<> and .. all<> ? Will all<> include<br>
protocols also? Probably I'd support to remove protocol<> and introduce<br>
just all<> for all :-) But if we have protocol<> and can't have type<> - I<br>
asked why we can't for clarity and consistency have class<> struct<><br>
<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Fri, 13 May 2016 20:08:57 +0300<br>
From: "Vladimir.S" <<a href="mailto:svabox@gmail.com">svabox@gmail.com</a>><br>
To: Adrian Zubarev <<a href="mailto:adrian.zubarev@devandartist.com">adrian.zubarev@devandartist.com</a>><br>
Cc: swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>><br>
Subject: Re: [swift-evolution] [Pitch] merge types and protocols back<br>
together with type<Type, Protocol, ...><br>
Message-ID: <<a href="mailto:b8fdfea7-e174-718e-5b28-6ec373f1d8b4@gmail.com">b8fdfea7-e174-718e-5b28-6ec373f1d8b4@gmail.com</a>><br>
Content-Type: text/plain; charset=utf-8; format=flowed<br>
<br>
Btw, if we'd have separate class<> and struct<> - we'd be able to have<br>
method to separate reference type from value type.<br>
<br>
We can write now : print(c is protocol<>)<br>
<br>
and we'd can:<br>
<br>
print(c is class<>)<br>
print(c is struct<>)<br>
<br>
Just thoughts..<br>
<br>
On 13.05.2016 20:04, Vladimir.S wrote:<br>
> On 13.05.2016 19:38, Adrian Zubarev via swift-evolution wrote:<br>
>> Why would you want to add all of these different formats where only one<br>
>> could serve them all. This is redundant in my opinion.<br>
>><br>
>> `struct<>` and `enum<>` would have same rules, only the first element would<br>
>> be a different value-type. I might consider this as an alternative.<br>
>><br>
><br>
> Actually, I fully support your idea and strongly +1 for `type<>` keyword. I<br>
> don't believe it will confuse anyone as protocol<> does not confuse currently.<br>
><br>
> But as I can see, the community(or core team) is strongly against of using<br>
> `type` keyword.<br>
> So, we have situation : protocol<> and .. all<> ? Will all<> include<br>
> protocols also? Probably I'd support to remove protocol<> and introduce<br>
> just all<> for all :-) But if we have protocol<> and can't have type<> - I<br>
> asked why we can't for clarity and consistency have class<> struct<><br>
<br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Fri, 13 May 2016 18:11:11 +0100<br>
From: "Ross O'Brien" <<a href="mailto:narrativium%2Bswift@gmail.com">narrativium+swift@gmail.com</a>><br>
To: Adrian Zubarev <<a href="mailto:adrian.zubarev@devandartist.com">adrian.zubarev@devandartist.com</a>><br>
Cc: swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>><br>
Subject: Re: [swift-evolution] [Pitch] merge types and protocols back<br>
together with type<Type, Protocol, ...><br>
Message-ID:<br>
<<a href="mailto:CAPUwzK55PQYDT4j1UBS69KSo410xKWR3js9dY1W8cBsjJshU6g@mail.gmail.com">CAPUwzK55PQYDT4j1UBS69KSo410xKWR3js9dY1W8cBsjJshU6g@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
In reply to:<br>
<br>
Why would you want to add all of these different formats where only one<br>
could serve them all. This is redundant in my opinion.<br>
<br>
`struct<>` and `enum<>` would have same rules, only the first element would<br>
be a different value-type. I might consider this as an alternative.<br>
<br>
Correct me if I’m wrong with the redundancy.<br>
<br>
<br>
'enum<>' might be valid, unless their functions (e.g. for 'init(rawValue:<br>
Int)' or 'allCases') are declared in explicit protocols which would<br>
implicitly cover enums and which other types could declare conformance to.<br>
<br>
'struct<>' does seem redundant unless it becomes subtypeable. If you want a<br>
struct which conforms to several protocols, protocol<> already covers this.<br>
I know there's a discussion at the moment regarding the equivalent of an<br>
'AnyObject' for value types, which might apply to this discussion, but I'm<br>
not sure how.<br>
<br>
A class in general would also a protocol<AnyObject, ...>. The benefit of<br>
'type<>' is in its ability to extend the behaviours of several subclasses<br>
at once, e.g. type<UIViewController, UIScrollViewDelegate> covers all view<br>
controllers with scroll views, not just UITableViewController,<br>
UICollectionViewController, etc..<br>
<br>
<br>
<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/4ace2772/attachment-0001.html" rel="noreferrer" target="_blank">https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/4ace2772/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Fri, 13 May 2016 12:14:23 -0500<br>
From: Cole Campbell <<a href="mailto:cole.m.campbell@icloud.com">cole.m.campbell@icloud.com</a>><br>
To: Joe Groff <<a href="mailto:jgroff@apple.com">jgroff@apple.com</a>><br>
Cc: Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>><br>
Subject: Re: [swift-evolution] Removing "_ in" from empty closures<br>
Message-ID: <<a href="mailto:4FC7FC81-FDF2-471D-8C0E-DA5A037AA6D3@icloud.com">4FC7FC81-FDF2-471D-8C0E-DA5A037AA6D3@icloud.com</a>><br>
Content-Type: text/plain; charset=us-ascii<br>
<br>
<br>
> +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:<br>
><br>
> let _: () -> () = {}<br>
> let _: (Int) -> () = {}<br>
> let _: (Int, Int) -> Int = { 5 }<br>
> let _: (Int, Int) -> Int = { $0 }<br>
> let _: (Int, Int) -> Int = { $1 }<br>
<br>
+1. This would be excellent.<br>
<br>
------------------------------<br>
<br>
Message: 5<br>
Date: Fri, 13 May 2016 10:29:01 -0700<br>
From: Joe Groff <<a href="mailto:jgroff@apple.com">jgroff@apple.com</a>><br>
To: Erica Sadun <<a href="mailto:erica@ericasadun.com">erica@ericasadun.com</a>><br>
Cc: Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>><br>
Subject: Re: [swift-evolution] [Review] SE-0084: Allow trailing commas<br>
in parameter lists and tuples<br>
Message-ID: <<a href="mailto:304E28A1-D8D0-43A2-BF7A-FBAEF8828F6D@apple.com">304E28A1-D8D0-43A2-BF7A-FBAEF8828F6D@apple.com</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
<br>
> On May 13, 2016, at 7:04 AM, Erica Sadun <<a href="mailto:erica@ericasadun.com">erica@ericasadun.com</a>> wrote:<br>
><br>
> On May 12, 2016, at 11:01 PM, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
>> On May 12, 2016, at 4:50 PM, Joe Groff <<a href="mailto:jgroff@apple.com">jgroff@apple.com</a>> wrote:<br>
>>>> You’re arguing that you want to read Swift code written like this?<br>
>>><br>
>>> I wouldn't mind it.<br>
>><br>
>> 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.<br>
>><br>
><br>
> No. Tell us what you *really* think of the style. Don't hold back.[1]<br>
><br>
>> 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.<br>
><br>
> 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.<br>
<br>
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?<br>
<br>
-Joe<br>
<br>
------------------------------<br>
<br>
Message: 6<br>
Date: Fri, 13 May 2016 19:32:34 +0200<br>
From: Adrian Zubarev <<a href="mailto:adrian.zubarev@devandartist.com">adrian.zubarev@devandartist.com</a>><br>
To: <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
Subject: Re: [swift-evolution] [Pitch] merge types and protocols back<br>
together with type<Type, Protocol, ...><br>
Message-ID: <etPan.57360fb2.5ed02b43.6ab2@DevAndArtist.fritz.box><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
'struct<>' does seem redundant unless it becomes subtypeable. If you want a struct which conforms to several protocols, protocol<> already covers this.<br>
I think this is not correct. Lets check this example:<br>
<br>
func foo(value: SomeProtocol) {<br>
<br>
if let a = value as? struct<StructA, SomeProtocol> { /* do something with a */ }<br>
<br>
else if let b = value as? struct<StructB, SomeProtocol> { /* do something with b */ }<br>
<br>
}<br>
<br>
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.<br>
<br>
<br>
<br>
Btw, if we'd have separate class<> and struct<> - we'd be able to have method to separate reference type from value type. <br>
We can write now : print(c is protocol<>) <br>
and we'd can: <br>
print(c is class<>) <br>
print(c is struct<>) <br>
<br>
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.<br>
<br>
<br>
-- <br>
Adrian Zubarev<br>
Sent with Airmail<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/4a9f75e9/attachment-0001.html" rel="noreferrer" target="_blank">https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/4a9f75e9/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 7<br>
Date: Fri, 13 May 2016 10:32:34 -0700<br>
From: Joe Groff <<a href="mailto:jgroff@apple.com">jgroff@apple.com</a>><br>
To: Matthew Johnson <<a href="mailto:matthew@anandabits.com">matthew@anandabits.com</a>>, Matthew Johnson via<br>
swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>><br>
Subject: Re: [swift-evolution] [Review] SE-0084: Allow trailing commas<br>
in parameter lists and tuples<br>
Message-ID: <<a href="mailto:76E430C3-01EF-45B3-B00E-01490E75DCAA@apple.com">76E430C3-01EF-45B3-B00E-01490E75DCAA@apple.com</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
<br>
> On May 13, 2016, at 7:32 AM, Matthew Johnson via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
><br>
><br>
><br>
> Sent from my iPad<br>
><br>
>> On May 13, 2016, at 9:19 AM, Vladimir.S <<a href="mailto:svabox@gmail.com">svabox@gmail.com</a>> wrote:<br>
>><br>
>>> On 13.05.2016 16:32, Matthew Johnson wrote:<br>
>>> I am, +1 on allowing new lines instead of commas. I suggest you pursue a proposal on that.<br>
>><br>
>> 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.<br>
>><br>
>>><br>
>>> 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.<br>
>><br>
>> 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.<br>
><br>
> 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.<br>
>><br>
>> 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?<br>
><br>
> That feels like a separate proposal to me.<br>
<br>
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.<br>
<br>
-Joe<br>
<br>
>><br>
>> As I can see, the proposal SE-0084 'per se' has more negative comments than positive(even if some from @<a href="http://apple.com" rel="noreferrer" target="_blank">apple.com</a> supports it) and I feel like extended proposal can have more support.<br>
>><br>
>>><br>
>>> Sent from my iPad<br>
>>><br>
>>>> On May 13, 2016, at 1:24 AM, Vladimir.S via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
>>>><br>
>>>> IMO If we were *really* concerned about this, we should just allow line-break as separator in comma-separated lists.<br>
>>>><br>
>>>>> On 13.05.2016 8:01, Chris Lattner via swift-evolution wrote:<br>
>>>>> 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.<br>
>>>> _______________________________________________<br>
>>>> swift-evolution mailing list<br>
>>>> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
>>>> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
>>><br>
>>><br>
><br>
> _______________________________________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 8<br>
Date: Fri, 13 May 2016 20:42:10 +0300<br>
From: "Vladimir.S" <<a href="mailto:svabox@gmail.com">svabox@gmail.com</a>><br>
To: Joe Groff <<a href="mailto:jgroff@apple.com">jgroff@apple.com</a>><br>
Cc: swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>><br>
Subject: Re: [swift-evolution] [Review] SE-0084: Allow trailing commas<br>
in parameter lists and tuples<br>
Message-ID: <<a href="mailto:d487fba4-581b-2c76-145e-b7b79477b395@gmail.com">d487fba4-581b-2c76-145e-b7b79477b395@gmail.com</a>><br>
Content-Type: text/plain; charset=utf-8; format=flowed<br>
<br>
Support. *all or nothing* :-)<br>
<br>
On 13.05.2016 20:29, Joe Groff via swift-evolution wrote:<br>
> 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?<br>
<br>
<br>
------------------------------<br>
<br>
Message: 9<br>
Date: Fri, 13 May 2016 11:46:39 -0600<br>
From: Erica Sadun <<a href="mailto:erica@ericasadun.com">erica@ericasadun.com</a>><br>
To: Joe Groff <<a href="mailto:jgroff@apple.com">jgroff@apple.com</a>><br>
Cc: Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>><br>
Subject: Re: [swift-evolution] [Review] SE-0084: Allow trailing commas<br>
in parameter lists and tuples<br>
Message-ID: <<a href="mailto:A9ADA97C-DB1F-4556-A290-36BBE2357975@ericasadun.com">A9ADA97C-DB1F-4556-A290-36BBE2357975@ericasadun.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
<br>
> On May 13, 2016, at 11:29 AM, Joe Groff <<a href="mailto:jgroff@apple.com">jgroff@apple.com</a>> wrote:<br>
><br>
>><br>
>> On May 13, 2016, at 7:04 AM, Erica Sadun <<a href="mailto:erica@ericasadun.com">erica@ericasadun.com</a>> wrote:<br>
>><br>
>> On May 12, 2016, at 11:01 PM, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
>>> On May 12, 2016, at 4:50 PM, Joe Groff <<a href="mailto:jgroff@apple.com">jgroff@apple.com</a>> wrote:<br>
>>>>> You’re arguing that you want to read Swift code written like this?<br>
>>>><br>
>>>> I wouldn't mind it.<br>
>>><br>
>>> 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.<br>
>>><br>
>><br>
>> No. Tell us what you *really* think of the style. Don't hold back.[1]<br>
>><br>
>>> 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.<br>
>><br>
>> 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.<br>
><br>
> 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?<br>
><br>
> -Joe<br>
<br>
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.<br>
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<br>
commas, it's always at the ends of lines anyway.<br>
<br>
But since I don't want to undercut you, so I'd much prefer to step back and defer to your judgement on this.<br>
<br>
-- E<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/5fa7ba20/attachment-0001.html" rel="noreferrer" target="_blank">https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/5fa7ba20/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 10<br>
Date: Fri, 13 May 2016 19:50:38 +0200<br>
From: Adrian Zubarev <<a href="mailto:adrian.zubarev@devandartist.com">adrian.zubarev@devandartist.com</a>><br>
To: <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
Subject: Re: [swift-evolution] [Pitch] merge types and protocols back<br>
together with type<Type, Protocol, ...><br>
Message-ID: <etPan.573613ee.5477cc5d.6ab2@DevAndArtist.fritz.box><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
'struct<>' does seem redundant unless it becomes subtypeable. If you want a struct which conforms to several protocols, protocol<> already covers this.<br>
I think this is not correct. Lets check this example:<br>
<br>
func foo(value: SomeProtocol) {<br>
<br>
if let a = value as? struct<StructA, SomeProtocol> { /* do something with a */ }<br>
<br>
else if let b = value as? struct<StructB, SomeProtocol> { /* do something with b */ }<br>
<br>
}<br>
<br>
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.<br>
<br>
<br>
There is no need to include the protocol here. Just do this:<br>
<br>
if let a = value as? StructA { use a }<br>
<br>
Whoops, I forgot that this will do the trick. I apologize for any confusion here, you are totally right.<br>
<br>
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)?<br>
<br>
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.<br>
<br>
-- <br>
Adrian Zubarev<br>
Sent with Airmail<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/b51d2c61/attachment-0001.html" rel="noreferrer" target="_blank">https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/b51d2c61/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 11<br>
Date: Fri, 13 May 2016 11:48:30 -0600<br>
From: Erica Sadun <<a href="mailto:erica@ericasadun.com">erica@ericasadun.com</a>><br>
To: Cole Campbell <<a href="mailto:cole.m.campbell@icloud.com">cole.m.campbell@icloud.com</a>><br>
Cc: Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>><br>
Subject: Re: [swift-evolution] Removing "_ in" from empty closures<br>
Message-ID: <<a href="mailto:2F3D83D2-2785-4778-B7C1-91B0EF2381D1@ericasadun.com">2F3D83D2-2785-4778-B7C1-91B0EF2381D1@ericasadun.com</a>><br>
Content-Type: text/plain; charset=us-ascii<br>
<br>
On May 13, 2016, at 11:14 AM, Cole Campbell via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
><br>
><br>
>> +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:<br>
>><br>
>> let _: () -> () = {}<br>
>> let _: (Int) -> () = {}<br>
>> let _: (Int, Int) -> Int = { 5 }<br>
>> let _: (Int, Int) -> Int = { $0 }<br>
>> let _: (Int, Int) -> Int = { $1 }<br>
><br>
> +1. This would be excellent.<br>
<br>
+1. Good riddance to bad code baggage.<br>
<br>
-- E<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 12<br>
Date: Fri, 13 May 2016 21:03:19 +0300<br>
From: Pyry Jahkola <<a href="mailto:pyry.jahkola@iki.fi">pyry.jahkola@iki.fi</a>><br>
To: Matthew Johnson <<a href="mailto:matthew@anandabits.com">matthew@anandabits.com</a>><br>
Cc: <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
Subject: Re: [swift-evolution] [swift-evolution-announce] [Review]<br>
SE-0041: Updating Protocol Naming Conventions for Conversions<br>
Message-ID: <<a href="mailto:1AAA5C78-073C-4515-80E6-AC64888FC725@iki.fi">1AAA5C78-073C-4515-80E6-AC64888FC725@iki.fi</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Taking the suggested changes into account, here's my review.<br>
<br>
1) +1, I think this is a reasonable way for naming this family of protocols.<br>
<br>
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.<br>
<br>
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.<br>
<br>
4) Quick reading.<br>
<br>
— Pyry<br>
<br>
> On 13 May 2016, Matthew Johnson wrote:<br>
><br>
> While the community feedback on our SE-0041 proposal "Updating Protocol Naming Conventions for Conversions" (<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md" rel="noreferrer" target="_blank">https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md</a> <<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md" rel="noreferrer" target="_blank">https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md</a>>) 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.<br>
><br>
> 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.<br>
><br>
> UPDATED APPROACH<br>
><br>
> Our updated approach focuses on the two most important conventions: one for initialization and one for representation.<br>
><br>
> 1. `Initializable`<br>
><br>
> `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.<br>
><br>
> For example, conforming to `ArrayLiteralInitializable` would allow a set to be created with `Set(arrayLiteral: <some array>)` and `var set: Set<T> = []`.<br>
><br>
> This phrase replaces the `Creatable` form from our original proposal.<br>
><br>
> 2. `Representable`<br>
><br>
> `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`.<br>
><br>
> 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.<br>
><br>
> FUTURE DIRECTIONS<br>
><br>
> 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.<br>
><br>
> Sent from my iPad<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/b88c8136/attachment-0001.html" rel="noreferrer" target="_blank">https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/b88c8136/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 13<br>
Date: Fri, 13 May 2016 12:09:01 -0600<br>
From: Eric Miller <<a href="mailto:hi@simple.gy">hi@simple.gy</a>><br>
To: <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
Subject: [swift-evolution] Could enums have their rawValue type<br>
inferred?<br>
Message-ID:<br>
<CAJaDgbjTQMo8keEa=<a href="mailto:4%2BneJp_yPgRpi3rdsSnrAMmwJbonLQEKQ@mail.gmail.com">4+neJp_yPgRpi3rdsSnrAMmwJbonLQEKQ@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
This might open a larger can of worms than I imagine, but what do you folks<br>
think about using the `rawValue` of an enum when that rawValue is a fit for<br>
the expected type?<br>
<br>
Use case.<br>
<br>
I'm making an animation facade, and it has some speed presets:<br>
<br>
class Animate {<br>
enum transitionSpeed: NSTimeInterval {<br>
case fast = 0.15<br>
case slow = 0.5<br>
}<br>
enum ambientAnimationSpeed: NSTimeInterval {<br>
case fast = 1.0<br>
case slow = 5.0<br>
}<br>
...<br>
}<br>
<br>
I did them with static variables at first but that made the call site<br>
verbose. Compare:<br>
<br>
Animate.fadeIn(view, withSpeed: Animate.cfg.transitionFast)<br>
Animate.fadeIn(view, withSpeed: .fast)<br>
<br>
So, I like the enum approach better, but my library code has to use<br>
`rawValue` to do anything with the actual value, of course:<br>
<br>
static func fadeIn(view: UIView?, withSpeed duration:transitionSpeed =<br>
.fast) {<br>
...<br>
UIView.animateWithDuration(duration.rawValue, animations: { })<br>
}<br>
<br>
It's not a serious issue, but the code is more clear and beautiful if it<br>
has just myIntent, rather than myIntent.rawValue.<br>
<br>
I've hit this issue when modeling other things, such as:<br>
<br>
* server fault codes<br>
* HTTP status codes<br>
* Currency codes<br>
* Days of the week<br>
<br>
Would it be appropriate to "autocast" to the rawValue of the enum when the<br>
rawValue's Type matches the type expectation of the API? Or would this<br>
introduce a bunch of type system uncertainty?<br>
<br>
Maybe this could be implemented as a protocol? It feels almost like the<br>
convenience of `CustomStringConvertible`'s `description` property.<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/c7c83773/attachment-0001.html" rel="noreferrer" target="_blank">https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/c7c83773/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 14<br>
Date: Fri, 13 May 2016 20:11:12 +0200<br>
From: Nicola Salmoria <<a href="mailto:nicola.salmoria@gmail.com">nicola.salmoria@gmail.com</a>><br>
To: "Vladimir.S" <<a href="mailto:svabox@gmail.com">svabox@gmail.com</a>><br>
Cc: swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>><br>
Subject: Re: [swift-evolution] [Draft] Introducing StaticSelf, an<br>
Invariant Self<br>
Message-ID:<br>
<CAMZYVZgE+gLH4w=xOaLa6DDP3KW3S6rggU8V5W=<a href="mailto:Ts93izu6T8g@mail.gmail.com">Ts93izu6T8g@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
On Fri, May 13, 2016 at 12:55 PM, Vladimir.S <<a href="mailto:svabox@gmail.com">svabox@gmail.com</a>> wrote:<br>
<br>
> > I'm not convinced by this example.<br>
><br>
> Probably my & Matthew's previous discussion in `[swift-evolution] [RFC]<br>
> #Self` topic will help you. I was trying there to find out (in primitive<br>
> examples) what Matthew is trying to achive with this `->StaticSelf` in<br>
> protocol.<br>
><br>
> In two words - he wants to achieve requirement 'return Self class or any<br>
> of base classes', as current `->Self` requires 'strictly return Self class'<br>
><br>
<br>
I think I understand what the request is, but I'm not sure if it's a<br>
problem worth solving, and if this would be the right solution.<br>
<br>
Going back to the example, let's say you have the requested<br>
<br>
protocol Fooable {<br>
func foo() -> StaticSelf<br>
}<br>
<br>
class A: Fooable {<br>
func foo() -> A { return A() }<br>
}<br>
<br>
class B: A {<br>
}<br>
<br>
How would you use foo() in generic code?<br>
<br>
func bar<T: Fooable>(_ x: T) -> X {<br>
return x.foo()<br>
}<br>
<br>
What does bar() return? What do you put in place of X in its declaration?<br>
You can't use T, you can't use T.StaticSelf. So what's the purpose of<br>
having a protocol if you can't use it in generic code?<br>
<br>
<br>
Nicola<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/f33b31ad/attachment-0001.html" rel="noreferrer" target="_blank">https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/f33b31ad/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 15<br>
Date: Fri, 13 May 2016 12:08:22 -0600<br>
From: Erica Sadun <<a href="mailto:erica@ericasadun.com">erica@ericasadun.com</a>><br>
To: Brent Royal-Gordon <<a href="mailto:brent@architechies.com">brent@architechies.com</a>>, Chris Lattner<br>
<<a href="mailto:clattner@apple.com">clattner@apple.com</a>><br>
Cc: <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
Subject: Re: [swift-evolution] [Review] SE-0045: Add scan,<br>
prefix(while:), drop(while:), and iterate to the stdlib<br>
Message-ID: <<a href="mailto:1FC733A8-6BE7-45A0-9579-841AE52B5BA9@ericasadun.com">1FC733A8-6BE7-45A0-9579-841AE52B5BA9@ericasadun.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
On May 1, 2016, at 5:13 AM, Brent Royal-Gordon via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
><br>
>> The proposal has been updated as per feedback from the core team (<a href="https://github.com/apple/swift-evolution/pull/275" rel="noreferrer" target="_blank">https://github.com/apple/swift-evolution/pull/275</a>). This includes removing some last vestiges of Swift 2 naming as well as replacing `iterate(_:apply:)` with an overloaded function `unfold(_:applying:)`.<br>
><br>
> The proposal says this:<br>
><br>
> public func unfold<T, State>(_ initialState: State, applying: State -> (T, State)?) -> UnfoldSequence<T><br>
> public func unfold<T>(_ initialElement: T, apply: T -> T) -> UnfoldSequence<T><br>
><br>
> However, the comment implies that the second one should instead be this:<br>
><br>
> public func unfold<T>(_ initialElement: T, applying: T -> T?) -> UnfoldSequence<T><br>
><br>
> 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?<br>
><br>
> public func unfold<T, State>(fromState initialState: State, applying: State -> (T, State)?) -> UnfoldSequence<T><br>
> public func unfold<T>(fromFirst initialElement: T, apply: T -> T) -> UnfoldSequence<T><br>
><br>
> 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.)<br>
<br>
I really don't want to see this discussion die as I have a vested interest in getting this functionality into<br>
Swift 3. So let me suggest that<br>
<br>
`sequence(_:, next:) -> AdHocSequence`<br>
<br>
might be a Swift acceptable solution. We're not going to see fold/unfold pair happen. It's a given that<br>
`reduce` is a fixed point in Swift space and `sequence` well describes what this should be doing.<br>
<br>
So is it possible to push forward with `sequence`, whose only negative seems to be that it's not as well<br>
loved as `unfold`?<br>
<br>
-- Erica<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/07e13f7a/attachment-0001.html" rel="noreferrer" target="_blank">https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/07e13f7a/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 16<br>
Date: Fri, 13 May 2016 21:16:03 +0300<br>
From: Pyry Jahkola <<a href="mailto:pyry.jahkola@iki.fi">pyry.jahkola@iki.fi</a>><br>
To: Erica Sadun <<a href="mailto:erica@ericasadun.com">erica@ericasadun.com</a>><br>
Cc: swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>><br>
Subject: Re: [swift-evolution] [Review] SE-0075: Adding a Build<br>
Configuration Import Test<br>
Message-ID: <<a href="mailto:95C947FC-C523-41C3-A385-44AFC469124E@iki.fi">95C947FC-C523-41C3-A385-44AFC469124E@iki.fi</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
> On 13 May 2016, Erica Sadun wrote:<br>
><br>
>> As per Pyry’s feedback, you could add a version:<br>
>><br>
>> #if import Frobnication(<1.7.3) // <- Only added version constraint here.<br>
>> extension Knob : Frobnicatable { ... }<br>
>> #endif<br>
><br>
> 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".<br>
<br>
I already gave my +1 on the original proposal and if `canImport` is indeed easiest to implement we should get it going now.<br>
<br>
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.<br>
<br>
> p.s. Also on my Swift Bucket list: "import as".<br>
<br>
Splendid! I'd already forgotten about qualified imports and renaming! Those would be welcome additions too.<br>
<br>
— Pyry<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/9e170f04/attachment-0001.html" rel="noreferrer" target="_blank">https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/9e170f04/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 17<br>
Date: Fri, 13 May 2016 11:19:08 -0700<br>
From: Max Moiseev <<a href="mailto:moiseev@apple.com">moiseev@apple.com</a>><br>
To: <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
Subject: [swift-evolution] [draft-proposal] allow access to the<br>
underlying collection of a slice<br>
Message-ID: <<a href="mailto:D32AAB4D-D21D-428D-AE52-BF0566DD825D@apple.com">D32AAB4D-D21D-428D-AE52-BF0566DD825D@apple.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi everyone!<br>
<br>
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.<br>
<br>
Max<br>
<br>
Adding a public base property to slices<br>
<br>
Proposal: SE-NNNN<br>
Author(s): Max Moiseev <<a href="https://github.com/moiseev" rel="noreferrer" target="_blank">https://github.com/moiseev</a>><br>
Status: Awaiting review<br>
Review manager: TBD<br>
Introduction<br>
<br>
Slice types provided by the standard library <<a href="https://github.com/apple/swift/blob/master/stdlib/public/core/Slice.swift.gyb" rel="noreferrer" target="_blank">https://github.com/apple/swift/blob/master/stdlib/public/core/Slice.swift.gyb</a>> should allow public readonly access to their base collections to make efficient implementations of protocol requirements possible in conforming types.<br>
<br>
Motivation<br>
<br>
The MutableCollection protocol conformance requires providing an implementation of the following subscript:<br>
<br>
subscript(bounds: Range<Index>) -> SubSequence { get set }<br>
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 <<a href="https://github.com/apple/swift/blob/master/stdlib/public/core/WriteBackMutableSlice.swift" rel="noreferrer" target="_blank">https://github.com/apple/swift/blob/master/stdlib/public/core/WriteBackMutableSlice.swift</a>> 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.<br>
<br>
Proposed solution<br>
<br>
We propose to export a public readonly property base, that will enable optimizations mentioned above. Here is how MutableRandomAccessSlice definition would look like:<br>
<br>
public struct MutableRandomAccessSlice<<br>
Base : protocol<RandomAccessIndexable, MutableIndexable><br>
> : RandomAccessCollection, MutableCollection {<br>
<br>
/// The underlying collection of the slice<br>
public var base: Base { get }<br>
}<br>
The same change is applicable to both mutable and immutable slice types.<br>
<br>
Impact on existing code<br>
<br>
The proposed change is purely additive and does not affect existing code.<br>
<br>
Alternatives considered<br>
<br>
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.<br>
<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/13768551/attachment-0001.html" rel="noreferrer" target="_blank">https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/13768551/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 18<br>
Date: Fri, 13 May 2016 11:19:23 -0700<br>
From: Joe Groff <<a href="mailto:jgroff@apple.com">jgroff@apple.com</a>><br>
To: Erica Sadun <<a href="mailto:erica@ericasadun.com">erica@ericasadun.com</a>><br>
Cc: Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>><br>
Subject: Re: [swift-evolution] [Review] SE-0084: Allow trailing commas<br>
in parameter lists and tuples<br>
Message-ID: <<a href="mailto:B61AB4F9-B20C-4B6E-A205-9D465ABB2C2A@apple.com">B61AB4F9-B20C-4B6E-A205-9D465ABB2C2A@apple.com</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
<br>
> On May 13, 2016, at 10:46 AM, Erica Sadun <<a href="mailto:erica@ericasadun.com">erica@ericasadun.com</a>> wrote:<br>
><br>
><br>
>> On May 13, 2016, at 11:29 AM, Joe Groff <<a href="mailto:jgroff@apple.com">jgroff@apple.com</a>> wrote:<br>
>><br>
>>><br>
>>> On May 13, 2016, at 7:04 AM, Erica Sadun <<a href="mailto:erica@ericasadun.com">erica@ericasadun.com</a>> wrote:<br>
>>><br>
>>> On May 12, 2016, at 11:01 PM, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
>>>> On May 12, 2016, at 4:50 PM, Joe Groff <<a href="mailto:jgroff@apple.com">jgroff@apple.com</a>> wrote:<br>
>>>>>> You’re arguing that you want to read Swift code written like this?<br>
>>>>><br>
>>>>> I wouldn't mind it.<br>
>>>><br>
>>>> 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.<br>
>>>><br>
>>><br>
>>> No. Tell us what you *really* think of the style. Don't hold back.[1]<br>
>>><br>
>>>> 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.<br>
>>><br>
>>> 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.<br>
>><br>
>> 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?<br>
>><br>
>> -Joe<br>
><br>
> 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.<br>
<br>
Sorry, I replied to you, but my comments were more directed toward Chris.<br>
<br>
-Joe<br>
<br>
------------------------------<br>
<br>
Message: 19<br>
Date: Fri, 13 May 2016 12:15:38 -0600<br>
From: Erica Sadun <<a href="mailto:erica@ericasadun.com">erica@ericasadun.com</a>><br>
To: Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>>,<br>
<a href="mailto:alex@kempgen.de">alex@kempgen.de</a><br>
Subject: [swift-evolution] Interspersing guard let with guard boolean<br>
Message-ID: <<a href="mailto:A0645FEA-B666-4E3D-8DDC-8406CE86E813@ericasadun.com">A0645FEA-B666-4E3D-8DDC-8406CE86E813@ericasadun.com</a>><br>
Content-Type: text/plain; charset=us-ascii<br>
<br>
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?<br>
<br>
Thanks, -- E<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 20<br>
Date: Fri, 13 May 2016 11:23:44 -0700<br>
From: Joe Groff <<a href="mailto:jgroff@apple.com">jgroff@apple.com</a>><br>
To: Erica Sadun <<a href="mailto:erica@ericasadun.com">erica@ericasadun.com</a>><br>
Cc: Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>>,<br>
<a href="mailto:alex@kempgen.de">alex@kempgen.de</a><br>
Subject: Re: [swift-evolution] Interspersing guard let with guard<br>
boolean<br>
Message-ID: <<a href="mailto:2F004069-682D-4C14-B9C4-158ACA735D0F@apple.com">2F004069-682D-4C14-B9C4-158ACA735D0F@apple.com</a>><br>
Content-Type: text/plain; charset=us-ascii<br>
<br>
<br>
> On May 13, 2016, at 11:15 AM, Erica Sadun via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
><br>
> 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?<br>
<br>
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:<br>
<br>
guard x == 0,<br>
let y = optional where<br>
z == 2 {<br>
}<br>
<br>
There's no technical reason we couldn't accept either 'where' or ',' consistently.<br>
<br>
-Joe<br>
<br>
------------------------------<br>
<br>
Message: 21<br>
Date: Fri, 13 May 2016 12:27:16 -0600<br>
From: Erica Sadun <<a href="mailto:erica@ericasadun.com">erica@ericasadun.com</a>><br>
To: Joe Groff <<a href="mailto:jgroff@apple.com">jgroff@apple.com</a>>, <a href="mailto:mike@mikeash.com">mike@mikeash.com</a><br>
Cc: Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>>,<br>
<a href="mailto:alex@kempgen.de">alex@kempgen.de</a><br>
Subject: Re: [swift-evolution] Interspersing guard let with guard<br>
boolean<br>
Message-ID: <<a href="mailto:9E13E3A9-3FAC-4D14-B3E6-B0D4054069B0@ericasadun.com">9E13E3A9-3FAC-4D14-B3E6-B0D4054069B0@ericasadun.com</a>><br>
Content-Type: text/plain; charset=us-ascii<br>
<br>
<br>
> On May 13, 2016, at 12:23 PM, Joe Groff <<a href="mailto:jgroff@apple.com">jgroff@apple.com</a>> wrote:<br>
><br>
><br>
>> On May 13, 2016, at 11:15 AM, Erica Sadun via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
>><br>
>> 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?<br>
><br>
> 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:<br>
><br>
> guard x == 0,<br>
> let y = optional where<br>
> z == 2 {<br>
> }<br>
><br>
> There's no technical reason we couldn't accept either 'where' or ',' consistently.<br>
><br>
> -Joe<br>
<br>
Is it worth a proposal to allow both, for when the where clauses don't have to be semantically tied to the conditional binding?<br>
<br>
-- E<br>
<br>
/ccing in Mike Ash so he can gloat<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 22<br>
Date: Fri, 13 May 2016 21:34:58 +0300<br>
From: "Vladimir.S" <<a href="mailto:svabox@gmail.com">svabox@gmail.com</a>><br>
To: Adrian Zubarev <<a href="mailto:adrian.zubarev@devandartist.com">adrian.zubarev@devandartist.com</a>><br>
Cc: swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>><br>
Subject: Re: [swift-evolution] [Pitch] merge types and protocols back<br>
together with type<Type, Protocol, ...><br>
Message-ID: <<a href="mailto:66427699-ae82-5140-ac5f-7f97ce14cc4a@gmail.com">66427699-ae82-5140-ac5f-7f97ce14cc4a@gmail.com</a>><br>
Content-Type: text/plain; charset=utf-8; format=flowed<br>
<br>
Hmm..<br>
<br>
What about such synthetic scenario:<br>
<br>
at the moment of writing our code we have:<br>
<br>
public protocol MyProtocol {<br>
func foo()<br>
}<br>
<br>
public struct StructA:MyProtocol {<br>
func foo()<br>
}<br>
<br>
public struct StructB:MyProtocol {<br>
func foo()<br>
}<br>
<br>
and have<br>
<br>
public protocol ExtraProtocol1 {<br>
func bar()<br>
}<br>
<br>
public protocol ExtraProtocol2 {<br>
func blort()<br>
}<br>
<br>
then we actually can have such code:<br>
<br>
func f(p: MyProtocol) {<br>
if let a = p as? struct<StructA, ExtraProtocol1> {<br>
a.foo()<br>
a.bar()<br>
}<br>
else<br>
if let b = p as? struct<StructB, ExtraProtocol2> {<br>
b.foo()<br>
b.blort()<br>
}<br>
}<br>
<br>
as we can(as example) expect that in 3rd party code someone will do:<br>
<br>
extension StructA: ExtraProtocol1 {<br>
func bar() {}<br>
}<br>
<br>
extension StructB: ExtraProtocol2 {<br>
func blort() {}<br>
}<br>
<br>
<br>
<br>
On 13.05.2016 20:50, Adrian Zubarev via swift-evolution wrote:<br>
>> 'struct<>' does seem redundant unless it becomes subtypeable. If<br>
>> you want a struct which conforms to several protocols, protocol<><br>
>> already covers this.<br>
>><br>
>> I think this is not correct. Lets check this example:<br>
>><br>
>> func foo(value: SomeProtocol) {<br>
>><br>
>> if let a = value as? struct<StructA, SomeProtocol> { /* do<br>
>> something with a */ }<br>
>><br>
>> else if let b = value as? struct<StructB, SomeProtocol> { /* do<br>
>> something with b */ }<br>
>><br>
>> }<br>
>><br>
>> In this scenario you’ll be able to access properties and functions<br>
>> from `StructA` or `StructB` which might not be covered by<br>
>> `SomeProtocol`. Everything is merged nicely into one instance. But<br>
>> you are right it depends on the use-case.<br>
>><br>
>><br>
>> There is no need to include the protocol here. Just do this:<br>
>><br>
>> if let a = value as? StructA { use a }<br>
>><br>
> Whoops, I forgot that this will do the trick. I apologize for any confusion<br>
> here, you are totally right.<br>
><br>
> That been said, do we really need `type<>` aka. `all<>` for value types? I<br>
> need to rethink this part of the proposal. Is there any use-case where we<br>
> would need this (any scenario for the future Swift version also counts)?<br>
><br>
> If we had `all<>` in Swift already for extendable reference types and one<br>
> day structs would become subtypeable, this wouldn’t be a huge problem to<br>
> upgrade `all<>` for structs I guess.<br>
><br>
> --<br>
> Adrian Zubarev<br>
> Sent with Airmail<br>
><br>
><br>
><br>
> _______________________________________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
><br>
<br>
<br>
------------------------------<br>
<br>
Message: 23<br>
Date: Fri, 13 May 2016 11:36:55 -0700<br>
From: Matt Wright <<a href="mailto:mww@apple.com">mww@apple.com</a>><br>
To: swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>><br>
Subject: Re: [swift-evolution] [Review] SE-0088: Modernize libdispatch<br>
for Swift 3 naming conventions<br>
Message-ID: <<a href="mailto:178CA219-60D2-4A43-96F3-86BA02DB7CBA@apple.com">178CA219-60D2-4A43-96F3-86BA02DB7CBA@apple.com</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
[Apologies for the weird threading, I missed the original email to the list so I can’t reply to it directly]<br>
<br>
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.<br>
<br>
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.<br>
<br>
Thanks again for your continued feedback,<br>
Matt<br>
<br>
> On Tue, May 10, 2016 at 9:39 PM, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
> Hello Swift community,<br>
><br>
> The review of "SE-0088: Modernize libdispatch for Swift 3 naming conventions" begins now and runs through May 17. The proposal is available here:<br>
><br>
> <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0088-libdispatch-for-swift3.md" rel="noreferrer" target="_blank">https://github.com/apple/swift-evolution/blob/master/proposals/0088-libdispatch-for-swift3.md</a><br>
><br>
> Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at<br>
><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
><br>
> or, if you would like to keep your feedback private, directly to the review manager.<br>
><br>
> What goes into a review?<br>
><br>
> 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:<br>
><br>
> * What is your evaluation of the proposal?<br>
> * Is the problem being addressed significant enough to warrant a change to Swift?<br>
> * Does this proposal fit well with the feel and direction of Swift?<br>
> * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?<br>
> * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?<br>
><br>
> More information about the Swift evolution process is available at<br>
><br>
> <a href="https://github.com/apple/swift-evolution/blob/master/process.md" rel="noreferrer" target="_blank">https://github.com/apple/swift-evolution/blob/master/process.md</a><br>
><br>
> Thank you,<br>
><br>
> -Chris Lattner<br>
> Review Manager<br>
><br>
><br>
><br>
> _______________________________________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
><br>
> _______________________________________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 24<br>
Date: Fri, 13 May 2016 14:06:23 -0500<br>
From: Matthew Johnson <<a href="mailto:matthew@anandabits.com">matthew@anandabits.com</a>><br>
To: Nicola Salmoria <<a href="mailto:nicola.salmoria@gmail.com">nicola.salmoria@gmail.com</a>><br>
Cc: swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>><br>
Subject: Re: [swift-evolution] [Draft] Introducing StaticSelf, an<br>
Invariant Self<br>
Message-ID: <<a href="mailto:6A1CC61D-1AB6-48C9-88E8-210DB4B85C89@anandabits.com">6A1CC61D-1AB6-48C9-88E8-210DB4B85C89@anandabits.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
<br>
> On May 13, 2016, at 1:11 PM, Nicola Salmoria via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
><br>
><br>
><br>
> On Fri, May 13, 2016 at 12:55 PM, Vladimir.S <<a href="mailto:svabox@gmail.com">svabox@gmail.com</a> <mailto:<a href="mailto:svabox@gmail.com">svabox@gmail.com</a>>> wrote:<br>
> > I'm not convinced by this example.<br>
><br>
> 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.<br>
><br>
> In two words - he wants to achieve requirement 'return Self class or any of base classes', as current `->Self` requires 'strictly return Self class'<br>
><br>
> 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.<br>
><br>
> Going back to the example, let's say you have the requested<br>
><br>
> protocol Fooable {<br>
> func foo() -> StaticSelf<br>
> }<br>
><br>
> class A: Fooable {<br>
> func foo() -> A { return A() }<br>
> }<br>
><br>
> class B: A {<br>
> }<br>
><br>
> How would you use foo() in generic code?<br>
><br>
> func bar<T: Fooable>(_ x: T) -> X {<br>
> return x.foo()<br>
> }<br>
><br>
> What does bar() return? What do you put in place of X in its declaration?<br>
> 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?<br>
<br>
This is a good question. Thank you very much for providing a concrete example along with the question.<br>
<br>
Let’s look at an example of what some of us have in mind:<br>
<br>
protocol StringCreatable {<br>
static func createWithString(s: String) -> StaticSelf<br>
}<br>
<br>
extension NSURL: StringCreatable {<br>
static func createWithString(s: String) -> StaticSelf {<br>
// ...<br>
}<br>
}<br>
<br>
func foo<Result: StringCreatable>(s: String) -> Result {<br>
return Result.createWithString(s: s)<br>
}<br>
<br>
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:<br>
<br>
protocol StringCreatable {<br>
typealias ConformingType = StaticSelf<br>
static func createWithString(s: String) -> StaticSelf<br>
}<br>
<br>
func foo<Result: StringCreatable where Result.ConformingType == Result>(s: String) -> Result {<br>
return Result.createWithString(s: s)<br>
}<br>
<br>
This requires same type constraints. I believe that is coming as part of “completing generics”.<br>
<br>
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.<br>
<br>
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?<br>
<br>
-Matthew<br>
<br>
<br>
><br>
><br>
> Nicola<br>
><br>
> _______________________________________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/faddc0a1/attachment-0001.html" rel="noreferrer" target="_blank">https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/faddc0a1/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 25<br>
Date: Fri, 13 May 2016 12:07:29 -0700<br>
From: Kevin Ballard <<a href="mailto:kevin@sb.org">kevin@sb.org</a>><br>
To: Erica Sadun <<a href="mailto:erica@ericasadun.com">erica@ericasadun.com</a>>, "Brent Royal-Gordon"<br>
<<a href="mailto:brent@architechies.com">brent@architechies.com</a>>, Chris Lattner <<a href="mailto:clattner@apple.com">clattner@apple.com</a>><br>
Cc: <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
Subject: Re: [swift-evolution] [Review] SE-0045: Add scan,<br>
prefix(while:), drop(while:), and iterate to the stdlib<br>
Message-ID:<br>
<<a href="mailto:1463166449.928503.607214225.00CC8144@webmail.messagingengine.com">1463166449.928503.607214225.00CC8144@webmail.messagingengine.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
On Fri, May 13, 2016, at 11:08 AM, Erica Sadun wrote:<br>
> On May 1, 2016, at 5:13 AM, Brent Royal-Gordon via swift-evolution <swift-<br>
> <a href="mailto:evolution@swift.org">evolution@swift.org</a>> wrote:<br>
>><br>
>>> The proposal has been updated as per feedback from the core team<br>
>>> (<a href="https://github.com/apple/swift-evolution/pull/275" rel="noreferrer" target="_blank">https://github.com/apple/swift-evolution/pull/275</a>). This includes<br>
>>> removing some last vestiges of Swift 2 naming as well as replacing<br>
>>> `iterate(_:apply:)` with an overloaded function<br>
>>> `unfold(_:applying:)`.<br>
>><br>
>> The proposal says this:<br>
>><br>
>> public func unfold<T, State>(_ initialState: State, applying: State<br>
>> -> (T, State)?) -> UnfoldSequence<T><br>
>> public func unfold<T>(_ initialElement: T, apply: T -> T) -><br>
>> UnfoldSequence<T><br>
>><br>
>> However, the comment implies that the second one should instead<br>
>> be this:<br>
>><br>
>> public func unfold<T>(_ initialElement: T, applying: T -> T?) -><br>
>> UnfoldSequence<T><br>
>><br>
>> I'm not sure I like having these be overloaded on only the return<br>
>> type of the closure. Maybe we could do something like this?<br>
>><br>
>> public func unfold<T, State>(fromState initialState: State,<br>
>> applying: State -> (T, State)?) -> UnfoldSequence<T><br>
>> public func unfold<T>(fromFirst initialElement: T, apply: T -> T) -><br>
>> UnfoldSequence<T><br>
>><br>
>> That way you're calling either `unfold(fromState:applying:)` or<br>
>> `unfold(fromFirst:applying:)`. (Some further bikeshedding might be<br>
>> needed here—it's late and I'm tired.)<br>
><br>
> I really don't want to see this discussion die as I have a vested<br>
> interest in getting this functionality into<br>
> Swift 3. So let me suggest that<br>
><br>
> `sequence(_:, next:) -> AdHocSequence`<br>
><br>
> might be a Swift acceptable solution. We're not going to see<br>
> fold/unfold pair happen. It's a given that<br>
> `reduce` is a fixed point in Swift space and `sequence` well describes<br>
> what this should be doing.<br>
><br>
> So is it possible to push forward with `sequence`, whose only negative<br>
> seems to be that it's not as well<br>
> loved as `unfold`?<br>
<br>
I do like `sequence`, though I'm not sold on the name AdHocSequence<br>
(just from that name it's hard to figure out what it does). An<br>
alternative is `expand`, which is nice because it pairs with `reduce`,<br>
but it's less obvious that it produces a sequence and the name isn't as<br>
good with the stateful version.<br>
<br>
As for return type name, we could go ahead and use UnfoldSequence<T><br>
anyway even though the function isn't named `unfold`, because this name<br>
will make sense to people who do know what unfold is, and I'm not<br>
convinced we can have a meaningful name for people who don't (since<br>
SequenceSequence is too silly).<br>
<br>
So given that, I'll suggest the following:<br>
<br>
func sequence<T>(initial: T, next: T -> T?) -> UnfoldSequence<T><br>
func sequence<T, State>(state: State, next: (inout State) -> T?) -><br>
UnfoldSequence<T><br>
<br>
I'm suggesting `sequence(initial:next:)` instead of the previously-<br>
suggested `sequence(from:applying:)` because the term "from" could<br>
equally well mean the first element or the state, whereas "initial"<br>
should make it more obvious that this value is the first element of the<br>
resulting sequence. And I'm using "next" as suggested by Erica because<br>
the function does return the next element, and it's similar to the<br>
IteratorProtocol method. I've also chosen to change the stateful version<br>
to use an inout parameter, as previously suggested, because it's<br>
equivalent to the State -> (T, State)? in functionality but is less<br>
likely to produce unwanted COW copies.<br>
<br>
-Kevin Ballard<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/6087ca3b/attachment-0001.html" rel="noreferrer" target="_blank">https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/6087ca3b/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 26<br>
Date: Fri, 13 May 2016 21:14:44 +0200<br>
From: Adrian Zubarev <<a href="mailto:adrian.zubarev@devandartist.com">adrian.zubarev@devandartist.com</a>><br>
To: <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
Subject: Re: [swift-evolution] [Pitch] merge types and protocols back<br>
together with type<Type, Protocol, ...><br>
Message-ID: <etPan.573627a4.578126f6.6ab2@DevAndArtist.fritz.box><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
As we can(as example) expect that in 3rd party code someone will do: <br>
<br>
extension StructA: ExtraProtocol1 { <br>
func bar() {} <br>
} <br>
<br>
extension StructB: ExtraProtocol2 { <br>
func blort() {} <br>
} <br>
<br>
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?<br>
<br>
Sure one could think that this protocols might be optional but the `f(p: MyProtocol)` function will cover this scenario.<br>
<br>
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.<br>
<br>
Here is what I mean in detail:<br>
<br>
protocol SomeProtocol /* we can’t constraint it to value types at the moment, only `class`es works */ {}<br>
<br>
func foo<T>(value: struct<T, SomeProtocol>) { /* do some work */ }<br>
<br>
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.<br>
<br>
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:<br>
<br>
func foo<T: struct where T: SomeProtocol>(value: T) {}<br>
<br>
But it seems that such a thing won’t ever happen to Swift.<br>
<br>
Basically `struct<>`, `class<>` and `enum<>` will just enable this for us. `all<>` would accept any type at its first element.<br>
<br>
func foo<T /* add more constraints here */ >(value: all<T, SomeProtocol>) { /* T could be a reference type or value type */ }<br>
<br>
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.<br>
<br>
@Matthew: isn’t this somehow a step towards (generic) `PureValue` types?<br>
<br>
struct A<T> {<br>
<br>
var value: struct<T> // if we drop the strict rule of at least one protocols<br>
}<br>
<br>
How does it sound to you?<br>
<br>
-- <br>
Adrian Zubarev<br>
Sent with Airmail<br>
<br>
Am 13. Mai 2016 bei 20:34:59, Vladimir.S (<a href="mailto:svabox@gmail.com">svabox@gmail.com</a>) schrieb:<br>
<br>
Hmm..<br>
<br>
What about such synthetic scenario:<br>
<br>
at the moment of writing our code we have:<br>
<br>
public protocol MyProtocol {<br>
func foo()<br>
}<br>
<br>
public struct StructA:MyProtocol {<br>
func foo()<br>
}<br>
<br>
public struct StructB:MyProtocol {<br>
func foo()<br>
}<br>
<br>
and have<br>
<br>
public protocol ExtraProtocol1 {<br>
func bar()<br>
}<br>
<br>
public protocol ExtraProtocol2 {<br>
func blort()<br>
}<br>
<br>
then we actually can have such code:<br>
<br>
func f(p: MyProtocol) {<br>
if let a = p as? struct<StructA, ExtraProtocol1> {<br>
a.foo()<br>
a.bar()<br>
}<br>
else<br>
if let b = p as? struct<StructB, ExtraProtocol2> {<br>
b.foo()<br>
b.blort()<br>
}<br>
}<br>
<br>
<br>
<br>
<br>
On 13.05.2016 20:50, Adrian Zubarev via swift-evolution wrote:<br>
>> 'struct<>' does seem redundant unless it becomes subtypeable. If<br>
>> you want a struct which conforms to several protocols, protocol<><br>
>> already covers this.<br>
>><br>
>> I think this is not correct. Lets check this example:<br>
>><br>
>> func foo(value: SomeProtocol) {<br>
>><br>
>> if let a = value as? struct<StructA, SomeProtocol> { /* do<br>
>> something with a */ }<br>
>><br>
>> else if let b = value as? struct<StructB, SomeProtocol> { /* do<br>
>> something with b */ }<br>
>><br>
>> }<br>
>><br>
>> In this scenario you’ll be able to access properties and functions<br>
>> from `StructA` or `StructB` which might not be covered by<br>
>> `SomeProtocol`. Everything is merged nicely into one instance. But<br>
>> you are right it depends on the use-case.<br>
>><br>
>><br>
>> There is no need to include the protocol here. Just do this:<br>
>><br>
>> if let a = value as? StructA { use a }<br>
>><br>
> Whoops, I forgot that this will do the trick. I apologize for any confusion<br>
> here, you are totally right.<br>
><br>
> That been said, do we really need `type<>` aka. `all<>` for value types? I<br>
> need to rethink this part of the proposal. Is there any use-case where we<br>
> would need this (any scenario for the future Swift version also counts)?<br>
><br>
> If we had `all<>` in Swift already for extendable reference types and one<br>
> day structs would become subtypeable, this wouldn’t be a huge problem to<br>
> upgrade `all<>` for structs I guess.<br>
><br>
> --<br>
> Adrian Zubarev<br>
> Sent with Airmail<br>
><br>
><br>
><br>
> _______________________________________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/167979a4/attachment-0001.html" rel="noreferrer" target="_blank">https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/167979a4/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 27<br>
Date: Fri, 13 May 2016 19:24:31 +0000<br>
From: Jacob Bandes-Storch <<a href="mailto:jtbandes@gmail.com">jtbandes@gmail.com</a>><br>
To: Matt Wright <<a href="mailto:mww@apple.com">mww@apple.com</a>><br>
Cc: swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>><br>
Subject: Re: [swift-evolution] [Review] SE-0088: Modernize libdispatch<br>
for Swift 3 naming conventions<br>
Message-ID:<br>
<<a href="mailto:CADcs6kNjyOgbBWs-4Ho8Mc2882DRKHJbAhOrvk1sggb-_7audA@mail.gmail.com">CADcs6kNjyOgbBWs-4Ho8Mc2882DRKHJbAhOrvk1sggb-_7audA@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
This looks great. Thanks for revising. I'm now a +1 on this.<br>
<br>
A couple more minor suggestions:<br>
<br>
- Consider renaming setTimer(...) to resetTimer() or just reset(), or<br>
something similar?<br>
<br>
- Consider making Semaphore's wait() throw an error, rather than returning<br>
non-zero, in the event of a timeout. Most common uses will be "try!<br>
wait()". Or you could have waitForever() be a separate, non-throwing<br>
function.<br>
<br>
Jacob Bandes-Storch<br>
<br>
On Fri, May 13, 2016 at 11:36 AM, Matt Wright via swift-evolution <<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
<br>
> [Apologies for the weird threading, I missed the original email to the<br>
> list so I can’t reply to it directly]<br>
><br>
> I just wanted to let the list know that I updated proposal SE-0088 to fix<br>
> the typos and include a more complete listing of the Dispatch module after<br>
> the transformations in the proposal have been applied. Additionally, I’ve<br>
> been keeping up with some of the feedback in this review thread and looking<br>
> to see which ones would be best applied to the proposal. Though it should<br>
> be made clear, this particular update only covers fixing the<br>
> inconsistencies in my original proposal and providing a more complete<br>
> overview of the module layout.<br>
><br>
> Similar to the changes in Foundation that are proposed on swift-evolution,<br>
> I don’t expect all of the changes in libdispatch will be able to go through<br>
> this process. As this is a large change (and, hopefully, a step forwards)<br>
> to libdispatch I believe it is important to bring it to the swift-evolution<br>
> list and take away your feedback for inclusion in future iterations of the<br>
> module.<br>
><br>
> Thanks again for your continued feedback,<br>
> Matt<br>
><br>
> > On Tue, May 10, 2016 at 9:39 PM, Chris Lattner via swift-evolution <<br>
> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
> > Hello Swift community,<br>
> ><br>
> > The review of "SE-0088: Modernize libdispatch for Swift 3 naming<br>
> conventions" begins now and runs through May 17. The proposal is available<br>
> here:<br>
> ><br>
> ><br>
> <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0088-libdispatch-for-swift3.md" rel="noreferrer" target="_blank">https://github.com/apple/swift-evolution/blob/master/proposals/0088-libdispatch-for-swift3.md</a><br>
> ><br>
> > Reviews are an important part of the Swift evolution process. All<br>
> reviews should be sent to the swift-evolution mailing list at<br>
> ><br>
> > <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
> ><br>
> > or, if you would like to keep your feedback private, directly to the<br>
> review manager.<br>
> ><br>
> > What goes into a review?<br>
> ><br>
> > The goal of the review process is to improve the proposal under review<br>
> through constructive criticism and contribute to the direction of Swift.<br>
> When writing your review, here are some questions you might want to answer<br>
> in your review:<br>
> ><br>
> > * What is your evaluation of the proposal?<br>
> > * Is the problem being addressed significant enough to warrant a<br>
> change to Swift?<br>
> > * Does this proposal fit well with the feel and direction of<br>
> Swift?<br>
> > * If you have used other languages or libraries with a similar<br>
> feature, how do you feel that this proposal compares to those?<br>
> > * How much effort did you put into your review? A glance, a<br>
> quick reading, or an in-depth study?<br>
> ><br>
> > More information about the Swift evolution process is available at<br>
> ><br>
> > <a href="https://github.com/apple/swift-evolution/blob/master/process.md" rel="noreferrer" target="_blank">https://github.com/apple/swift-evolution/blob/master/process.md</a><br>
> ><br>
> > Thank you,<br>
> ><br>
> > -Chris Lattner<br>
> > Review Manager<br>
> ><br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > swift-evolution mailing list<br>
> > <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
> > <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
> ><br>
> > _______________________________________________<br>
> > swift-evolution mailing list<br>
> > <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
> > <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
><br>
> _______________________________________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/25063811/attachment-0001.html" rel="noreferrer" target="_blank">https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/25063811/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 28<br>
Date: Fri, 13 May 2016 19:29:06 +0000<br>
From: Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com">xiaodi.wu@gmail.com</a>><br>
To: Matt Wright <<a href="mailto:mww@apple.com">mww@apple.com</a>>, swift-evolution<br>
<<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>><br>
Subject: Re: [swift-evolution] [Review] SE-0088: Modernize libdispatch<br>
for Swift 3 naming conventions<br>
Message-ID:<br>
<<a href="mailto:CAGY80umC-paivBJ3Ci3MPp_j%2BEx_QrYe7LFNmN%2B2TYMB4J53wQ@mail.gmail.com">CAGY80umC-paivBJ3Ci3MPp_j+Ex_QrYe7LFNmN+2TYMB4J53wQ@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
More nits:<br>
<br>
setHighWater(highWater:) and its ilk should should probably be<br>
setHighWater(_:) and so on (I include among these setInterval(interval:),<br>
setTargetQueue(queue:), etc.)<br>
<br>
Similarly, in terms of conforming to Swift guidelines, I notice many<br>
instances where labels repeat the parameter type, especially<br>
DispatchWalltime. For instance, setTimer(walltime: DispatchWalltime,<br>
leeway: DispatchTimeInterval)--not sure what to suggest here other than<br>
point out that the first label is redundant.<br>
On Fri, May 13, 2016 at 11:36 Matt Wright via swift-evolution <<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
<br>
> [Apologies for the weird threading, I missed the original email to the<br>
> list so I can’t reply to it directly]<br>
><br>
> I just wanted to let the list know that I updated proposal SE-0088 to fix<br>
> the typos and include a more complete listing of the Dispatch module after<br>
> the transformations in the proposal have been applied. Additionally, I’ve<br>
> been keeping up with some of the feedback in this review thread and looking<br>
> to see which ones would be best applied to the proposal. Though it should<br>
> be made clear, this particular update only covers fixing the<br>
> inconsistencies in my original proposal and providing a more complete<br>
> overview of the module layout.<br>
><br>
> Similar to the changes in Foundation that are proposed on swift-evolution,<br>
> I don’t expect all of the changes in libdispatch will be able to go through<br>
> this process. As this is a large change (and, hopefully, a step forwards)<br>
> to libdispatch I believe it is important to bring it to the swift-evolution<br>
> list and take away your feedback for inclusion in future iterations of the<br>
> module.<br>
><br>
> Thanks again for your continued feedback,<br>
> Matt<br>
><br>
> > On Tue, May 10, 2016 at 9:39 PM, Chris Lattner via swift-evolution <<br>
> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
> > Hello Swift community,<br>
> ><br>
> > The review of "SE-0088: Modernize libdispatch for Swift 3 naming<br>
> conventions" begins now and runs through May 17. The proposal is available<br>
> here:<br>
> ><br>
> ><br>
> <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0088-libdispatch-for-swift3.md" rel="noreferrer" target="_blank">https://github.com/apple/swift-evolution/blob/master/proposals/0088-libdispatch-for-swift3.md</a><br>
> ><br>
> > Reviews are an important part of the Swift evolution process. All<br>
> reviews should be sent to the swift-evolution mailing list at<br>
> ><br>
> > <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
> ><br>
> > or, if you would like to keep your feedback private, directly to the<br>
> review manager.<br>
> ><br>
> > What goes into a review?<br>
> ><br>
> > The goal of the review process is to improve the proposal under review<br>
> through constructive criticism and contribute to the direction of Swift.<br>
> When writing your review, here are some questions you might want to answer<br>
> in your review:<br>
> ><br>
> > * What is your evaluation of the proposal?<br>
> > * Is the problem being addressed significant enough to warrant a<br>
> change to Swift?<br>
> > * Does this proposal fit well with the feel and direction of<br>
> Swift?<br>
> > * If you have used other languages or libraries with a similar<br>
> feature, how do you feel that this proposal compares to those?<br>
> > * How much effort did you put into your review? A glance, a<br>
> quick reading, or an in-depth study?<br>
> ><br>
> > More information about the Swift evolution process is available at<br>
> ><br>
> > <a href="https://github.com/apple/swift-evolution/blob/master/process.md" rel="noreferrer" target="_blank">https://github.com/apple/swift-evolution/blob/master/process.md</a><br>
> ><br>
> > Thank you,<br>
> ><br>
> > -Chris Lattner<br>
> > Review Manager<br>
> ><br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > swift-evolution mailing list<br>
> > <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
> > <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
> ><br>
> > _______________________________________________<br>
> > swift-evolution mailing list<br>
> > <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
> > <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
><br>
> _______________________________________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/4644df43/attachment-0001.html" rel="noreferrer" target="_blank">https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/4644df43/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 29<br>
Date: Fri, 13 May 2016 12:44:59 -0700<br>
From: Matt Wright <<a href="mailto:mww@apple.com">mww@apple.com</a>><br>
To: Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com">xiaodi.wu@gmail.com</a>><br>
Cc: swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>><br>
Subject: Re: [swift-evolution] [Review] SE-0088: Modernize libdispatch<br>
for Swift 3 naming conventions<br>
Message-ID: <<a href="mailto:96D2038A-FB04-47FF-B7CF-85923D50AD2A@apple.com">96D2038A-FB04-47FF-B7CF-85923D50AD2A@apple.com</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
<br>
> On May 13, 2016, at 12:29 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com">xiaodi.wu@gmail.com</a>> wrote:<br>
><br>
> More nits:<br>
><br>
> setHighWater(highWater:) and its ilk should should probably be setHighWater(_:) and so on (I include among these setInterval(interval:), setTargetQueue(queue:), etc.)<br>
<br>
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!<br>
<br>
> 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.<br>
<br>
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.<br>
<br>
> On Fri, May 13, 2016 at 11:36 Matt Wright via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
> [Apologies for the weird threading, I missed the original email to the list so I can’t reply to it directly]<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> Thanks again for your continued feedback,<br>
> Matt<br>
><br>
> > On Tue, May 10, 2016 at 9:39 PM, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
> > Hello Swift community,<br>
> ><br>
> > The review of "SE-0088: Modernize libdispatch for Swift 3 naming conventions" begins now and runs through May 17. The proposal is available here:<br>
> ><br>
> > <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0088-libdispatch-for-swift3.md" rel="noreferrer" target="_blank">https://github.com/apple/swift-evolution/blob/master/proposals/0088-libdispatch-for-swift3.md</a><br>
> ><br>
> > Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at<br>
> ><br>
> > <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
> ><br>
> > or, if you would like to keep your feedback private, directly to the review manager.<br>
> ><br>
> > What goes into a review?<br>
> ><br>
> > 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:<br>
> ><br>
> > * What is your evaluation of the proposal?<br>
> > * Is the problem being addressed significant enough to warrant a change to Swift?<br>
> > * Does this proposal fit well with the feel and direction of Swift?<br>
> > * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?<br>
> > * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?<br>
> ><br>
> > More information about the Swift evolution process is available at<br>
> ><br>
> > <a href="https://github.com/apple/swift-evolution/blob/master/process.md" rel="noreferrer" target="_blank">https://github.com/apple/swift-evolution/blob/master/process.md</a><br>
> ><br>
> > Thank you,<br>
> ><br>
> > -Chris Lattner<br>
> > Review Manager<br>
> ><br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > swift-evolution mailing list<br>
> > <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
> > <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
> ><br>
> > _______________________________________________<br>
> > swift-evolution mailing list<br>
> > <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
> > <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
><br>
> _______________________________________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 30<br>
Date: Fri, 13 May 2016 12:51:34 -0700<br>
From: Matt Wright <<a href="mailto:mww@apple.com">mww@apple.com</a>><br>
To: Jacob Bandes-Storch <<a href="mailto:jtbandes@gmail.com">jtbandes@gmail.com</a>><br>
Cc: swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>><br>
Subject: Re: [swift-evolution] [Review] SE-0088: Modernize libdispatch<br>
for Swift 3 naming conventions<br>
Message-ID: <<a href="mailto:82629D20-E9E7-4B06-8E13-3ADBDB225099@apple.com">82629D20-E9E7-4B06-8E13-3ADBDB225099@apple.com</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
<br>
> On May 13, 2016, at 12:24 PM, Jacob Bandes-Storch <<a href="mailto:jtbandes@gmail.com">jtbandes@gmail.com</a>> wrote:<br>
><br>
> This looks great. Thanks for revising. I'm now a +1 on this.<br>
><br>
> A couple more minor suggestions:<br>
><br>
> - Consider renaming setTimer(...) to resetTimer() or just reset(), or something similar?<br>
<br>
setTimer addresses both the initial setup as well as setting it again. I’m not sure reset is a good name for it.<br>
<br>
> - 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.<br>
<br>
Throwing an error here seems like a sensible improvement.<br>
<br>
><br>
> Jacob Bandes-Storch<br>
><br>
> On Fri, May 13, 2016 at 11:36 AM, Matt Wright via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
> [Apologies for the weird threading, I missed the original email to the list so I can’t reply to it directly]<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> Thanks again for your continued feedback,<br>
> Matt<br>
><br>
> > On Tue, May 10, 2016 at 9:39 PM, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
> > Hello Swift community,<br>
> ><br>
> > The review of "SE-0088: Modernize libdispatch for Swift 3 naming conventions" begins now and runs through May 17. The proposal is available here:<br>
> ><br>
> > <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0088-libdispatch-for-swift3.md" rel="noreferrer" target="_blank">https://github.com/apple/swift-evolution/blob/master/proposals/0088-libdispatch-for-swift3.md</a><br>
> ><br>
> > Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at<br>
> ><br>
> > <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
> ><br>
> > or, if you would like to keep your feedback private, directly to the review manager.<br>
> ><br>
> > What goes into a review?<br>
> ><br>
> > 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:<br>
> ><br>
> > * What is your evaluation of the proposal?<br>
> > * Is the problem being addressed significant enough to warrant a change to Swift?<br>
> > * Does this proposal fit well with the feel and direction of Swift?<br>
> > * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?<br>
> > * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?<br>
> ><br>
> > More information about the Swift evolution process is available at<br>
> ><br>
> > <a href="https://github.com/apple/swift-evolution/blob/master/process.md" rel="noreferrer" target="_blank">https://github.com/apple/swift-evolution/blob/master/process.md</a><br>
> ><br>
> > Thank you,<br>
> ><br>
> > -Chris Lattner<br>
> > Review Manager<br>
> ><br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > swift-evolution mailing list<br>
> > <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
> > <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
> ><br>
> > _______________________________________________<br>
> > swift-evolution mailing list<br>
> > <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
> > <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
><br>
> _______________________________________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 31<br>
Date: Fri, 13 May 2016 16:58:06 -0300<br>
From: Leonardo Pessoa <<a href="mailto:me@lmpessoa.com">me@lmpessoa.com</a>><br>
To: Swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>><br>
Subject: Re: [swift-evolution] Could enums have their rawValue type<br>
inferred?<br>
Message-ID:<br>
<<a href="mailto:CANTOS57wksMRzUAMq0ncf1QAd82vhudf21tnea6wHjhBOFr1PA@mail.gmail.com">CANTOS57wksMRzUAMq0ncf1QAd82vhudf21tnea6wHjhBOFr1PA@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Eric, I think I understood your proposal. If I may explain in other words<br>
it would be "to automatically cast rawValue when assigning an enum value to<br>
a variable or argument of the type of the enum's raw value", am I right? I<br>
think this would imply a little more inference and type checking rules from<br>
the compiler and maybe even take a little longer to fully compile code. I'm<br>
not sure it's feasible but from your examples, I can see how it enhances<br>
readability of the code, so I'm +1 for it. My only concern is that you<br>
would still need to fully declare the enum's name where the value of the<br>
enum is used. Taking from your own example<br>
<br>
Animate.fadeIn(view, withSpeed: .fast)<br>
<br>
couldn't be called that way if withSpeed expects and NSTimeInterval because<br>
the compiler won't know whether you're refering to transitionSpeed or to<br>
ambientAnimationSpeed. You would still have to call it like<br>
<br>
Animate.fadeIn(view, withSpeed: transitionSpeed.fast)<br>
<br>
even if you had only one possible enum value over all declared enums<br>
because that would still force the compiler to search for each value over<br>
all known enums to define where the value you're using comes from and make<br>
sure there are no two enums with the same value.<br>
<br>
Aside from that, I good with the idea.<br>
<br>
<br>
<br>
On 13 May 2016 at 15:09, Eric Miller via swift-evolution <<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
<br>
> This might open a larger can of worms than I imagine, but what do you<br>
> folks think about using the `rawValue` of an enum when that rawValue is a<br>
> fit for the expected type?<br>
><br>
> Use case.<br>
><br>
> I'm making an animation facade, and it has some speed presets:<br>
><br>
> class Animate {<br>
> enum transitionSpeed: NSTimeInterval {<br>
> case fast = 0.15<br>
> case slow = 0.5<br>
> }<br>
> enum ambientAnimationSpeed: NSTimeInterval {<br>
> case fast = 1.0<br>
> case slow = 5.0<br>
> }<br>
> ...<br>
> }<br>
><br>
> I did them with static variables at first but that made the call site<br>
> verbose. Compare:<br>
><br>
> Animate.fadeIn(view, withSpeed: Animate.cfg.transitionFast)<br>
> Animate.fadeIn(view, withSpeed: .fast)<br>
><br>
> So, I like the enum approach better, but my library code has to use<br>
> `rawValue` to do anything with the actual value, of course:<br>
><br>
> static func fadeIn(view: UIView?, withSpeed duration:transitionSpeed =<br>
> .fast) {<br>
> ...<br>
> UIView.animateWithDuration(duration.rawValue, animations: { })<br>
> }<br>
><br>
> It's not a serious issue, but the code is more clear and beautiful if it<br>
> has just myIntent, rather than myIntent.rawValue.<br>
><br>
> I've hit this issue when modeling other things, such as:<br>
><br>
> * server fault codes<br>
> * HTTP status codes<br>
> * Currency codes<br>
> * Days of the week<br>
><br>
> Would it be appropriate to "autocast" to the rawValue of the enum when the<br>
> rawValue's Type matches the type expectation of the API? Or would this<br>
> introduce a bunch of type system uncertainty?<br>
><br>
> Maybe this could be implemented as a protocol? It feels almost like the<br>
> convenience of `CustomStringConvertible`'s `description` property.<br>
><br>
> _______________________________________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/05a1d4c2/attachment-0001.html" rel="noreferrer" target="_blank">https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/05a1d4c2/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 32<br>
Date: Fri, 13 May 2016 13:02:44 -0700<br>
From: Jacob Bandes-Storch <<a href="mailto:jtbandes@gmail.com">jtbandes@gmail.com</a>><br>
To: Erica Sadun <<a href="mailto:erica@ericasadun.com">erica@ericasadun.com</a>><br>
Cc: Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>><br>
Subject: Re: [swift-evolution] Removing "_ in" from empty closures<br>
Message-ID:<br>
<CADcs6kPHDONJd_1zVkrEuLBJUT8QsxU_kDcdY=<a href="mailto:hDf6EVOvEvnw@mail.gmail.com">hDf6EVOvEvnw@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
+1, seems logical to me:<br>
<br>
let x: [T] = []<br>
let x: [T:U] = [:]<br>
let x: T->() = {}<br>
<br>
Jacob<br>
<br>
On Fri, May 13, 2016 at 10:48 AM, Erica Sadun via swift-evolution <<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
<br>
> On May 13, 2016, at 11:14 AM, Cole Campbell via swift-evolution <<br>
> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
> ><br>
> ><br>
> >> +1. In general, I think we should allow implicit arguments, without<br>
> requiring the closure to use all the implicit $n variables like we do<br>
> today. These should all be valid:<br>
> >><br>
> >> let _: () -> () = {}<br>
> >> let _: (Int) -> () = {}<br>
> >> let _: (Int, Int) -> Int = { 5 }<br>
> >> let _: (Int, Int) -> Int = { $0 }<br>
> >> let _: (Int, Int) -> Int = { $1 }<br>
> ><br>
> > +1. This would be excellent.<br>
><br>
> +1. Good riddance to bad code baggage.<br>
><br>
> -- E<br>
><br>
> _______________________________________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/1fc15c26/attachment-0001.html" rel="noreferrer" target="_blank">https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/1fc15c26/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 33<br>
Date: Fri, 13 May 2016 15:06:18 -0500<br>
From: Matthew Johnson <<a href="mailto:matthew@anandabits.com">matthew@anandabits.com</a>><br>
To: Jacob Bandes-Storch <<a href="mailto:jtbandes@gmail.com">jtbandes@gmail.com</a>><br>
Cc: Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>><br>
Subject: Re: [swift-evolution] Removing "_ in" from empty closures<br>
Message-ID: <<a href="mailto:5F3F407C-B624-4596-9850-C8E059D5EE9A@anandabits.com">5F3F407C-B624-4596-9850-C8E059D5EE9A@anandabits.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Is anyone planning to write a proposal for this?<br>
<br>
Sent from my iPhone<br>
<br>
> On May 13, 2016, at 3:02 PM, Jacob Bandes-Storch via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
><br>
> +1, seems logical to me:<br>
><br>
> let x: [T] = []<br>
> let x: [T:U] = [:]<br>
> let x: T->() = {}<br>
><br>
> Jacob<br>
><br>
>> On Fri, May 13, 2016 at 10:48 AM, Erica Sadun via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
>> On May 13, 2016, at 11:14 AM, Cole Campbell via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
>> ><br>
>> ><br>
>> >> +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:<br>
>> >><br>
>> >> let _: () -> () = {}<br>
>> >> let _: (Int) -> () = {}<br>
>> >> let _: (Int, Int) -> Int = { 5 }<br>
>> >> let _: (Int, Int) -> Int = { $0 }<br>
>> >> let _: (Int, Int) -> Int = { $1 }<br>
>> ><br>
>> > +1. This would be excellent.<br>
>><br>
>> +1. Good riddance to bad code baggage.<br>
>><br>
>> -- E<br>
>><br>
>> _______________________________________________<br>
>> swift-evolution mailing list<br>
>> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
>> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
><br>
> _______________________________________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/edf1fd63/attachment-0001.html" rel="noreferrer" target="_blank">https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/edf1fd63/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 34<br>
Date: Fri, 13 May 2016 13:12:10 -0700<br>
From: Joe Groff <<a href="mailto:jgroff@apple.com">jgroff@apple.com</a>><br>
To: Matthew Johnson <<a href="mailto:matthew@anandabits.com">matthew@anandabits.com</a>><br>
Cc: Matthew Johnson via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>><br>
Subject: Re: [swift-evolution] [Draft] Introducing StaticSelf, an<br>
Invariant Self<br>
Message-ID: <<a href="mailto:DA7FECEA-2E3D-45D9-BE6A-E95C859F5794@apple.com">DA7FECEA-2E3D-45D9-BE6A-E95C859F5794@apple.com</a>><br>
Content-Type: text/plain; charset=us-ascii<br>
<br>
<br>
> On May 13, 2016, at 9:06 AM, Matthew Johnson <<a href="mailto:matthew@anandabits.com">matthew@anandabits.com</a>> wrote:<br>
><br>
><br>
>> On May 13, 2016, at 10:55 AM, Joe Groff <<a href="mailto:jgroff@apple.com">jgroff@apple.com</a>> wrote:<br>
>><br>
>><br>
>>> On May 13, 2016, at 8:18 AM, Matthew Johnson <<a href="mailto:matthew@anandabits.com">matthew@anandabits.com</a>> wrote:<br>
>>><br>
>>> 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.<br>
>><br>
>> `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.<br>
><br>
> 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.<br>
<br>
That makes `StaticSelf` tricky to use in generic code. This would be invalid:<br>
<br>
protocol Makable {<br>
static func make(value: Int) -> StaticSelf<br>
}<br>
<br>
func makeWithZero<T: Fooable>(x: Int) -> T {<br>
return T.make(value: 0) // ERROR: T.StaticSelf may be a supertype of T so isn't convertible to T<br>
}<br>
<br>
`StaticSelf` in this model is effectively an associated type of the protocol, with a `Self: StaticSelf` constraint (if that were supported).<br>
<br>
-Joe<br>
<br>
------------------------------<br>
<br>
Message: 35<br>
Date: Fri, 13 May 2016 13:16:31 -0700<br>
From: Joe Groff <<a href="mailto:jgroff@apple.com">jgroff@apple.com</a>><br>
To: Matthew Johnson <<a href="mailto:matthew@anandabits.com">matthew@anandabits.com</a>><br>
Cc: Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>><br>
Subject: Re: [swift-evolution] Removing "_ in" from empty closures<br>
Message-ID: <<a href="mailto:4D375D91-F148-4B2A-9E14-DE8FBBC41384@apple.com">4D375D91-F148-4B2A-9E14-DE8FBBC41384@apple.com</a>><br>
Content-Type: text/plain; charset=us-ascii<br>
<br>
<br>
> On May 13, 2016, at 1:06 PM, Matthew Johnson via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
><br>
> Is anyone planning to write a proposal for this?<br>
<br>
Sounds like you just signed up!<br>
<br>
-Joe<br>
<br>
> Sent from my iPhone<br>
><br>
> On May 13, 2016, at 3:02 PM, Jacob Bandes-Storch via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
><br>
>> +1, seems logical to me:<br>
>><br>
>> let x: [T] = []<br>
>> let x: [T:U] = [:]<br>
>> let x: T->() = {}<br>
>><br>
>> Jacob<br>
>><br>
>> On Fri, May 13, 2016 at 10:48 AM, Erica Sadun via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
>> On May 13, 2016, at 11:14 AM, Cole Campbell via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
>> ><br>
>> ><br>
>> >> +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:<br>
>> >><br>
>> >> let _: () -> () = {}<br>
>> >> let _: (Int) -> () = {}<br>
>> >> let _: (Int, Int) -> Int = { 5 }<br>
>> >> let _: (Int, Int) -> Int = { $0 }<br>
>> >> let _: (Int, Int) -> Int = { $1 }<br>
>> ><br>
>> > +1. This would be excellent.<br>
>><br>
>> +1. Good riddance to bad code baggage.<br>
>><br>
>> -- E<br>
>><br>
>> _______________________________________________<br>
>> swift-evolution mailing list<br>
>> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
>> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
>><br>
>> _______________________________________________<br>
>> swift-evolution mailing list<br>
>> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
>> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
> _______________________________________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 36<br>
Date: Fri, 13 May 2016 17:07:44 -0400<br>
From: John Siracusa <<a href="mailto:siracusa@gmail.com">siracusa@gmail.com</a>><br>
To: swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>><br>
Subject: Re: [swift-evolution] [Review] SE-0084: Allow trailing commas<br>
in parameter lists and tuples<br>
Message-ID:<br>
<CAJu6bqtOxv6FFoZVuynvJjTdzQimv+gSc9ZNDJZWOjwzGKvd=<a href="mailto:A@mail.gmail.com">A@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Having used, more or less continuously for my 20 years as a professional<br>
programmer, both a language that allows trailing commas and one that does<br>
not, I come down pretty strongly on the side of allowing trailing commas<br>
(for all the reasons already stated in this thread). If it means requiring<br>
a newline after the last comma to make some people feel better about it, so<br>
be it.<br>
<br>
-John<br>
<br>
<br>
<br>
On Fri, May 13, 2016 at 1:46 PM, Erica Sadun via swift-evolution <<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
<br>
><br>
> On May 13, 2016, at 11:29 AM, Joe Groff <<a href="mailto:jgroff@apple.com">jgroff@apple.com</a>> wrote:<br>
><br>
><br>
> On May 13, 2016, at 7:04 AM, Erica Sadun <<a href="mailto:erica@ericasadun.com">erica@ericasadun.com</a>> wrote:<br>
><br>
> On May 12, 2016, at 11:01 PM, Chris Lattner via swift-evolution <<br>
> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
><br>
> On May 12, 2016, at 4:50 PM, Joe Groff <<a href="mailto:jgroff@apple.com">jgroff@apple.com</a>> wrote:<br>
><br>
> You’re arguing that you want to read Swift code written like this?<br>
><br>
><br>
> I wouldn't mind it.<br>
><br>
><br>
> I personally find that style repulsive :-) and I haven’t seen swift code<br>
> commonly doing it. I’m not sure that we want to encourage it either.<br>
><br>
><br>
> No. Tell us what you *really* think of the style. Don't hold back.[1]<br>
><br>
> If we were really concerned about this, a narrower way to solve the same<br>
> problem would be to allow a comma before the ), but *only* when there is a<br>
> newline between them. I still don’t see why we’d want to encourage this<br>
> though.<br>
><br>
><br>
> I wouldn't object to this restriction. I cannot think of a situation where<br>
> using ",)" -- that is the comma adjacent to a closing parenthesis -- makes<br>
> sense for any reason previously enumerated in support of this proposal.<br>
><br>
><br>
> I don't see why we need to micromanage the situations where trailing<br>
> commas are allowed. That's just unnecessarily increasing the fractal<br>
> complexity of the language. We've delegated other style choices like<br>
> requiring `self.` or brace formatting to linters; why does this one need to<br>
> be legislated by the compiler?<br>
><br>
> -Joe<br>
><br>
><br>
> Mostly because I'm trying to play nice and get Chris to reconsider. I'd<br>
> like to get the feature, I'm willing to compromise on the technicalities.<br>
> Having it would make my coding life significantly easier and if a little<br>
> micromanagement is involved, I'm not terribly fussed. When I need trailing<br>
> commas, it's always at the ends of lines anyway.<br>
><br>
> But since I don't want to undercut you, so I'd much prefer to step back<br>
> and defer to your judgement on this.<br>
><br>
> -- E<br>
><br>
><br>
> _______________________________________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/ef8148fe/attachment-0001.html" rel="noreferrer" target="_blank">https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/ef8148fe/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 37<br>
Date: Sat, 14 May 2016 00:16:16 +0300<br>
From: "Vladimir.S" <<a href="mailto:svabox@gmail.com">svabox@gmail.com</a>><br>
To: Adrian Zubarev <<a href="mailto:adrian.zubarev@devandartist.com">adrian.zubarev@devandartist.com</a>><br>
Cc: swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>><br>
Subject: Re: [swift-evolution] [Pitch] merge types and protocols back<br>
together with type<Type, Protocol, ...><br>
Message-ID: <<a href="mailto:e4a00c9d-d327-1015-ab01-0ac4a689a114@gmail.com">e4a00c9d-d327-1015-ab01-0ac4a689a114@gmail.com</a>><br>
Content-Type: text/plain; charset=utf-8; format=flowed<br>
<br>
You asked for any example, I give it to you ;-)<br>
(as I said, it is syntactical, just to show that such struct<> can be used<br>
to test some struct for conforming to protocol, that was not conformed at<br>
writing time)<br>
Probably we can invent useful examples for this struct<> - but I don't<br>
believe it will be introduced in Swift ;-)<br>
<br>
On 13.05.2016 22:14, Adrian Zubarev via swift-evolution wrote:<br>
> Can we really do that? I mean, I thought about that myself but I came to<br>
> the conclusion that this scenario is like: I was to lazy to couple this<br>
> structs to my library protocols, will you do that for me?<br>
<br>
<br>
------------------------------<br>
<br>
Message: 38<br>
Date: Sat, 14 May 2016 00:46:23 +0300<br>
From: "Vladimir.S" <<a href="mailto:svabox@gmail.com">svabox@gmail.com</a>><br>
To: Joe Groff <<a href="mailto:jgroff@apple.com">jgroff@apple.com</a>><br>
Cc: swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>><br>
Subject: Re: [swift-evolution] [Draft] Introducing StaticSelf, an<br>
Invariant Self<br>
Message-ID: <<a href="mailto:cbc94f19-4c47-3859-fc27-05116dec50ae@gmail.com">cbc94f19-4c47-3859-fc27-05116dec50ae@gmail.com</a>><br>
Content-Type: text/plain; charset=utf-8; format=flowed<br>
<br>
Seems like ->StaticSelf can actually only means returns the class for which<br>
protocol conformance was applied first(in hierarchy). I.e. some `->BaseSelf`.<br>
But in this case we need a method to get this 'base' class from protocol..<br>
<br>
something like(just pseudo code!):<br>
<br>
func makeWithZero<T: Makable >(x: Int) -> Makable(T).FirstConformedClass {<br>
return T.make(value: 0)<br>
}<br>
<br>
or<br>
<br>
func makeWithZero<T: Makable >(x: Int) -> type<T.make(value:)> {<br>
return T.make(value: 0)<br>
}<br>
<br>
I don't know if all of this makes sense at all ;-)<br>
<br>
On 13.05.2016 23:12, Joe Groff via swift-evolution wrote:<br>
><br>
>> On May 13, 2016, at 9:06 AM, Matthew Johnson <<a href="mailto:matthew@anandabits.com">matthew@anandabits.com</a>> wrote:<br>
>><br>
>><br>
>>> On May 13, 2016, at 10:55 AM, Joe Groff <<a href="mailto:jgroff@apple.com">jgroff@apple.com</a>> wrote:<br>
>>><br>
>>><br>
>>>> On May 13, 2016, at 8:18 AM, Matthew Johnson <<a href="mailto:matthew@anandabits.com">matthew@anandabits.com</a>> wrote:<br>
>>>><br>
>>>> 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.<br>
>>><br>
>>> `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.<br>
>><br>
>> 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.<br>
><br>
> That makes `StaticSelf` tricky to use in generic code. This would be invalid:<br>
><br>
> protocol Makable {<br>
> static func make(value: Int) -> StaticSelf<br>
> }<br>
><br>
> func makeWithZero<T: Fooable>(x: Int) -> T {<br>
> return T.make(value: 0) // ERROR: T.StaticSelf may be a supertype of T so isn't convertible to T<br>
> }<br>
><br>
> `StaticSelf` in this model is effectively an associated type of the protocol, with a `Self: StaticSelf` constraint (if that were supported).<br>
><br>
> -Joe<br>
> _______________________________________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
><br>
<br>
<br>
------------------------------<br>
<br>
Message: 39<br>
Date: Fri, 13 May 2016 17:21:02 -0500<br>
From: Matthew Johnson <<a href="mailto:matthew@anandabits.com">matthew@anandabits.com</a>><br>
To: Joe Groff <<a href="mailto:jgroff@apple.com">jgroff@apple.com</a>><br>
Cc: Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>><br>
Subject: Re: [swift-evolution] Removing "_ in" from empty closures<br>
Message-ID: <<a href="mailto:86DB53E1-6567-411B-8350-5C9794EEF39E@anandabits.com">86DB53E1-6567-411B-8350-5C9794EEF39E@anandabits.com</a>><br>
Content-Type: text/plain; charset=us-ascii<br>
<br>
<br>
<br>
Sent from my iPhone<br>
<br>
> On May 13, 2016, at 3:16 PM, Joe Groff <<a href="mailto:jgroff@apple.com">jgroff@apple.com</a>> wrote:<br>
><br>
><br>
>> On May 13, 2016, at 1:06 PM, Matthew Johnson via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
>><br>
>> Is anyone planning to write a proposal for this?<br>
><br>
> Sounds like you just signed up!<br>
<br>
Lol, sounds good. Just don't want to duplicate efforts! :)<br>
<br>
><br>
> -Joe<br>
><br>
>> Sent from my iPhone<br>
>><br>
>>> On May 13, 2016, at 3:02 PM, Jacob Bandes-Storch via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
>>><br>
>>> +1, seems logical to me:<br>
>>><br>
>>> let x: [T] = []<br>
>>> let x: [T:U] = [:]<br>
>>> let x: T->() = {}<br>
>>><br>
>>> Jacob<br>
>>><br>
>>> On Fri, May 13, 2016 at 10:48 AM, Erica Sadun via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
>>>> On May 13, 2016, at 11:14 AM, Cole Campbell via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
>>>><br>
>>>><br>
>>>>> +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:<br>
>>>>><br>
>>>>> let _: () -> () = {}<br>
>>>>> let _: (Int) -> () = {}<br>
>>>>> let _: (Int, Int) -> Int = { 5 }<br>
>>>>> let _: (Int, Int) -> Int = { $0 }<br>
>>>>> let _: (Int, Int) -> Int = { $1 }<br>
>>>><br>
>>>> +1. This would be excellent.<br>
>>><br>
>>> +1. Good riddance to bad code baggage.<br>
>>><br>
>>> -- E<br>
>>><br>
>>> _______________________________________________<br>
>>> swift-evolution mailing list<br>
>>> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
>>> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
>>><br>
>>> _______________________________________________<br>
>>> swift-evolution mailing list<br>
>>> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
>>> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
>> _______________________________________________<br>
>> swift-evolution mailing list<br>
>> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
>> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 40<br>
Date: Fri, 13 May 2016 16:46:31 -0700<br>
From: Matt Wright <<a href="mailto:mww@apple.com">mww@apple.com</a>><br>
To: plx <<a href="mailto:plxswift@icloud.com">plxswift@icloud.com</a>><br>
Cc: "<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>" <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>><br>
Subject: Re: [swift-evolution] [Review] SE-0088: Modernize libdispatch<br>
for Swift 3 naming conventions<br>
Message-ID: <<a href="mailto:7662E01E-8594-45E2-8ABE-2B9B22DA99F5@apple.com">7662E01E-8594-45E2-8ABE-2B9B22DA99F5@apple.com</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
<br>
> On May 13, 2016, at 9:29 AM, plx via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
><br>
><br>
>> * What is your evaluation of the proposal?<br>
><br>
> +1 conceptually, some quibbles.<br>
><br>
> I agree with a few others that `synchronously` and `asynchronously` aren’t ideal; `dispatchSynchronously` or `dispatchSync` (or `performSync` or `performSynchronously`) all seem more-appropriate.<br>
><br>
> 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).<br>
<br>
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.<br>
<br>
><br>
> 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.<br>
<br>
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.<br>
<br>
><br>
> 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.<br>
<br>
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.<br>
<br>
><br>
> EG: I think of `dispatch_group_async` as a “method” on a `dispatch_group`, so would’ve expected this:<br>
><br>
> class DispatchGroup : DispatchObject {<br>
><br>
> // (actual name should match chosen name convention)<br>
> func asynchronouslyDispatch(to queue: DispatchQueue, work: @convention(block) () -> Void)<br>
><br>
> // (actual name should match chosen name convention)<br>
> func notify(on queue: DispatchQueue, using block: @convention(block) () -> Void)<br>
><br>
> }<br>
><br>
> …(and presumably the API would have manual enter/leave/wait methods and so on exposed).<br>
><br>
> I don’t feel strongly here but bring it up in case others feel similarly.<br>
><br>
> 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?<br>
<br>
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.<br>
<br>
><br>
> Also on queue-specifics, what is our expected story if we have custom destructors? Subclass `DispatchSpecificKey`?<br>
<br>
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.<br>
<br>
><br>
> 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.<br>
><br>
> For `DispatchData`, is there a principled reason there isn’t something like this defined:<br>
><br>
> struct DispatchDataSegment {<br>
> let bytes: UnsafeBufferPointer<UInt8><br>
> let byteIndex: Int<br>
> }<br>
><br>
> extension DispatchData {<br>
><br>
> /// Returns a sequence that enumerates the contiguous chunks,<br>
> /// e.g. a sequence with elements of type `DispatchDataSegment`.<br>
> ///<br>
> /// Sequence-based eplacement-for `enumerateBytes(_:)`<br>
> var segmentSequence: DispatchDataSegmentSequence { get }<br>
><br>
> }<br>
<br>
This is a good path to investigate in future improvements here.<br>
<br>
><br>
> …or something analogous (instead of the proposed use dispatch_data_apply?)?<br>
><br>
> 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.<br>
><br>
> 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.<br>
<br>
These should be present in today’s updated module listing.<br>
<br>
><br>
><br>
>> * Is the problem being addressed significant enough to warrant a change to Swift?<br>
>> * Does this proposal fit well with the feel and direction of Swift?<br>
>> * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?<br>
>> * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?<br>
>><br>
>> More information about the Swift evolution process is available at<br>
>><br>
>> <a href="https://github.com/apple/swift-evolution/blob/master/process.md" rel="noreferrer" target="_blank">https://github.com/apple/swift-evolution/blob/master/process.md</a><br>
>><br>
>> Thank you,<br>
>><br>
>> -Chris Lattner<br>
>> Review Manager<br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> swift-evolution mailing list<br>
>> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
>> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
><br>
> _______________________________________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 41<br>
Date: Sat, 14 May 2016 01:50:37 +0200<br>
From: Adrian Zubarev <<a href="mailto:adrian.zubarev@devandartist.com">adrian.zubarev@devandartist.com</a>><br>
To: <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
Subject: Re: [swift-evolution] [Pitch] merge types and protocols back<br>
together with type<Type, Protocol, ...><br>
Message-ID: <etPan.5736684d.50456560.6ab2@DevAndArtist.fritz.box><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
If anyone is interested, I started a draft proposal with detailed design here: <a href="https://github.com/DevAndArtist/swift-evolution/blob/master/proposals/nnnn-merging-types-with-protocols.md" rel="noreferrer" target="_blank">https://github.com/DevAndArtist/swift-evolution/blob/master/proposals/nnnn-merging-types-with-protocols.md</a><br>
<br>
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). <br>
<br>
`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.)<br>
<br>
I’d love to hear your feedback and strong arguments for the motivation part I could include into this proposal.<br>
<br>
-- <br>
Adrian Zubarev<br>
Sent with Airmail<br>
<br>
Am 13. Mai 2016 bei 23:16:20, Vladimir.S (<a href="mailto:svabox@gmail.com">svabox@gmail.com</a>) schrieb:<br>
<br>
You asked for any example, I give it to you ;-)<br>
(as I said, it is syntactical, just to show that such struct<> can be used<br>
to test some struct for conforming to protocol, that was not conformed at<br>
writing time)<br>
Probably we can invent useful examples for this struct<> - but I don't<br>
believe it will be introduced in Swift ;-)<br>
<br>
On 13.05.2016 22:14, Adrian Zubarev via swift-evolution wrote:<br>
> Can we really do that? I mean, I thought about that myself but I came to<br>
> the conclusion that this scenario is like: I was to lazy to couple this<br>
> structs to my library protocols, will you do that for me?<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://lists.swift.org/pipermail/swift-evolution/attachments/20160514/8100916d/attachment-0001.html" rel="noreferrer" target="_blank">https://lists.swift.org/pipermail/swift-evolution/attachments/20160514/8100916d/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 42<br>
Date: Fri, 13 May 2016 19:16:50 -0500<br>
From: Matthew Johnson <<a href="mailto:matthew@anandabits.com">matthew@anandabits.com</a>><br>
To: Adrian Zubarev <<a href="mailto:adrian.zubarev@devandartist.com">adrian.zubarev@devandartist.com</a>><br>
Cc: <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
Subject: Re: [swift-evolution] [Pitch] merge types and protocols back<br>
together with type<Type, Protocol, ...><br>
Message-ID: <<a href="mailto:99488013-D61B-4CD2-9671-3848838FCC8C@anandabits.com">99488013-D61B-4CD2-9671-3848838FCC8C@anandabits.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
<br>
> On May 13, 2016, at 2:14 PM, Adrian Zubarev via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
><br>
>> As we can(as example) expect that in 3rd party code someone will do:<br>
>><br>
>> extension StructA: ExtraProtocol1 {<br>
>> func bar() {}<br>
>> }<br>
>><br>
>> extension StructB: ExtraProtocol2 {<br>
>> func blort() {}<br>
>> }<br>
><br>
><br>
> 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?<br>
><br>
> Sure one could think that this protocols might be optional but the `f(p: MyProtocol)` function will cover this scenario.<br>
><br>
> 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? <<a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160502/016286.html" rel="noreferrer" target="_blank">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160502/016286.html</a>>), but I kinda like this new approach.<br>
><br>
> Here is what I mean in detail:<br>
><br>
> protocol SomeProtocol /* we can’t constraint it to value types at the moment, only `class`es works */ {}<br>
><br>
> func foo<T>(value: struct<T, SomeProtocol>) { /* do some work */ }<br>
><br>
> 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.<br>
><br>
> 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:<br>
><br>
> func foo<T: struct where T: SomeProtocol>(value: T) {}<br>
><br>
> But it seems that such a thing won’t ever happen to Swift.<br>
><br>
> Basically `struct<>`, `class<>` and `enum<>` will just enable this for us. `all<>` would accept any type at its first element.<br>
><br>
> func foo<T /* add more constraints here */ >(value: all<T, SomeProtocol>) { /* T could be a reference type or value type */ }<br>
><br>
> 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.<br>
><br>
> @Matthew: isn’t this somehow a step towards (generic) `PureValue` types?<br>
<br>
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.<br>
<br>
><br>
> struct A<T> {<br>
><br>
> var value: struct<T> // if we drop the strict rule of at least one protocols<br>
> }<br>
><br>
> How does it sound to you?<br>
><br>
> --<br>
> Adrian Zubarev<br>
> Sent with Airmail<br>
><br>
> Am 13. Mai 2016 bei 20:34:59, Vladimir.S (<a href="mailto:svabox@gmail.com">svabox@gmail.com</a> <mailto:<a href="mailto:svabox@gmail.com">svabox@gmail.com</a>>) schrieb:<br>
><br>
>> Hmm..<br>
>><br>
>> What about such synthetic scenario:<br>
>><br>
>> at the moment of writing our code we have:<br>
>><br>
>> public protocol MyProtocol {<br>
>> func foo()<br>
>> }<br>
>><br>
>> public struct StructA:MyProtocol {<br>
>> func foo()<br>
>> }<br>
>><br>
>> public struct StructB:MyProtocol {<br>
>> func foo()<br>
>> }<br>
>><br>
>> and have<br>
>><br>
>> public protocol ExtraProtocol1 {<br>
>> func bar()<br>
>> }<br>
>><br>
>> public protocol ExtraProtocol2 {<br>
>> func blort()<br>
>> }<br>
>><br>
>> then we actually can have such code:<br>
>><br>
>> func f(p: MyProtocol) {<br>
>> if let a = p as? struct<StructA, ExtraProtocol1> {<br>
>> a.foo()<br>
>> a.bar()<br>
>> }<br>
>> else<br>
>> if let b = p as? struct<StructB, ExtraProtocol2> {<br>
>> b.foo()<br>
>> b.blort()<br>
>> }<br>
>> }<br>
>><br>
>><br>
>><br>
>><br>
>> On 13.05.2016 20:50, Adrian Zubarev via swift-evolution wrote:<br>
>> >> 'struct<>' does seem redundant unless it becomes subtypeable. If<br>
>> >> you want a struct which conforms to several protocols, protocol<><br>
>> >> already covers this.<br>
>> >><br>
>> >> I think this is not correct. Lets check this example:<br>
>> >><br>
>> >> func foo(value: SomeProtocol) {<br>
>> >><br>
>> >> if let a = value as? struct<StructA, SomeProtocol> { /* do<br>
>> >> something with a */ }<br>
>> >><br>
>> >> else if let b = value as? struct<StructB, SomeProtocol> { /* do<br>
>> >> something with b */ }<br>
>> >><br>
>> >> }<br>
>> >><br>
>> >> In this scenario you’ll be able to access properties and functions<br>
>> >> from `StructA` or `StructB` which might not be covered by<br>
>> >> `SomeProtocol`. Everything is merged nicely into one instance. But<br>
>> >> you are right it depends on the use-case.<br>
>> >><br>
>> >><br>
>> >> There is no need to include the protocol here. Just do this:<br>
>> >><br>
>> >> if let a = value as? StructA { use a }<br>
>> >><br>
>> > Whoops, I forgot that this will do the trick. I apologize for any confusion<br>
>> > here, you are totally right.<br>
>> ><br>
>> > That been said, do we really need `type<>` aka. `all<>` for value types? I<br>
>> > need to rethink this part of the proposal. Is there any use-case where we<br>
>> > would need this (any scenario for the future Swift version also counts)?<br>
>> ><br>
>> > If we had `all<>` in Swift already for extendable reference types and one<br>
>> > day structs would become subtypeable, this wouldn’t be a huge problem to<br>
>> > upgrade `all<>` for structs I guess.<br>
>> ><br>
>> > --<br>
>> > Adrian Zubarev<br>
>> > Sent with Airmail<br>
>> ><br>
>> ><br>
>> ><br>
>> > _______________________________________________<br>
>> > swift-evolution mailing list<br>
>> > <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
>> > <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
>> ><br>
> _______________________________________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a> <mailto:<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a> <<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a>><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/0d832263/attachment-0001.html" rel="noreferrer" target="_blank">https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/0d832263/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 43<br>
Date: Fri, 13 May 2016 19:33:04 -0500<br>
From: Matthew Johnson <<a href="mailto:matthew@anandabits.com">matthew@anandabits.com</a>><br>
To: Joe Groff <<a href="mailto:jgroff@apple.com">jgroff@apple.com</a>><br>
Cc: Matthew Johnson via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>><br>
Subject: Re: [swift-evolution] [Draft] Introducing StaticSelf, an<br>
Invariant Self<br>
Message-ID: <<a href="mailto:E5E5D42D-5E98-4FD0-A29A-A4F228B4D558@anandabits.com">E5E5D42D-5E98-4FD0-A29A-A4F228B4D558@anandabits.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
<br>
> On May 13, 2016, at 3:12 PM, Joe Groff <<a href="mailto:jgroff@apple.com">jgroff@apple.com</a>> wrote:<br>
><br>
>><br>
>> On May 13, 2016, at 9:06 AM, Matthew Johnson <<a href="mailto:matthew@anandabits.com">matthew@anandabits.com</a>> wrote:<br>
>><br>
>><br>
>>> On May 13, 2016, at 10:55 AM, Joe Groff <<a href="mailto:jgroff@apple.com">jgroff@apple.com</a>> wrote:<br>
>>><br>
>>><br>
>>>> On May 13, 2016, at 8:18 AM, Matthew Johnson <<a href="mailto:matthew@anandabits.com">matthew@anandabits.com</a>> wrote:<br>
>>>><br>
>>>> 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.<br>
>>><br>
>>> `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.<br>
>><br>
>> 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.<br>
><br>
> That makes `StaticSelf` tricky to use in generic code. This would be invalid:<br>
><br>
> protocol Makable {<br>
> static func make(value: Int) -> StaticSelf<br>
> }<br>
><br>
> func makeWithZero<T: Fooable>(x: Int) -> T {<br>
> return T.make(value: 0) // ERROR: T.StaticSelf may be a supertype of T so isn't convertible to T<br>
> }<br>
<br>
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:<br>
<br>
protocol Makable {<br>
typealias RootMakable = StaticSelf<br>
static func make(value: Int) -> StaticSelf<br>
}<br>
<br>
func makeWithZero<T: Makable where T == T.RootMakable>(x: Int) -> T {<br>
return T.make(value: 0) // works now<br>
}<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
><br>
> `StaticSelf` in this model is effectively an associated type of the protocol, with a `Self: StaticSelf` constraint (if that were supported).<br>
<br>
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.<br>
<br>
<br>
<br>
><br>
> -Joe<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/3276330a/attachment-0001.html" rel="noreferrer" target="_blank">https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/3276330a/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 44<br>
Date: Fri, 13 May 2016 21:06:11 -0700<br>
From: Austin Zheng <<a href="mailto:austinzheng@gmail.com">austinzheng@gmail.com</a>><br>
To: Matthew Johnson <<a href="mailto:matthew@anandabits.com">matthew@anandabits.com</a>><br>
Cc: swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>><br>
Subject: Re: [swift-evolution] [Pitch] merge types and protocols back<br>
together with type<Type, Protocol, ...><br>
Message-ID:<br>
<<a href="mailto:CANGnqV14%2BBLVHx7CZgoHfTKnQfpxDXFzp4mTWO4MFCFtZfKCAg@mail.gmail.com">CANGnqV14+BLVHx7CZgoHfTKnQfpxDXFzp4mTWO4MFCFtZfKCAg@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
This is certainly a detailed and well-considered proposal.<br>
<br>
I don't think the struct functionality makes much sense. There are two ways<br>
you can use the struct<...> construct:<br>
<br>
1. struct<SomeConcreteStruct, Protocol1, Protocol2>. In this case the<br>
struct<...> representation is unnecessary; the protocols that are available<br>
to the user are known at compile-time, and structs can't have subtypes that<br>
conform to additional protocols like classes can. There is an example<br>
marked "func boo(value: struct<SomeStruct>) /* equivalent to */ func<br>
boo(value: SomeStruct)"; my question is why having more than two ways to<br>
express the same idea makes the language better, easier to use, etc.<br>
<br>
2. struct<T, Protocol1, Protocol2>. In this case struct<...> is being used<br>
as an add-on to the generics system to denote a 'must be value type'<br>
constraint. However, I think a 'T : class'-like 'struct' constraint makes<br>
more sense, both because it fits better with the existing 'class'<br>
constraint and because it can be used anywhere the generic system allows a<br>
type parameter to be constrained. A generic 'struct' constraint would give<br>
the currently generics system as much expressive power as struct<...>.<br>
<br>
Overall, rather than having this be a separate feature I think it should be<br>
developed as part of the "Generalized Existentials" feature that is already<br>
on the roadmap for Swift 3. The cases where adding class<...>, struct<...>,<br>
etc can improve expressive power are covered by allowing variables to take<br>
existential types with constraints. The one big feature that Generalized<br>
Existentials should absorb from this proposal is allowing the<br>
representation of a concrete class type with protocol constraints<br>
(<MyClass, SomeProtocol, AnotherProtocol>).<br>
<br>
Best,<br>
Austin<br>
<br>
<br>
<br>
On Fri, May 13, 2016 at 5:16 PM, Matthew Johnson via swift-evolution <<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
<br>
><br>
> On May 13, 2016, at 2:14 PM, Adrian Zubarev via swift-evolution <<br>
> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
><br>
> As we can(as example) expect that in 3rd party code someone will do:<br>
><br>
> extension StructA: ExtraProtocol1 {<br>
> func bar() {}<br>
> }<br>
><br>
> extension StructB: ExtraProtocol2 {<br>
> func blort() {}<br>
> }<br>
><br>
><br>
> Can we really do that? I mean, I thought about that myself but I came to<br>
> the conclusion that this scenario is like: I was to lazy to couple this<br>
> structs to my library protocols, will you do that for me?<br>
><br>
> Sure one could think that this protocols might be optional but the `f(p:<br>
> MyProtocol)` function will cover this scenario.<br>
><br>
> Another interesting side-effect `struct<>`, `class<>` and `enum<>` will<br>
> allow us to do is to distinguish between value and reference types for<br>
> generics. I tried this differentiation types with protocols like<br>
> `AnyReference` and `AnyValue` in another topic before (Should we rename<br>
> "class" when referring to protocol conformance?<br>
> <<a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160502/016286.html" rel="noreferrer" target="_blank">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160502/016286.html</a>>),<br>
> but I kinda like this new approach.<br>
><br>
> Here is what I mean in detail:<br>
><br>
> protocol SomeProtocol /* we can’t constraint it to value types at the<br>
> moment, only `class`es works */ {}<br>
><br>
> func foo<T>(value: struct<T, SomeProtocol>) { /* do some work */ }<br>
><br>
> This function is pretty neat. (1) You can force the library user to create<br>
> a struct with conformance to `SomeProtocol`. (2) This approach will accept<br>
> any struct which conforms to that protocol.<br>
><br>
> As I said in the protocol comment above protocols can only be constrained<br>
> to classes at the moment, and this might change in the future. If we also<br>
> had some sort of things for generics so the function from above might have<br>
> looked like this:<br>
><br>
> func foo<T: struct where T: SomeProtocol>(value: T) {}<br>
><br>
> But it seems that such a thing won’t ever happen to Swift.<br>
><br>
> Basically `struct<>`, `class<>` and `enum<>` will just enable this for us.<br>
> `all<>` would accept any type at its first element.<br>
><br>
> func foo<T /* add more constraints here */ >(value: all<T, SomeProtocol>)<br>
> { /* T could be a reference type or value type */ }<br>
><br>
> That been said, `all<>` could replace `protocol<>` where it is composed<br>
> from protocols. `all<>` can only be used as a generic constraints if the<br>
> first element is a protocol or a reference type.<br>
><br>
> @Matthew: isn’t this somehow a step towards (generic) `PureValue` types?<br>
><br>
><br>
> No. These say nothing about semantics. PureValue is all about the<br>
> semantics of a type and has nothing to do with what mechanism is used to<br>
> implement the type.<br>
><br>
><br>
> struct A<T> {<br>
><br>
> var value: struct<T> // if we drop the strict rule of at least one<br>
> protocols<br>
> }<br>
><br>
> How does it sound to you?<br>
><br>
> --<br>
> Adrian Zubarev<br>
> Sent with Airmail<br>
><br>
> Am 13. Mai 2016 bei 20:34:59, Vladimir.S (<a href="mailto:svabox@gmail.com">svabox@gmail.com</a>) schrieb:<br>
><br>
> Hmm..<br>
><br>
> What about such synthetic scenario:<br>
><br>
> at the moment of writing our code we have:<br>
><br>
> public protocol MyProtocol {<br>
> func foo()<br>
> }<br>
><br>
> public struct StructA:MyProtocol {<br>
> func foo()<br>
> }<br>
><br>
> public struct StructB:MyProtocol {<br>
> func foo()<br>
> }<br>
><br>
> and have<br>
><br>
> public protocol ExtraProtocol1 {<br>
> func bar()<br>
> }<br>
><br>
> public protocol ExtraProtocol2 {<br>
> func blort()<br>
> }<br>
><br>
> then we actually can have such code:<br>
><br>
> func f(p: MyProtocol) {<br>
> if let a = p as? struct<StructA, ExtraProtocol1> {<br>
> a.foo()<br>
> a.bar()<br>
> }<br>
> else<br>
> if let b = p as? struct<StructB, ExtraProtocol2> {<br>
> b.foo()<br>
> b.blort()<br>
> }<br>
> }<br>
><br>
><br>
><br>
><br>
> On 13.05.2016 20:50, Adrian Zubarev via swift-evolution wrote:<br>
> >> 'struct<>' does seem redundant unless it becomes subtypeable. If<br>
> >> you want a struct which conforms to several protocols, protocol<><br>
> >> already covers this.<br>
> >><br>
> >> I think this is not correct. Lets check this example:<br>
> >><br>
> >> func foo(value: SomeProtocol) {<br>
> >><br>
> >> if let a = value as? struct<StructA, SomeProtocol> { /* do<br>
> >> something with a */ }<br>
> >><br>
> >> else if let b = value as? struct<StructB, SomeProtocol> { /* do<br>
> >> something with b */ }<br>
> >><br>
> >> }<br>
> >><br>
> >> In this scenario you’ll be able to access properties and functions<br>
> >> from `StructA` or `StructB` which might not be covered by<br>
> >> `SomeProtocol`. Everything is merged nicely into one instance. But<br>
> >> you are right it depends on the use-case.<br>
> >><br>
> >><br>
> >> There is no need to include the protocol here. Just do this:<br>
> >><br>
> >> if let a = value as? StructA { use a }<br>
> >><br>
> > Whoops, I forgot that this will do the trick. I apologize for any<br>
> confusion<br>
> > here, you are totally right.<br>
> ><br>
> > That been said, do we really need `type<>` aka. `all<>` for value types?<br>
> I<br>
> > need to rethink this part of the proposal. Is there any use-case where we<br>
><br>
> > would need this (any scenario for the future Swift version also counts)?<br>
><br>
> ><br>
> > If we had `all<>` in Swift already for extendable reference types and one<br>
><br>
> > day structs would become subtypeable, this wouldn’t be a huge problem to<br>
><br>
> > upgrade `all<>` for structs I guess.<br>
> ><br>
> > --<br>
> > Adrian Zubarev<br>
> > Sent with Airmail<br>
> ><br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > swift-evolution mailing list<br>
> > <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
> > <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
> ><br>
><br>
> _______________________________________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/350b0db2/attachment-0001.html" rel="noreferrer" target="_blank">https://lists.swift.org/pipermail/swift-evolution/attachments/20160513/350b0db2/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 45<br>
Date: Sat, 14 May 2016 01:05:32 -0400<br>
From: Jon Shier <<a href="mailto:jon@jonshier.com">jon@jonshier.com</a>><br>
To: <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
Subject: Re: [swift-evolution] [Review] SE-0081: Move where clause to<br>
end of declaration<br>
Message-ID: <<a href="mailto:DC2A000A-6322-43A5-BD6D-2C405C745C89@jonshier.com">DC2A000A-6322-43A5-BD6D-2C405C745C89@jonshier.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
> * What is your evaluation of the proposal?<br>
<br>
-1<br>
<br>
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:<br>
<br>
func something<T: Decodable where T == T.DecodedType>(with something: T) -> String<br>
<br>
turns into this, which is less readable to me, as it hides important information between the generic information:<br>
<br>
func something<T: Decodable>(with something: T) -> String where T == T.DecodedType<br>
<br>
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:<br>
<br>
final class NetworkOperation<T: Decodable where T == T.DecodedType>: Operation,… {<br>
<br>
to:<br>
<br>
final class NetworkOperation<T: Decodable>: Operation,… where T == T.DecodedType {<br>
<br>
The additional conformances types can have make this an especially bad use case for this proposal.<br>
<br>
> * Is the problem being addressed significant enough to warrant a change to Swift?<br>
<br>
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.<br>
<br>
> * Does this proposal fit well with the feel and direction of Swift?<br>
<br>
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.<br>
<br>
> * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?<br>
<br>
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.<br>
<br>
> * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?<br>
<br>
Read the proposal, the thread thus far, and considered my response.<br>
<br>
<br>
<br>
Jon<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://lists.swift.org/pipermail/swift-evolution/attachments/20160514/a80f432d/attachment-0001.html" rel="noreferrer" target="_blank">https://lists.swift.org/pipermail/swift-evolution/attachments/20160514/a80f432d/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 46<br>
Date: Sat, 14 May 2016 01:19:49 -0400<br>
From: Jon Shier <<a href="mailto:jon@jonshier.com">jon@jonshier.com</a>><br>
To: swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>><br>
Subject: Re: [swift-evolution] [Pitch] Consistent bridging for<br>
NSErrors at the language boundary<br>
Message-ID: <<a href="mailto:C1FE5542-1469-4ECB-B422-D4C7F013CA58@jonshier.com">C1FE5542-1469-4ECB-B422-D4C7F013CA58@jonshier.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Charles:<br>
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.<br>
<br>
<br>
<br>
Jon Shier<br>
<br>
<br>
> On May 5, 2016, at 3:06 PM, Charles Srstka via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
><br>
> 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?<br>
><br>
> MOTIVATION:<br>
><br>
> 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:<br>
><br>
> - 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.<br>
><br>
> - 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.<br>
><br>
> - 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.<br>
><br>
> - 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.<br>
><br>
> - 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.<br>
><br>
> - 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.<br>
><br>
> - 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.<br>
><br>
> - 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 (<a href="https://github.com/apple/swift-evolution/pull/289" rel="noreferrer" target="_blank">https://github.com/apple/swift-evolution/pull/289</a> <<a href="https://github.com/apple/swift-evolution/pull/289" rel="noreferrer" target="_blank">https://github.com/apple/swift-evolution/pull/289</a>>).<br>
><br>
> - 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.<br>
><br>
> PROPOSED APPROACH:<br>
><br>
> 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.<br>
><br>
> The benefits of this approach are many:<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> 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 (<a href="https://github.com/apple/swift-evolution/pull/289" rel="noreferrer" target="_blank">https://github.com/apple/swift-evolution/pull/289</a> <<a href="https://github.com/apple/swift-evolution/pull/289" rel="noreferrer" target="_blank">https://github.com/apple/swift-evolution/pull/289</a>>) become viable, and the casting operators can be made to no longer act in ways that are often surprising and confusing.<br>
><br>
> 5. The programmer never has to deal with NSError objects in Swift code again.<br>
><br>
> DETAILED DESIGN:<br>
><br>
> 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.<br>
><br>
> 2. NSError’s conformance to ErrorProtocol is removed, since Swift code will generally no longer need to work directly with NSErrors.<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> IMPACT ON EXISTING CODE:<br>
><br>
> 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.<br>
><br>
> ALTERNATIVES CONSIDERED:<br>
><br>
> Do nothing, and let the terrorists win.<br>
><br>
> Charles<br>
><br>
><br>
> _______________________________________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://lists.swift.org/pipermail/swift-evolution/attachments/20160514/480f784a/attachment-0001.html" rel="noreferrer" target="_blank">https://lists.swift.org/pipermail/swift-evolution/attachments/20160514/480f784a/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 47<br>
Date: Sat, 14 May 2016 15:20:05 +1000<br>
From: Patrick Smith <<a href="mailto:pgwsmith@gmail.com">pgwsmith@gmail.com</a>><br>
To: Kevin Ballard <<a href="mailto:kevin@sb.org">kevin@sb.org</a>><br>
Cc: <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
Subject: Re: [swift-evolution] [Review] SE-0045: Add scan,<br>
prefix(while:), drop(while:), and iterate to the stdlib<br>
Message-ID: <<a href="mailto:9264E8FF-0A0E-4CC9-BF8E-51E0B67B5752@gmail.com">9264E8FF-0A0E-4CC9-BF8E-51E0B67B5752@gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Would there be any issue with the return type being AnySequence? It’s used in other areas:<br>
<br>
LazySequence & FlattenSequence’s<br>
dropFirst(n: Int) -> AnySequence<Generator.Element><br>
dropLast(n: Int) -> AnySequence<Generator.Element><br>
<br>
No need to introduce another type, and it’s straight forward to implement with AnySequence.<br>
<br>
<br>
> On 14 May 2016, at 5:07 AM, Kevin Ballard via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
><br>
> On Fri, May 13, 2016, at 11:08 AM, Erica Sadun wrote:<br>
>> On May 1, 2016, at 5:13 AM, Brent Royal-Gordon via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a> <mailto:<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>>> wrote:<br>
>>><br>
>>>> The proposal has been updated as per feedback from the core team (<a href="https://github.com/apple/swift-evolution/pull/275" rel="noreferrer" target="_blank">https://github.com/apple/swift-evolution/pull/275</a> <<a href="https://github.com/apple/swift-evolution/pull/275" rel="noreferrer" target="_blank">https://github.com/apple/swift-evolution/pull/275</a>>). This includes removing some last vestiges of Swift 2 naming as well as replacing `iterate(_:apply:)` with an overloaded function `unfold(_:applying:)`.<br>
>>><br>
>>> The proposal says this:<br>
>>><br>
>>> public func unfold<T, State>(_ initialState: State, applying: State -> (T, State)?) -> UnfoldSequence<T><br>
>>> public func unfold<T>(_ initialElement: T, apply: T -> T) -> UnfoldSequence<T><br>
>>><br>
>>> However, the comment implies that the second one should instead be this:<br>
>>><br>
>>> public func unfold<T>(_ initialElement: T, applying: T -> T?) -> UnfoldSequence<T><br>
>>><br>
>>> 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?<br>
>>><br>
>>> public func unfold<T, State>(fromState initialState: State, applying: State -> (T, State)?) -> UnfoldSequence<T><br>
>>> public func unfold<T>(fromFirst initialElement: T, apply: T -> T) -> UnfoldSequence<T><br>
>>><br>
>>> 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.)<br>
>><br>
>><br>
>> I really don't want to see this discussion die as I have a vested interest in getting this functionality into<br>
>> Swift 3. So let me suggest that<br>
>><br>
>> `sequence(_:, next:) -> AdHocSequence`<br>
>><br>
>> might be a Swift acceptable solution. We're not going to see fold/unfold pair happen. It's a given that<br>
>> `reduce` is a fixed point in Swift space and `sequence` well describes what this should be doing.<br>
>><br>
>> So is it possible to push forward with `sequence`, whose only negative seems to be that it's not as well<br>
>> loved as `unfold`?<br>
><br>
> 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.<br>
><br>
> 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).<br>
><br>
> So given that, I'll suggest the following:<br>
><br>
> func sequence<T>(initial: T, next: T -> T?) -> UnfoldSequence<T><br>
> func sequence<T, State>(state: State, next: (inout State) -> T?) -> UnfoldSequence<T><br>
><br>
> 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.<br>
><br>
> -Kevin Ballard<br>
> _______________________________________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://lists.swift.org/pipermail/swift-evolution/attachments/20160514/760d1ed4/attachment.html" rel="noreferrer" target="_blank">https://lists.swift.org/pipermail/swift-evolution/attachments/20160514/760d1ed4/attachment.html</a>><br>
<br>
------------------------------<br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br>
<br>
End of swift-evolution Digest, Vol 6, Issue 45<br>
**********************************************<br>
</blockquote></div><br></div></div></div>