Re: [swift-evolution] [Pitch] Generalized supertype constraints

[Dennis Weissmann via swift-evolution]

You’re right, I misunderstood that paragraph (maybe I read what I wanted to 
read :D). Thank you very much for the clarification and I’ll take a closer look 
at your proposal tomorrow!

- Dennis

Sent from my iPhone

> On 25. Nov 2017, at 10:37 PM, Adrian Zubarev 
>  wrote:
> 
> Well no, this proposal won’t allow your example. The problem in your example 
> actually has different roots - *Metatypes*. As by today, meta types are 
> somehow broken, especially in generic / associated type context. Furthermore 
> there is currently no way to express that you may want a subtype for an 
> existential metatype instead of the static metatype.
> 
> For more informations about meta types and who some of us would like them to 
> work, read our proposal here:
> https://github.com/DevAndArtist/swift-evolution/blob/refactor_existential_metatypes/proposals/0126-refactor-metatypes.md
> 
> Then your example could be expressed as:
> 
> ```
> func register(_ service: Service, ofType type: Type) where AnyType : 
> AnyType {}
> 
> // or if I’m not mistaken we can make use if implicit existential like this 
> then
> func register(_ service: Service, ofType type: Type) where S : Service 
> {}
> ```
> 
> I don't want to dive any deeper about the metatype pain points, because I 
> don’t want to prevent the success of the pitched idea with an off-topic.
> 
> 
> Am 25. November 2017 um 16:34:58, Dennis Weissmann 
> (den...@dennisweissmann.me) schrieb:
> 
>> I would also love to have generic associated types in the language, I have a 
>> lot of uses for them and, IIUC, supertype constraint would enable me to 
>> express the following:
>> 
>> protocol Service {}
>> 
>> protocol WikiService: Service {} // methods not shown for conciseness
>> class DefaultWikiService: WikiService {}
>> class DemoWikiService: WikiService {}
>> 
>> class DataServiceManager {
>> 
>> private var registry = [String: Service]()
>> 
>> func register(_ service: Service, ofType type: S.Type) where S: 
>> Service {
>> let key = "\(Swift.type(of: type))"
>> registry[key] = service
>> }
>> 
>> func service(ofType type: S.Type) -> S where S: Service {
>> let key = "\(Swift.type(of: type))"
>> 
>> // It is a programmer error to expect a value for a not yet 
>> registered type
>> guard let service = registry[key] as? S else {
>> fatalError("Service of type \(type) cannot be found. Please 
>> register a service for that type before accessing it.")
>> }
>> return service
>> }
>> 
>> }
>> 
>> let manager = DataServiceManager()
>> if isDemoMode {
>> manager.register(DemoWikiService(), ofType: WikiService.self) // 
>> Currently: error: in argument type 'WikiService.Protocol', 'WikiService' 
>> does not conform to expected type 'Service'
>> } else {
>> manager.register(DefaultWikiService(), ofType: WikiService.self) // 
>> Currently: error: in argument type 'WikiService.Protocol', 'WikiService' 
>> does not conform to expected type 'Service'
>> }
>> 
>> If that's right, I'm also +1 on this :)
>> 
>> - Dennis
>> 
>>> On Nov 25, 2017, at 12:13 AM, Adrian Zubarev via swift-evolution 
>>>  wrote:
>>> 
>>> In general this is more then welcome, so +1 for me.
>>> 
>>> However I have one question:
>>> 
>>> Could this allow support, or at least be a first step towards Swift 
>>> allowing the following behaviour?
>>> 
>>> ```
>>> extension MyProtocol where Self : SomeClass {
>>> static func getSubtypes(ofType _: T.Type = T.self) -> [T] where T : Self 
>>> { ... }
>>> }
>>> ```
>>> 
>>> I would like to be able to upgrade `Self` to a class constraint, which then 
>>> will allow me to only accept subtypes from T at compile time.
>>> 
>>> Am 25. November 2017 um 00:03:23, Matthew Johnson via swift-evolution 
>>> (swift-evolution@swift.org) schrieb:
>>> 
 One of the most frequent frustrations I encounter when writing generic 
 code in Swift is the requirement that supertype constraints be concrete.  
 When I mentioned this on Twitter 
 (https://twitter.com/anandabits/status/929958479598534656) Doug Gregor 
 mentioned that this feature is smaller and mostly straightforward to 
 design and implement 
 (https://twitter.com/dgregor79/status/929975472779288576). 
 
 I currently have a PR open to add the high-level description of this 
 feature found below to the generics manifesto 
 (https://github.com/apple/swift/pull/13012):
 
 Currently, supertype constraints may only be specified using a concrete 
 class or protocol type.  This prevents us from abstracting over the 
 supertype.
 
 ```swift
 protocol P {
   associatedtype Base
   associatedtype Derived: Base
 }
 ```
 
 In the above example `Base` may be any type.  `Derived` may be the same as 
 `Base` or may be _any_ subtype of `Base`.  All subtype relationships 
 supported by Swift should be supported in this context including, but not 
 l

Re: [swift-evolution] [Pitch] Generalized supertype constraints

[Dennis Weissmann via swift-evolution]

I would also love to have generic associated types in the language, I have a 
lot of uses for them and, IIUC, supertype constraint would enable me to express 
the following:

protocol Service {}

protocol WikiService: Service {} // methods not shown for conciseness
class DefaultWikiService: WikiService {}
class DemoWikiService: WikiService {}

class DataServiceManager {

private var registry = [String: Service]()

func register(_ service: Service, ofType type: S.Type) where S: Service {
let key = "\(Swift.type(of: type))"
registry[key] = service
}

func service(ofType type: S.Type) -> S where S: Service {
let key = "\(Swift.type(of: type))"

// It is a programmer error to expect a value for a not yet registered 
type
guard let service = registry[key] as? S else {
fatalError("Service of type \(type) cannot be found. Please 
register a service for that type before accessing it.")
}
return service
}

}

let manager = DataServiceManager()
if isDemoMode {
manager.register(DemoWikiService(), ofType: WikiService.self) // Currently: 
error: in argument type 'WikiService.Protocol', 'WikiService' does not conform 
to expected type 'Service'
} else {
manager.register(DefaultWikiService(), ofType: WikiService.self) // 
Currently: error: in argument type 'WikiService.Protocol', 'WikiService' does 
not conform to expected type 'Service'
}

If that's right, I'm also +1 on this :)

- Dennis

> On Nov 25, 2017, at 12:13 AM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> In general this is more then welcome, so +1 for me.
> 
> However I have one question:
> 
> Could this allow support, or at least be a first step towards Swift allowing 
> the following behaviour?
> 
> ```
> extension MyProtocol where Self : SomeClass {
>   static func getSubtypes(ofType _: T.Type = T.self) -> [T] where T : 
> Self { ... }
> }
> ```
> 
> I would like to be able to upgrade `Self` to a class constraint, which then 
> will allow me to only accept subtypes from T at compile time.
> 
> Am 25. November 2017 um 00:03:23, Matthew Johnson via swift-evolution 
> (swift-evolution@swift.org ) schrieb:
> 
>> One of the most frequent frustrations I encounter when writing generic code 
>> in Swift is the requirement that supertype constraints be concrete.  When I 
>> mentioned this on Twitter 
>> (https://twitter.com/anandabits/status/929958479598534656 
>> ) Doug Gregor 
>> mentioned that this feature is smaller and mostly straightforward to design 
>> and implement (https://twitter.com/dgregor79/status/929975472779288576 
>> ).
>> 
>> I currently have a PR open to add the high-level description of this feature 
>> found below to the generics manifesto 
>> (https://github.com/apple/swift/pull/13012 
>> ):
>> 
>> Currently, supertype constraints may only be specified using a concrete 
>> class or protocol type.  This prevents us from abstracting over the 
>> supertype.
>> 
>> ```swift
>> protocol P {
>>   associatedtype Base
>>   associatedtype Derived: Base
>> }
>> ```
>> 
>> In the above example `Base` may be any type.  `Derived` may be the same as 
>> `Base` or may be _any_ subtype of `Base`.  All subtype relationships 
>> supported by Swift should be supported in this context including, but not 
>> limited to, classes and subclasses, existentials and conforming concrete 
>> types or refining existentials, `T?` and  `T`, `((Base) -> Void)` and 
>> `((Derived) -> Void)`, etc.
>> 
>> Generalized supertype constraints would be accepted in all syntactic 
>> locations where generic constraints are accepted.
>> 
>> I would like to see generalized supertype constraints make it into Swift 5 
>> if possible.  I am not an implementer so I will not be able to bring a 
>> proposal forward alone but am interested in collaborating with anyone 
>> interested in working on implementation.
>> 
>> I am also interested in hearing general feedback on this feature from the 
>> community at large.  Have you also found this limitation frustrating?  In 
>> what contexts?  Does anyone have reservations about introducing this 
>> capability?  If so, what are they?
>> 
>> Matthew
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

[Dennis Weissmann via swift-evolution]

I think discovering them is not the problem, the question is if you really want 
them to be annotated pro-actively by the compiler - I don't think so.

Your comparison with @escape is both right and wrong :) It's wrong in the sense 
that @escaping is a relaxing attribute while @pure is a constraining one.

You can pass a non-escaping closure where an escaping one is required, but no 
the other way around.
This would be equivalent to an (relaxing) @impure attribute, you could still 
pass a pure function wherever an impure one is required but no the other way 
around.

With @pure it's the other way around, you cannot pass an impure function where 
a pure one is required.

Imagine the compiler annotating every pure function automatically with @pure, 
you could not override it with an impure function even though you maybe never 
though of making it pure, it just happened by accident.

- Dennis

> On Feb 16, 2017, at 10:25 PM, Sean Heber via swift-evolution 
>  wrote:
> 
> Couldn’t pure functions be discovered by the compiler like how the compiler 
> already discovers an escaping vs. non-escaping function? Then perhaps pure 
> only needs to be an attribute on closure parameter - just like how @escaping 
> works?
> 
> l8r
> Sean
> 
> 
>> On Feb 16, 2017, at 3:18 PM, T.J. Usiyan via swift-evolution 
>>  wrote:
>> 
>> I am ok with a keyword but `pure` in front of func doesn't work well with 
>> inline closures.
>> 
>> A few people talked through many of these issues starting with this tweet. 
>> https://twitter.com/griotspeak/status/832247545325842432
>> 
>> On Thu, Feb 16, 2017 at 4:13 PM, Jonathan Hull  wrote:
>> +1 for the idea of pure functions in swift.  Seems like it would enable a 
>> lot of good optimizations (in some cases even just evaluating the function 
>> at compile time).
>> 
>> -1 on the specific notation.  I would much rather just put the word ‘pure’ 
>> in front of ‘func’, the same way we put ‘mutating' in front of mutating 
>> functions… it seems to me like these are part of the same family.
>> 
>> I agree we should allow inout.
>> 
>> Thanks,
>> Jon
>> 
>>> On Feb 16, 2017, at 9:03 AM, T.J. Usiyan via swift-evolution 
>>>  wrote:
>>> 
>>> # Pure Functions
>>> 
>>> * Proposal: 
>>> [SE-](https://github.com/apple/swift-evolution/blob/master/proposals/-name.md)
>>> * Author(s): [TJ Usiyan](https://github.com/griotspeak)
>>> * Status: **Awaiting review**
>>> * Review manager: TBD
>>> 
>>> ## Introduction
>>> 
>>> Some functions are, essentially, only meant to be transformations of their 
>>> input and–as such–do not and should not reference any variables other than 
>>> those passed in. These same functions are not meant to have any effects 
>>> other than the aforementioned transformation of input. Currently, Swift 
>>> cannot assist the developer and confirm that any given function is one of 
>>> these 'pure' functions. To facilitate this, this proposal adds syntax to 
>>> signal that a function is 'pure'.
>>> 
>>> 'pure', in this context, means:
>>> 1. The function must have a return value
>>> 1. This function can only call other pure functions
>>> 1. This function cannot access/modify global or static variables.
>>> 
>>> ## Motivation
>>> 
>>> Consider the following example where `_computeNullability(of:)` is meant to 
>>> create its output solely based on the provided recognizer.
>>> 
>>> ```
>>> class Recognizer {
>>> var nullabilityMemo: Bool?
>>> var isNullable: Bool {
>>> func _computeNullability(of recognizer: Recognizer) -> Bool {…}
>>> if let back = nullabilityMemo {
>>> return back 
>>> } else {
>>> let back =  _computeNullability(of: self)
>>> nullabilityMemo = back
>>> return back
>>> }
>>> }
>>> }
>>> ```
>>> if `_computeNullability(of:)` is recursive at all, there exists a real 
>>> potential to accidentally reference `self` in its body and the mistake, 
>>> depending on circumstance, can be terribly subtle. Converting 
>>> `_computeNullability(of:)` to a `static` function is an option but 
>>> obfuscates the fact that it is *only* to be called within `isNullable`.
>>> 
>>> 
>>> ## Proposed solution
>>> 
>>> Given the ability to indicate that `_computeNullability(of:)` is a 'pure' 
>>> function, the developer gains assurance from the tooling that it doesn't 
>>> reference anything or cause any side effects.
>>> 
>>> 
>>> ```
>>> class Recognizer {
>>> var nullabilityMemo: Bool?
>>> var isNullable: Bool {
>>> pfunc _computeNullability(of recognizer: Recognizer) -> Bool {…}
>>> if let back = nullabilityMemo {
>>> return back 
>>> } else {
>>> let back =  _computeNullability(of: self)
>>> nullabilityMemo = back
>>> return back
>>> }
>>> }
>>> }
>>> ```
>>> 
>>> ## Detailed desig

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

[Dennis Weissmann via swift-evolution]

> On Feb 16, 2017, at 10:24 PM, David Sweeris  wrote:
> 
> 
>> On Feb 16, 2017, at 13:10, Dennis Weissmann via swift-evolution 
>>  wrote:
>> 
>> Secondly, are they inherited? So if ClassA has a pure function a(), can I 
>> override it in subclass ClassB: ClassA to be impure? (I think no)
> 
> I would agree. IIUC, the "pureness" of A's implementation of a() becomes a 
> moot point if B's implementation doesn't have to have at least as strong of a 
> constraint,  because otherwise all the optimizations that the compiler makes 
> would break as soon as someone passes a B in instead of an A.
> 
>> Can I annotate a function in a protocol to force it to be pure? (not sure 
>> about this one)
> 
> I would say yes, for similar reasons: if the attribute doesn't hold for *all* 
> implementations, the compiler can't assume it holds for any. At least not 
> with the way generics work now, IIUC.
> 

That makes a lot of sense and would be consistent with @escaping's behavior.

> - Dave Sweeris.



smime.p7s
Description: S/MIME cryptographic signature
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

[Dennis Weissmann via swift-evolution]

Big +1 from me for the concept, thanks for proposing this, here's some "but"'s 
that came to my mind after a quick read:

I don't quite like the introduction of a new function arrow, in the end (in my 
opinion) this is just a more special, more constrained version of a normal 
function. For me, "pure" feels more like an attribute, describing how a 
function differs from a "normal" function, see @escaping, etc. (I could imagine 
having an @total too, but I think the implementation of that is a bit more 
involved :-)) Have you thought about `@pure`? If so why did you decide against 
it?

Secondly, are they inherited? So if ClassA has a pure function a(), can I 
override it in subclass ClassB: ClassA to be impure? (I think no)
Can I annotate a function in a protocol to force it to be pure? (not sure about 
this one)

- Dennis

> On Feb 16, 2017, at 6:03 PM, T.J. Usiyan via swift-evolution 
>  wrote:
> 
> # Pure Functions
> 
> * Proposal: 
> [SE-](https://github.com/apple/swift-evolution/blob/master/proposals/-name.md
>  
> )
> * Author(s): [TJ Usiyan](https://github.com/griotspeak 
> )
> * Status: **Awaiting review**
> * Review manager: TBD
> 
> ## Introduction
> 
> Some functions are, essentially, only meant to be transformations of their 
> input and–as such–do not and should not reference any variables other than 
> those passed in. These same functions are not meant to have any effects other 
> than the aforementioned transformation of input. Currently, Swift cannot 
> assist the developer and confirm that any given function is one of these 
> 'pure' functions. To facilitate this, this proposal adds syntax to signal 
> that a function is 'pure'.
> 
> 'pure', in this context, means:
> 1. The function must have a return value
> 1. This function can only call other pure functions
> 1. This function cannot access/modify global or static variables.
> 
> ## Motivation
> 
> Consider the following example where `_computeNullability(of:)` is meant to 
> create its output solely based on the provided recognizer.
> 
> ```
> class Recognizer {
>   var nullabilityMemo: Bool?
>   var isNullable: Bool {
>   func _computeNullability(of recognizer: Recognizer) -> Bool {…}
>   if let back = nullabilityMemo {
>   return back 
>   } else {
>   let back =  _computeNullability(of: self)
>   nullabilityMemo = back
>   return back
>   }
>   }
> }
> ```
> if `_computeNullability(of:)` is recursive at all, there exists a real 
> potential to accidentally reference `self` in its body and the mistake, 
> depending on circumstance, can be terribly subtle. Converting 
> `_computeNullability(of:)` to a `static` function is an option but obfuscates 
> the fact that it is *only* to be called within `isNullable`.
> 
> 
> ## Proposed solution
> 
> Given the ability to indicate that `_computeNullability(of:)` is a 'pure' 
> function, the developer gains assurance from the tooling that it doesn't 
> reference anything or cause any side effects.
> 
> 
> ```
> class Recognizer {
>   var nullabilityMemo: Bool?
>   var isNullable: Bool {
>   pfunc _computeNullability(of recognizer: Recognizer) -> Bool {…}
>   if let back = nullabilityMemo {
>   return back 
>   } else {
>   let back =  _computeNullability(of: self)
>   nullabilityMemo = back
>   return back
>   }
>   }
> }
> ```
> 
> ## Detailed design
> 
> This proposal introduces a new annotation `=>`, which is to be accepted 
> everywhere `->` currently is. Members created using this kewyord must follow 
> the rules listed in the introduction.
> 
> ## Impact on existing code
> 
> This is an additive feature unless alternative 2 is chosen and, as such, 
> should not require an effect on existing code. It could be used to annotate 
> closures accepted by methods in the standard library such as `map`, `filter`, 
> and `reduce`. While this would fit well with their typical use, such a change 
> is not necessarily part of this proposal.
> 
> ## Alternatives considered
> 
> It should be noted that neither of these alternatives can remain consistent 
> for inline closures.
> 1. keyword `pfunc` (pronounciation: pifəŋk) for 'pure' functions. 
> 2. `proc` keyword for 'impure' functions and 'func' for 'pure' functions. 
> This would be a massively source breaking change and, as such, is unlikely to 
> have any feasibility. It is, however, the most clean semantically, in my 
> opinion.
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution



smime.p7s
Description: S/MIME crypto

Re: [swift-evolution] [draft] Compound Names For Enum Cases

[Dennis Weissmann via swift-evolution]

I'm also +1 on this, wanted this for a long time :)

- Dennis

> On Feb 2, 2017, at 2:42 PM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> Great, thanks. Love it :) 
> 
> +1 
> 
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 2. Februar 2017 um 14:39:43, Daniel Duan (dan...@duan.org 
> ) schrieb:
> 
>> This has been answered in various forms in the thread. Short answer: yes.
>> 
>> On Feb 2, 2017, at 2:05 AM, Adrian Zubarev > > wrote:
>> 
>>> Is that correct that this proposal will add some sort of overloading enum 
>>> cases by different labels?
>>> 
>>> enum Foo {
>>> case foo(a: Int)
>>> case foo(a: Int, b: Int)
>>> }   
>>> Is Foo a valid enum after this proposal?
>>> 
>>> 
>>> 
>>> -- 
>>> Adrian Zubarev
>>> Sent with Airmail
>>> 
>>> Am 19. Januar 2017 um 19:37:50, Daniel Duan via swift-evolution 
>>> (swift-evolution@swift.org ) schrieb:
>>> 
 Hi all,
 
 Here’s a short proposal for fixing an inconsistency in Swift’s enum. 
 Please share you feedback :)
 
 (Updating/rendered version: 
 https://github.com/dduan/swift-evolution/blob/compound-names-for-enum-cases/proposals/-Compound-Names-For-Enum-Cases.md
  
 )
 
 
 ## Introduction
 
 Argument labels are part of its function's declaration name. An enum case
 declares a function that can be used to construct enum values. For cases 
 with
 associated values, their labels should be part of the constructor name, 
 similar
 to "normal" function and methods. In Swift 3, however, this is not true. 
 This
 proposal aim to change that.
 
 ## Motivation
 
 After SE-0111, Swift function's fully qualified name consists of its base 
 name
 and all argument labels. As a example, one can invoke a function with its
 fully name:
 
 ```swift
 func f(x: Int, y: Int) {}
 
 f(x: y:)(0, 0) // Okay, this is equivalent to f(x: 0, y: 0)
 ```
 
 This, however, is not true when enum cases with associated value were
 constructed:
 
 ```swift
 enum Foo {
 case bar(x: Int, y: Int)
 }
 
 Foo.bar(x: y:)(0, 0) // Does not compile as of Swift 3
 ```
 
 Here, the declared name for the case is `foo`; it has a tuple with two 
 labeled
 fields as its associated value. `x` and `y` aren't part of the case name. 
 This
 inconsistency may surprise some users.
 
 Using tuple to implement associated value also limits us from certain 
 layout
 optimizations as each payload need to be a tuple first, as opposed to 
 simply be
 unique to the enum.
 
 ## Proposed solution
 
 Include labels in enum case's declaration name. In the last example, 
 `bar`'s
 full name would become `bar(x:y:)`, `x` and `y` will no longer be labels 
 in a
 tuple. The compiler may also stop using tuple to represent associated 
 values.
 
 ## Detailed design
 
 When labels are present in enum cases, they are now part of case's 
 declared name
 instead of being labels for fields in a tuple. In details, when 
 constructing an
 enum value with the case name, label names must either be supplied in the
 argument list it self, or as part of the full name.
 
 ```swift
 Foo.bar(x: 0, y: 0) // Okay, the Swift 3 way.
 Foo.bar(x: y:)(0, 0) // Equivalent to the previous line.
 Foo.bar(x: y:)(x: 0, y: 0) // This would be an error, however.
 ```
 
 Note that since the labels aren't part of a tuple, they no longer 
 participate in
 type checking, similar to functions:
 
 ```swift
 let f = Foo.bar // f has type (Int, Int) -> Foo
 f(0, 0) // Okay!
 f(x: 0, y: 0) // Won't compile.
 ```
 
 ## Source compatibility
 
 Since type-checking rules on labeled tuple is stricter than that on 
 function
 argument labels, existing enum value construction by case name remain 
 valid.
 This change is source compatible with Swift 3.
 
 ## Effect on ABI stability and resilience
 
 This change introduces compound names for enum cases, which affects their
 declaration's name mangling.
 
 The compiler may also choose to change enum payload's representation from 
 tuple.
 This may open up more space for improving enum's memory layout.
 
 ## Alternatives considered
 
 Keep current behaviors, which means we live with the inconsistency.
 
 ___
 swift-evolution mailing list
 swift-evolution@swift.org 
 https://lists.swift.org/mailman/listinfo/swift-evolution 
 

Re: [swift-evolution] [Pitch] Tuple Destructuring in Parameter Lists

[Dennis Weissmann via swift-evolution]

> I like the idea of allowing destructuring everywhere we bind a name very 
> much.  My only (minor) concern with doing this for tuples right now is that 
> it might encourage overuse of them where a struct would be a better choice.  
> 
> I have been thinking about destructuring of structs and classes and wonder if 
> it might be best to introduce that first.  That would avoid any temptation to 
> abuse tuples just because they can be destructured.  This is probably an 
> overblown concern but it is something to consider.   


That’s interesting! I haven’t had the time to look at destructuring of structs 
and classes but a quick look at how it’s done in Rust and looks promising.
It’s a fair point you made, I don’t have a problem delaying this proposal. 

- Dennis

> On May 30, 2016, at 4:14 PM, Matthew Johnson  wrote:
> 
> 
> 
> Sent from my iPad
> 
> On May 30, 2016, at 8:01 AM, Brent Royal-Gordon via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
>>> // Allowed today:
>>> func takesATuple(tuple: (Int, Int)) {
>>> let valueA = tuple.0
>>> let valueB = tuple.1
>>> // ...
>>> }
>>> 
>>> // Proposed syntax:
>>> func takesATuple(tuple (valueA, valueB): (Int, Int)) {
>>> // use valueA
>>> // use valueB
>>> }
>> 
>> Personally, I find this example confusing because the label is "tuple", 
>> which kind of reads like a keyword, and because you're using the same name 
>> for the label and variable. If I understand the semantics you're proposing 
>> correctly, I think it would be clearer to write this example like:
>> 
>> // Allowed today:
>> func takes(a tuple: (Int, Int)) {
>> let valueA = tuple.0
>> let valueB = tuple.1
>> // ...
>> }
>> 
>> // Proposed syntax:
>> func takes(a (valueA, valueB): (Int, Int)) {
>> // use valueA
>> // use valueB
>> }
>> 
>> Incidentally, it may also be a good idea to define what happens if you write:
>> 
>> func takes((valueA, valueB): (Int, Int))
>> 
>> Normally, if there's no separate label and variable name, they're the same, 
>> but you can't have a label like `(valueA, valueB)`. I see two reasonably 
>> sensible answers here:
>> 
>> 1. It's equivalent to writing `_ (valueA, valueB)`.
>> 2. It's illegal. You have to write a label, or `_` if you don't want one.
>> 
>> My preference would be for #2, but you're the designer, not me.
> 
> I agree.  #2 is more consistent with Swift 3 where all arguments have 
> external names by default.  I don't think this should change just because 
> there is no direct internal name that can also serve as an external name.
> 
> I like the idea of allowing destructuring everywhere we bind a name very 
> much.  My only (minor) concern with doing this for tuples right now is that 
> it might encourage overuse of them where a struct would be a better choice.  
> 
> I have been thinking about destructuring of structs and classes and wonder if 
> it might be best to introduce that first.  That would avoid any temptation to 
> abuse tuples just because they can be destructured.  This is probably an 
> overblown concern but it is something to consider.   
> 
> Another option would be to just introduce a related proposal to destructure 
> structs and classes at roughly the same time as the parameter destructuring 
> proposal...
> 
>> 
>> -- 
>> Brent Royal-Gordon
>> Architechies
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Tuple Destructuring in Parameter Lists

[Dennis Weissmann via swift-evolution]

Great catch! I didn’t know that was possible! I’ll add it to the proposal. 
Thanks!

- Dennis

> On May 30, 2016, at 3:53 PM, Vladimir.S  wrote:
> 
> I believe you should add currently available syntax to proposal text:
> 
> let c = zip(a,b).reduce(0) { (acc, tuple: (a: Int, b: Int)) in
>  acc + tuple.a + tuple.b
> }
> 
> func takesATuple(tuple : (valueA: Int, valueB: Int)) {
>  print("a: \(tuple.valueA) b:\(tuple.valueB)")
> }
> 
> Not so nice as proposed, but not so ugly as just tuple.0.
> I'm not sure if the proposed feature is adding important improvement to the 
> language.
> 
> On 30.05.2016 0:20, Dennis Weissmann via swift-evolution wrote:
>> Thanks for everyone participating in this discussion! :)
>> I’ve drafted a formal proposal, it is available
>> here: 
>> https://github.com/dennisweissmann/swift-evolution/blob/tuple-destructuring/proposals/-tuple-destructuring.md
>> 
>> Please let me know what you think (it would be great if a native speaker
>> could take a look at grammar and spelling mistakes). Thanks!
>> 
>> 
>>  Tuple Destructuring in Parameter Lists
>> 
>>  * Proposal: SE-
>>
>> <https://github.com/apple/swift-evolution/blob/master/proposals/-name.md>
>>  * Author(s): Dennis Weissmann <https://github.com/dennisweissmann>
>>  * Status: *Awaiting review*
>>  * Review manager: TBD
>> 
>> 
>>Introduction
>> 
>> Tuple destructuring is the process of extracting elements from tuples.
>> 
>> This is valid today:
>> 
>> Swift
>> 
>> |let point = (x: 20.0, y: 31.0, z: 42.0) // Approach 1: let x = point.x let
>> y = point.y let z = point.z // Approach 2: let (x, y, z) = point // For-in
>> loops support tuple destructuring for (x, y, z) in [point] { // use x, y, z 
>> }|
>> 
>> Swift-evolution thread: [Pitch] Tuple Destructuring in Parameter Lists
>> <http://thread.gmane.org/gmane.comp.lang.swift.evolution/16190>
>> 
>> 
>>Motivation
>> 
>> This proposal seeks to generalize this behavior for every use case where
>> tuples need to be destructured. These are parameter lists in closures and
>> parameter lists in functions. Consistency is a major goal of Swift but it
>> is currently only possible to destructure tuples in the above mentioned 
>> places.
>> 
>> 
>>Proposed solution
>> 
>> Extending tuple destructuring to parameter lists seems natural and improves
>> consistency in the language.
>> 
>> 
>>  Closures
>> 
>> Parameters in closures are currently not directly destructable. They can
>> either be accessed via |.0|, |.1|, etc. or can be destructured by assigning
>> them to variables in an explicit statement.
>> 
>> It feels natural to do this right in the parameter list itself (just like
>> with for-in loops).
>> 
>> Swift
>> 
>> |let a = [0,1,2,3,4,5,6,7,8,9] let b = [0,1,2,3,4,5,6,7,8,9] // Allowed
>> today: let c = zip(a,b).reduce(0) { acc, tuple in acc + tuple.0 + tuple.1 }
>> // Also allowed today: let c = zip(a,b).reduce(0) { acc, tuple in let
>> (valueA, valueB) = tuple return acc + valueA + valueB } // Proposed syntax:
>> let c = zip(a,b).reduce(0) { acc, (valueA, valueB) in acc + valueA + valueB 
>> }|
>> 
>> 
>>  Functions
>> 
>> When it comes to functions this proposal uses Swift's feature of
>> differentiating between internal and external parameter names.
>> 
>> Swift
>> 
>> |// Allowed today: func takesATuple(tuple: (Int, Int)) { let valueA =
>> tuple.0 let valueB = tuple.1 // ... } // Proposed syntax: func
>> takesATuple(tuple (valueA, valueB): (Int, Int)) { // use valueA // use
>> valueB }|
>> 
>> This design has no visible effects to the call site of a function but makes
>> it very convenient for the function author to use the tuple's elements
>> inside the function body.
>> 
>> 
>>Impact on existing code
>> 
>> This feature is strictly additive and does not effect current code.
>> 
>> 
>>Alternatives considered
>> 
>> Leave it as is destructure in a separate assignment.
>> 
>> 
>> 
>> - Dennis
>> 
>>> On May 11, 2016, at 10:12 AM, Dennis Weissmann via swift-evolution
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> Thanks for all your feedback!
>>> 
>>> This is the current statistic:
>>> Closure syntax: All positive
>>> Function syntax: 3 (or 4) positive, 2 negative
>

Re: [swift-evolution] [Pitch] Tuple Destructuring in Parameter Lists

[Dennis Weissmann via swift-evolution]

Hi Brent,

Thanks! Those are great points!

I haven’t thought about the possibility of suppressing the external label. I 
like your option 2 very much! I’ll add it to the proposal and change the used 
variable names. 

- Dennis

> On May 30, 2016, at 3:01 PM, Brent Royal-Gordon  
> wrote:
> 
>> // Allowed today:
>> func takesATuple(tuple: (Int, Int)) {
>>  let valueA = tuple.0
>>  let valueB = tuple.1
>>  // ...
>> }
>> 
>> // Proposed syntax:
>> func takesATuple(tuple (valueA, valueB): (Int, Int)) {
>>  // use valueA
>>  // use valueB
>> }
> 
> Personally, I find this example confusing because the label is "tuple", which 
> kind of reads like a keyword, and because you're using the same name for the 
> label and variable. If I understand the semantics you're proposing correctly, 
> I think it would be clearer to write this example like:
> 
> // Allowed today:
> func takes(a tuple: (Int, Int)) {
>  let valueA = tuple.0
>  let valueB = tuple.1
>  // ...
> }
> 
> // Proposed syntax:
> func takes(a (valueA, valueB): (Int, Int)) {
>  // use valueA
>  // use valueB
> }
> 
> Incidentally, it may also be a good idea to define what happens if you write:
> 
> func takes((valueA, valueB): (Int, Int))
> 
> Normally, if there's no separate label and variable name, they're the same, 
> but you can't have a label like `(valueA, valueB)`. I see two reasonably 
> sensible answers here:
> 
> 1. It's equivalent to writing `_ (valueA, valueB)`.
> 2. It's illegal. You have to write a label, or `_` if you don't want one.
> 
> My preference would be for #2, but you're the designer, not me.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Tuple Destructuring in Parameter Lists

[Dennis Weissmann via swift-evolution]

Thanks for everyone participating in this discussion! :)
I’ve drafted a formal proposal, it is available here: 
https://github.com/dennisweissmann/swift-evolution/blob/tuple-destructuring/proposals/-tuple-destructuring.md

Please let me know what you think (it would be great if a native speaker could 
take a look at grammar and spelling mistakes). Thanks!
Tuple Destructuring in Parameter Lists
Proposal: SE- 
<https://github.com/apple/swift-evolution/blob/master/proposals/-name.md>
Author(s): Dennis Weissmann <https://github.com/dennisweissmann>
Status: Awaiting review 

Review manager: TBD
Introduction
Tuple destructuring is the process of extracting elements from tuples.

This is valid today:

Swift
let point = (x: 20.0, y: 31.0, z: 42.0)
// Approach 1:
let x = point.x
let y = point.y
let z = point.z

// Approach 2:
let (x, y, z) = point

// For-in loops support tuple destructuring
for (x, y, z) in [point] {
  // use x, y, z
}
Swift-evolution thread: [Pitch] Tuple Destructuring in Parameter Lists 
<http://thread.gmane.org/gmane.comp.lang.swift.evolution/16190>
Motivation
This proposal seeks to generalize this behavior for every use case where tuples 
need to be destructured. These are parameter lists in closures and parameter 
lists in functions. Consistency is a major goal of Swift but it is currently 
only possible to destructure tuples in the above mentioned places.

Proposed solution
Extending tuple destructuring to parameter lists seems natural and improves 
consistency in the language.

Closures

Parameters in closures are currently not directly destructable. They can either 
be accessed via .0, .1, etc. or can be destructured by assigning them to 
variables in an explicit statement.

It feels natural to do this right in the parameter list itself (just like with 
for-in loops).

Swift
let a = [0,1,2,3,4,5,6,7,8,9]
let b = [0,1,2,3,4,5,6,7,8,9]

// Allowed today:
let c = zip(a,b).reduce(0) { acc, tuple in
  acc + tuple.0 + tuple.1
}

// Also allowed today:
let c = zip(a,b).reduce(0) { acc, tuple in
  let (valueA, valueB) = tuple
  return acc + valueA + valueB
}

// Proposed syntax:
let c = zip(a,b).reduce(0) { acc, (valueA, valueB) in
  acc + valueA + valueB
}
Functions

When it comes to functions this proposal uses Swift's feature of 
differentiating between internal and external parameter names.

Swift
// Allowed today:
func takesATuple(tuple: (Int, Int)) {
  let valueA = tuple.0
  let valueB = tuple.1
  // ...
}

// Proposed syntax:
func takesATuple(tuple (valueA, valueB): (Int, Int)) {
  // use valueA
  // use valueB
}
This design has no visible effects to the call site of a function but makes it 
very convenient for the function author to use the tuple's elements inside the 
function body.

Impact on existing code
This feature is strictly additive and does not effect current code.

Alternatives considered
Leave it as is destructure in a separate assignment.



- Dennis

> On May 11, 2016, at 10:12 AM, Dennis Weissmann via swift-evolution 
>  wrote:
> 
> Thanks for all your feedback!
> 
> This is the current statistic:
> Closure syntax: All positive
> Function syntax: 3 (or 4) positive, 2 negative
> 
> I’ll try to address the concern Geordie and T.J. have.
> 
>> func takesATuple(someInt: Int, tuple: (valueA: String, valueB: String)) {}
> 
>> It’s true that you still have the ‚overhead‘ of having to type tuple. before 
>> accessing its members. But this is almost always what I want (hopefully 
>> you’d never actually name your tuple ‚tuple‘, instead it’d be a logical 
>> namespace for what it contains). Do you have a real-world example where 
>> you’d need this? To me it seems that in a case like this the API that 
>> produced the tuple would need refining rather than the language itself.
> 
> 
> What you suggest here is not tuple destructuring but using labeled tuples. 
> And while I’m totally with you that this is for many cases the better 
> approach, I still think we should introduce it to functions as well, for 
> consistency and readability reasons.
> In the end inconsistency is what led to this thread because tuple 
> destructuring is already possible today - in for loops:
> 
> let stringTuple = [("", "”), ("", "")]
> for (i, j) in stringTuple {}
> 
> That made me wonder if it’s also possible for closures (because I needed it 
> there - and eventually someone will definitely wonder if it’s possible for 
> function arguments as well).
> 
> You also asked me for my use case. To be honest, I don’t have one for the 
> function version, but imagine the following:
> 
> My current closure use case is this (template.points and resampledPoints are 
> of type [CGPoint]):
> 
> let localHighestSimilarity = zip(template.points, 
> resampledPoints).reduce(0.0) { accumulator, point

Re: [swift-evolution] [Pitch] Make `return` optional in computed properties for a single case

[Dennis Weissmann via swift-evolution]

+ 1 from me as well for the already stated reasons.

- Dennis

> On May 28, 2016, at 2:15 AM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> 
> 
> Sent from my iPad
> 
> On May 27, 2016, at 6:15 PM, Brent Royal-Gordon via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
>>> The idea is simple:
>>> 
>>>   • Can we make return keyword optional in cases like this?
>>>   • Shouldn’t this behave like @autoclosure or @noescape?
>> 
>> This actually doesn't have anything to do with @autoclosure or @noescape. 
>> Any one-expression closure can omit the `return` statement and have an 
>> inferred return type.
>> 
>>> type A {
>>>   var characters: [Character] = …
>>>   var string: String { String(self.characters) }
>>>   var count: Int { 42 }
>>> }
>> 
>> Despite those inaccuracies, I do think that it's a good idea to permit 
>> single-expression accessors to omit the `return` statement; it will make 
>> them much less clunky. I would even extend this to cases where you use the 
>> `get` keyword:
>> 
>>   var string: String {
>>   get { String(self.characters) }
>>   set { characters = Array(newValue.characters) }
>>   }
> 
> +1.  And in single-expression functions as well.  This is something that 
> should be consistent and allowed everywhere in the language.
> 
>> 
>> -- 
>> Brent Royal-Gordon
>> Architechies
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions

[Dennis Weissmann via swift-evolution]

Awesome! :) You are too fast to follow up!

- Dennis
Sent from my iPhone

> On May 13, 2016, at 7:02 AM, Chris Lattner  wrote:
> 
> On May 12, 2016, at 12:59 AM, Dennis Weissmann via swift-evolution 
>  wrote:
>>>> let item = DispatchWorkItem(qos: .qosUserInitiated) {
>>>> print("Hello World")
>>>> }
>>>> 
>>>> I’d change the enum case from .qosUserInitiated to .userInitiated (maybe 
>>>> that’s just a typo since in the code example before uses .unspecified).
>>> 
>>> I think it is a typo, only default needs to be qosDefault because default 
>>> is a keyword, and asking all users to back-tick it isn’t really good either.
>>> (also no one should really specify qos class default anyway).
>> 
>> Even .default should be okay once SE-0071 is implemented.
> 
> SE-0071 is implemented already.
> 
> -Chris


smime.p7s
Description: S/MIME cryptographic signature
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions

[Dennis Weissmann via swift-evolution]

- Dennis

> On May 12, 2016, at 9:34 AM, Pierre Habouzit  wrote:
> 
>> On May 11, 2016, at 9:02 AM, Dennis Weissmann via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> 1. What is your evaluation of the proposal?
>> +1 I think this is a big win for readability.
>> 
>> 2. Is the problem being addressed significant enough to warrant a change to 
>> Swift?
>> Yes. dispatch is used nearly everywhere so many many projects would benefit 
>> from it.
>> 
>> 3. Does this proposal fit well with the feel and direction of Swift?
>> Making the API more “swift" and feel more natural definitely is the 
>> direction Swift libraries are / should be going in.
>> 
>> 4. If you have used other languages or libraries with a similar feature, how 
>> do you feel that this proposal compares to those?
>> Unfortunately not.
>> 
>> 5. How much effort did you put into your review? A glance, a quick reading, 
>> or an in-depth study?
>> Read the proposal twice.
>> 
>> A little nitpick:
>> 
>> let item = DispatchWorkItem(qos: .qosUserInitiated) {
>> print("Hello World")
>> }
>> 
>> I’d change the enum case from .qosUserInitiated to .userInitiated (maybe 
>> that’s just a typo since in the code example before uses .unspecified).
> 
> I think it is a typo, only default needs to be qosDefault because default is 
> a keyword, and asking all users to back-tick it isn’t really good either.
> (also no one should really specify qos class default anyway).

Even .default should be okay once SE-0071 
<https://github.com/apple/swift-evolution/blob/23da9e94fd9580e59bdae50abf122d3d3c852a8f/proposals/0071-member-keywords.md>
 is implemented.

>> 
>> - Dennis
>> 
>>> On May 11, 2016, at 6:39 AM, Chris Lattner >> <mailto:clatt...@apple.com>> wrote:
>>> 
>>> Hello Swift community,
>>> 
>>> The review of "SE-0088: Modernize libdispatch for Swift 3 naming 
>>> conventions" begins now and runs through May 17. The proposal is available 
>>> here:
>>> 
>>> 
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0088-libdispatch-for-swift3.md
>>>  
>>> <https://github.com/apple/swift-evolution/blob/master/proposals/0088-libdispatch-for-swift3.md>
>>> 
>>> Reviews are an important part of the Swift evolution process. All reviews 
>>> should be sent to the swift-evolution mailing list at
>>> 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>> 
>>> or, if you would like to keep your feedback private, directly to the review 
>>> manager.
>>> 
>>> What goes into a review?
>>> 
>>> The goal of the review process is to improve the proposal under review 
>>> through constructive criticism and contribute to the direction of Swift. 
>>> When writing your review, here are some questions you might want to answer 
>>> in your review:
>>> 
>>> * What is your evaluation of the proposal?
>>> * Is the problem being addressed significant enough to warrant a change 
>>> to Swift?
>>> * Does this proposal fit well with the feel and direction of Swift?
>>> * If you have used other languages or libraries with a similar feature, 
>>> how do you feel that this proposal compares to those?
>>> * How much effort did you put into your review? A glance, a quick 
>>> reading, or an in-depth study?
>>> 
>>> More information about the Swift evolution process is available at
>>> 
>>> https://github.com/apple/swift-evolution/blob/master/process.md
>>> 
>>> Thank you,
>>> 
>>> -Chris Lattner
>>> Review Manager
>>> 
>>> 
>>> 
>>> ___
>>> swift-evolution-announce mailing list
>>> swift-evolution-annou...@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution-announce
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions

[Dennis Weissmann via swift-evolution]

1. What is your evaluation of the proposal?
+1 I think this is a big win for readability.

2. Is the problem being addressed significant enough to warrant a change to 
Swift?
Yes. dispatch is used nearly everywhere so many many projects would benefit 
from it.

3. Does this proposal fit well with the feel and direction of Swift?
Making the API more “swift" and feel more natural definitely is the direction 
Swift libraries are / should be going in.

4. If you have used other languages or libraries with a similar feature, how do 
you feel that this proposal compares to those?
Unfortunately not.

5. How much effort did you put into your review? A glance, a quick reading, or 
an in-depth study?
Read the proposal twice.

A little nitpick:

let item = DispatchWorkItem(qos: .qosUserInitiated) {
print("Hello World")
}

I’d change the enum case from .qosUserInitiated to .userInitiated (maybe that’s 
just a typo since in the code example before uses .unspecified).

- Dennis

> On May 11, 2016, at 6:39 AM, Chris Lattner  wrote:
> 
> Hello Swift community,
> 
> The review of "SE-0088: Modernize libdispatch for Swift 3 naming conventions" 
> begins now and runs through May 17. The proposal is available here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0088-libdispatch-for-swift3.md
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at
> 
>   https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager.
> 
> What goes into a review?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and contribute to the direction of Swift. When 
> writing your review, here are some questions you might want to answer in your 
> review:
> 
>   * What is your evaluation of the proposal?
>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?
>   * Does this proposal fit well with the feel and direction of Swift?
>   * If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?
>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
> 
> More information about the Swift evolution process is available at
> 
>   https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> -Chris Lattner
> Review Manager
> 
> 
> 
> ___
> swift-evolution-announce mailing list
> swift-evolution-annou...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution-announce

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Tuple Destructuring in Parameter Lists

[Dennis Weissmann via swift-evolution]

Thanks for all your feedback!

This is the current statistic:
Closure syntax: All positive
Function syntax: 3 (or 4) positive, 2 negative

I’ll try to address the concern Geordie and T.J. have.

> func takesATuple(someInt: Int, tuple: (valueA: String, valueB: String)) {}

> It’s true that you still have the ‚overhead‘ of having to type tuple. before 
> accessing its members. But this is almost always what I want (hopefully you’d 
> never actually name your tuple ‚tuple‘, instead it’d be a logical namespace 
> for what it contains). Do you have a real-world example where you’d need 
> this? To me it seems that in a case like this the API that produced the tuple 
> would need refining rather than the language itself.


What you suggest here is not tuple destructuring but using labeled tuples. And 
while I’m totally with you that this is for many cases the better approach, I 
still think we should introduce it to functions as well, for consistency and 
readability reasons.
In the end inconsistency is what led to this thread because tuple destructuring 
is already possible today - in for loops:

let stringTuple = [("", "”), ("", "")]
for (i, j) in stringTuple {}

That made me wonder if it’s also possible for closures (because I needed it 
there - and eventually someone will definitely wonder if it’s possible for 
function arguments as well).

You also asked me for my use case. To be honest, I don’t have one for the 
function version, but imagine the following:

My current closure use case is this (template.points and resampledPoints are of 
type [CGPoint]):

let localHighestSimilarity = zip(template.points, resampledPoints).reduce(0.0) 
{ accumulator, points in
  let (template, resampled) = points
  return accumulator + Double(template.x * resampled.x + template.y * 
resampled.y)
}

To reuse this code elsewhere I maybe want to refactor the closure into a 
function (using your labeled tuple suggestion):

func accumulateSimilarity(accumulator: Double, for points: (point1: CGPoint, 
point2: CGPoint)) -> Double {
  return accumulator + Double(points.point1.x * points.point2.x + 
points.point1.y * points.point2.y)
}

This isn’t particularity readable (image passing a CGRect and you need the 
points or a more complex calculation). Compare it to this:

func accumulateSimilarity(accumulator: Double, for (point1, point2): (CGPoint, 
CGPoint)) -> Double {
  return accumulator + Double(point1.x * point2.x + point1.y * point2.y)
}

You can of course still pass a named tuple instead of an unnamed, but it 
doesn’t make any difference, which brings me to an aside*.

I think the second approach makes the calculation much more comprehensible and 
it just feels “intuitive” (again, at least for me) :).


- Dennis

* I’m not sure how scientifically correct the following statement is but 
strictly speaking (at least for me) (valueA: String, valueB: String) is not of 
the same type as (String, String) just like func d(string: String, int: Int) is 
different from func e(_: String, _: Int) though in Swift the tuples are 
interchangeable (you can pass one where the other is expected).

> On May 8, 2016, at 6:10 PM, Geordie J  wrote:
> 
> Comments below
> 
>> Am 05.05.2016 um 20:22 schrieb Dennis Weissmann via swift-evolution 
>> mailto:swift-evolution@swift.org>>:
>> 
>> Following a short discussion with positive feedback on 
>> [swift-users](http://thread.gmane.org/gmane.comp.lang.swift.user/1812 
>> <http://thread.gmane.org/gmane.comp.lang.swift.user/1812>) I’d like to 
>> discuss the following:
>> 
>> Tuples should be destructible into their components in parameter lists.
>> 
>> Consider the following code:
>> 
>> let a = [0,1,2,3,4,5,6,7,8,9]
>> let b = [0,1,2,3,4,5,6,7,8,9]
>> 
>> let c = zip(a,b).reduce(0) { acc, tuple in
>>   acc + tuple.0 + tuple.1
>> }
>> 
>> tuple is of type (Int, Int).
>> 
>> The problem is that the calculation is not very comprehensible due to .0 and 
>> .1. That’s when destructuring tuples directly in the parameter list comes 
>> into play:
>> 
>> let c = zip(a,b).reduce(0) { acc, (valueA, valueB) in
>>   acc + valueA + valueB
>> }
> 
> +1 I think this is a great way to go about it.
> 
>> 
>> The above is what I propose should be accepted by the compiler (but 
>> currently isn’t).
>> 
>> Currently tuple destructuring is possible like this:
>> 
>> let c = zip(a,b).reduce(0) { (acc, tuple) in
>>   let (valueA, valueB) = tuple
>>   return acc + valueA + valueB
>> }
>> 
>> This is not about saving one line ;-). I just find it much more intuitive to 
>> destructure the tuple in the parameter list itself.
> 
> Agreed
> 
>> 
>> The same thing could be

Re: [swift-evolution] [swift-corelibs-dev] Change in String.CharacterView.Index?

[Dennis Weissmann via swift-evolution]

Hey Joe,

The collection index model changed:

https://github.com/apple/swift-evolution/blob/master/proposals/0065-collections-move-indices.md

You now need to ask the collection for the next index:

let a = “Hello, World"
let secondIndex = a.characters.index(after: a.characters.startIndex)
print(a.characters[secondIndex]) // prints "e"

- Dennis

> On May 8, 2016, at 7:58 PM, Joseph Bell via swift-corelibs-dev 
>  wrote:
> 
> Howdy,
> 
> I've been building the latest Swift 3.0 and noticed that between Apr 25 and 
> today that String.CharacterView.Index.advance(by:) is no longer available.
> 
> This runs with an Apr 25 build (Swift 255544591c to be exact)
> let string:String = "Hello, world!"
> print(string.startIndex)
> print(string.startIndex.advanced(by:1))
> 
> It fails with a build today (May 8, Swift 26fcf1ab4a):
> test.swift:3:14: error: value of type 'Index' (aka 
> 'String.CharacterView.Index') has no member 'advanced'
> print(string.startIndex.advanced(by:1))
>   ~~~^~ 
> 
> I don't know who runs swiftdoc.org  but it is handy, 
> and shows advanced(by:) a valid method:
> http://swiftdoc.org/v3.0/type/String.CharacterView.Index/ 
> 
> 
> Not sure what I'm missing here!
> 
> Thanks,
> Joe
> 
> 
> -- 
> Joseph Bell
> http://dev.iachieved.it/iachievedit/ 
> @iachievedit
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Pitch] Tuple Destructuring in Parameter Lists

[Dennis Weissmann via swift-evolution]

Following a short discussion with positive feedback on 
[swift-users](http://thread.gmane.org/gmane.comp.lang.swift.user/1812) I’d like 
to discuss the following:

Tuples should be destructible into their components in parameter lists.

Consider the following code:

let a = [0,1,2,3,4,5,6,7,8,9]
let b = [0,1,2,3,4,5,6,7,8,9]

let c = zip(a,b).reduce(0) { acc, tuple in
  acc + tuple.0 + tuple.1
}

tuple is of type (Int, Int).

The problem is that the calculation is not very comprehensible due to .0 and 
.1. That’s when destructuring tuples directly in the parameter list comes into 
play:

let c = zip(a,b).reduce(0) { acc, (valueA, valueB) in
  acc + valueA + valueB
}

The above is what I propose should be accepted by the compiler (but currently 
isn’t).

Currently tuple destructuring is possible like this:

let c = zip(a,b).reduce(0) { (acc, tuple) in
  let (valueA, valueB) = tuple
  return acc + valueA + valueB
}

This is not about saving one line ;-). I just find it much more intuitive to 
destructure the tuple in the parameter list itself.

The same thing could be done for functions:

func takesATuple(someInt: Int, tuple: (String, String))

Here we also need to destructure the tuple inside the function, but the 
intuitive place (at least for me) to do this would be the parameter list.

In the following example I'm making use of Swift’s feature to name parameters 
different from their labels (for internal use inside the function, this is not 
visible to consumers of the API):

func takesATuple(someInt: Int, tuple (valueA, valueB): (String, String))

Here valueA and valueB would be directly usable within the function. The tuple 
as a whole would not be available anymore.


Now it’s your turn!

1. What do you think?
2. Is this worth being discussed now (i.e. is it implementable in the Swift 3 
timeframe) or should I delay it?

Cheers,

- Dennis___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Idea] Passing an Array to Variadic Functions

[Dennis Weissmann via swift-evolution]

Sorry for my absence.

> Increment/decrement operators, currying, tuple splat and even the C-style for 
> loop have already been deprecated, and although I would have preferred to 
> keep some of those constructs, I think it is good how progressive Swift is 
> pushed forward ("would we add this feature now if it wasn't already there?”)

That is exactly my opinion.

Thanks Haravikk for compiling a list with pros/cons.

In my opinion, we have a perfectly fine way to express “a sequence of values”. 
And that is arrays. So why would you need a second concept to accomplish the 
exact same thing? In fact, inside the implementing function all varargs *are* 
arrays, why aren’t they outside?

The other reason I don’t like them is that, at the call site, you cannot 
distinguish between them and C functions (or badly named Swift functions).

Take the C stdlib atan2 function for example:

let a = atan2(3.0, 4.0)   

Does it take 2 Doubles? Or does it take a vararg list of Doubles. Can I do let 
a = atan2(3.0, 4.0, 5.0)? I cannot tell by reading someone else’s code (and 
there is quite a lot of C code out there).

Even in Swift it is possible to write functions like these:

func whichOne(t: Int) -> Int {
  return 1
}

func whichOne(t: Int...) -> Int {
  return 2
}

func whichOne(t: Int, _ t2: Int...) -> Int {
  return 3
}

Now call these functions:

whichOne(1)
whichOne(2, 2)
whichOne(3, 3)

Can you guess what they return? (answer: 1,3,3)

In the end it’s just another concept to learn (or at least to be aware of) 
which in and of itself does not create much of an added value (except you save 
two characters []).

- Dennis

> On Apr 20, 2016, at 4:56 PM, Tino Heth via swift-evolution 
>  wrote:
> 
> 
>> The question is whether the downside to variadic parameters is really enough 
>> to justify _removing_ an existing language feature. 
>> 
>> The burden of justification should be on those people wanting to change the 
>> language, not on those wanting to maintain the status quo and “I don’t like 
>> it” or “I think it makes code a tiny bit less readable” is not sufficient 
>> justification, in my opinion because you already have the option not to use 
>> the feature. 
> Afaics, this isn't true:


> The value of variadic functions is imho less than the possibility to omit 
> "()" in procedure calls, and afair, there have been several posts that 
> illustrate the complications of this feature.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Idea] Passing an Array to Variadic Functions

[Dennis Weissmann via swift-evolution]

- Dennis

> On Apr 18, 2016, at 9:55 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>> I would like to see format strings go away and be replace with safer inline 
>> annotations.
> 
> The main problem is doing localized strings with printf-style formats well, 
> but I actually have a pretty sweet solution for that: 
> https://gist.github.com/brentdax/79fa038c0af0cafb52dd
> 
>> -- E, somewhat agnostic on variadics
> 
> Variadics are eventually important as a generic function feature; you really 
> want to be able to write a version of zip() which can take any number of 
> sequences, for instance, and the only reasonable way to do that is to pass a 
> variable number of parameters and return a sequence with a matchingly 
> variable number of type parameters.
> 
Which brings us to dependent types :)

> Today, they are important in that they bootstrap ArrayLiteralConvertible and 
> DictionaryLiteralConvertible by (at least theoretically) acting as a 
> pass-N-items mechanism that doesn't depend on one of the standard library 
> types defined in terms of it. (If we convert them to show up as tuples once 
> we have tuple subscripting syntax, that will even become true.) Less 
> esoterically, they're used in several places where an Array would be 
> inconvenient or break traditions:
> 
> * The `print` function's list of items to print is variadic. An array 
> equivalent would look like `print([one, two, three])`.
> * The `min` and `max` functions are more convenient than explicitly 
> constructing an array and calling their `min()` and `max()` methods.
> * And, yes, `String.init(format:_:)`, which we will probably never be quite 
> rid of for compatibility reasons.
> 
All those points are also perfectly solved by dependent types (which is 
definitely not in the time frame of Swift 3 or even Swift 4).
But I think in the long term we should get rid of varargs and Swift 3 (as far 
as I remember) is the last version of Swift to remove functionality from the 
language (is that actually correct?).

Short-term solutions:

I very very rarely use the print function with multiple parameters. Most of the 
time I build a single string and use string interpolation to insert values. If 
there really is a need for multiple arguments to print, like others said, 
overloads could be generated.
min and max: I think most the time they are used to compare 2 values. If there 
are more than 2 values (or let’s say 3) I think an array is better suited.
String.init(format:_:) … I think if all C APIs would get imported by converting 
varargs to arrays we could get rid of it.

> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Idea] Passing an Array to Variadic Functions

[Dennis Weissmann via swift-evolution]

Hm, sorry but I’m still not convinced :(

I still find it confusing and I think if it wasn’t in Swift already, it would 
not be added. Maybe someone can come up with a strong reason why it should be 
added if it weren’t there.

- Dennis

> On Apr 18, 2016, at 10:10 AM, Gwendal Roué  wrote:
> 
> 
>> Le 18 avr. 2016 à 10:02, Dennis Weissmann  a 
>> écrit :
>> 
>> That’s IMO already a problematic case:
>> 
>>> DatabaseTable.select(id, name).order(name, id)  // What’s the 
>>> problem?
>>> // vs.
>>> DatabaseTable.select([id, name]).order([name, id])  // OK, of 
>>> course... But some people will find it a litle short
>> 
>> The problem is that you can’t tell by looking at the call site whether 
>> `select` takes an id and a name as parameter (the function being declared as 
>> `func select(id: String, _ name: String)` or a vararg `func select(string: 
>> String…)`.
>> Both call sites look like this:
>> 
>>> select(id, name)
>> 
>> I think it would make the language clearer and more consistent if varargs 
>> were removed.
> 
> Sorry my example wasn’t clear enough, and that’s why you couldn’t tell by 
> looking at the call site what was happening. You were missing context. "id" 
> and "name" are not values, they’re database columns. It’s more something 
> along:
>   
>   DatabaseTable {
>   func select(columns: Column…) { … }
>   }
>   
>   people.select(idColumn, nameColumn)
>   furniture.select(nameColumn, widthColumn, heightColumn, depthColumn, 
> priceColumn)
> 
> (Sometimes examples are too complex, and don't serve well their purpose - my 
> mistake)
> 
> Maybe you’ll follow the counter argument now. Which is "of course a variadic 
> function can always be turned into a function that takes an array, what a 
> surprise, but this is not always the good thing to do."
> 
> Regards,
> Gwendal Roué

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Idea] Passing an Array to Variadic Functions

[Dennis Weissmann via swift-evolution]

That’s IMO already a problematic case:

>   DatabaseTable.select(id, name).order(name, id)  // What’s the 
> problem?
>   // vs.
>   DatabaseTable.select([id, name]).order([name, id])  // OK, of 
> course... But some people will find it a litle short


The problem is that you can’t tell by looking at the call site whether `select` 
takes an id and a name as parameter (the function being declared as `func 
select(id: String, _ name: String)` or a vararg `func select(string: String…)`.
Both call sites look like this:

> select(id, name)


I think it would make the language clearer and more consistent if varargs were 
removed.

- Dennis

> On Apr 18, 2016, at 9:48 AM, Gwendal Roué  wrote:
> 
> 
>> Le 18 avr. 2016 à 09:35, Dennis Weissmann via swift-evolution 
>>  a écrit :
>> 
>>> Why not remove varargs altogether from Swift, it is easy enough to put [] 
>>> round a list?
>> 
>> +1, that was my thought too. I can’t think of a use case where you can’t use 
>> an array instead of varargs (this assumes all vararg parameters are 
>> converted to array parameters).
> 
> Oh no please no. Of course a variadic function can always be rewritten as a 
> function that takes an array. Of course. You always can use an array. Got it. 
> But some APIs are nicer with varargs. And even nicer APIs go over the top by 
> adding support for arrays too, because not all lists are known at compile 
> time. It’s a matter of being sensible.
> 
>   DatabaseTable.select(id, name).order(name, id)  // What’s the 
> problem?
>   // vs.
>   DatabaseTable.select([id, name]).order([name, id])  // OK, of 
> course... But some people will find it a litle short
> 
> Gwendal Roué
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Idea] Passing an Array to Variadic Functions

[Dennis Weissmann via swift-evolution]

> Why not remove varargs altogether from Swift, it is easy enough to put [] 
> round a list?

+1, that was my thought too. I can’t think of a use case where you can’t use an 
array instead of varargs (this assumes all vararg parameters are converted to 
array parameters).

- Dennis

> On Apr 18, 2016, at 12:48 AM, Howard Lovatt via swift-evolution 
>  wrote:
> 
> Why not remove varargs altogether from Swift, it is easy enough to put [] 
> round a list?
> 
> On Monday, 18 April 2016, Keith Smiley via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> We've been dealing with this as well. We've chosen to go with your option 1 
> for
> most of our cases, sometimes dropping varargs all together and just using the
> array signature.
> 
> It would be great if you could have a safe apply function for this.
> 
> --
> Keith Smiley
> 
> On 04/17, Justin Jia via swift-evolution wrote:
> > Hi!
> >
> > Currently, we can’t call a variadic function with an array of arguments.
> >
> > Reference:
> > 1. 
> > http://stackoverflow.com/questions/24024376/passing-an-array-to-a-function-with-variable-number-of-args-in-swift
> >  
> > 
> >  
> >  >  
> > >
> > 2. https://www.drivenbycode.com/the-missing-apply-function-in-swift/ 
> >  
> >  > >
> >
> > Consider the following use case:
> >
> > ```
> > func average(numbers: Double…) -> Double {
> >return sum(numbers) / numbers.count // Error: Cannot convert value of 
> > type ‘[Double]’ to expected argument type ‘Double'
> > }
> >
> > func sum(numbers: Double...) -> Double { … }
> > ```
> >
> > Right now, there are two ways to fix it:
> >
> > 1. Add another function that accept `[Double]` as input.
> >
> > ```
> > func average(numbers: Double…) -> Double {
> >return sum(numbers) / numbers.count
> > }
> >
> > func sum(numbers: Double...) -> Double {
> >return sum(numbers)
> > }
> >
> > func sum(numbers: [Double]) -> Double { … }
> > ```
> >
> > 2. Implement an `apply()` function using `unsafeBitCast`.
> >
> > ```
> > func average(numbers: Double…) -> Double {
> >return sum(apply(numbers)) / numbers.count
> > }
> >
> > func sum(numbers: [Double]) -> Double { … }
> >
> > func apply(fn: (T...) -> U, args: [T]) -> U {
> >typealias FunctionType = [T] -> U
> >return unsafeBitCast(fn, FunctionType.self)(args)
> > }
> > ```
> >
> > However, both solutions are not very elegant. The first solution requires 
> > the library author to implement both functions, and the second solution 
> > breaks the guarantees of Swift’s type system.
> >
> > Swift should allow passing an array to variadic functions, or we should 
> > somehow implement a type-safe `apply()` function in the standard library.
> >
> > Justin
> 
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org <>
> > https://lists.swift.org/mailman/listinfo/swift-evolution 
> > 
> 
> 
> 
> -- 
> -- Howard.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

[Dennis Weissmann via swift-evolution]

> On Apr 14, 2016, at 9:00 AM, Vladimir.S via swift-evolution 
>  wrote:
> 
> [offtopic for "A New Model for Collections and Indices"]
> 
> Just wanted to add my 2 cents to this new naming guidelines proposal that 
> @Dave pointed to:
> "Update API Naming Guidelines and Rewrite Set APIs Accordingly"
> https://github.com/apple/swift-evolution/blob/master/proposals/0059-updated-set-apis.md
> 
> I strongly feel this "form" prefix is a wrong decision. Is it really most of 
> us feel this "form" method name not confusing and think this is a good 
> solution? Just can't believe in this.
> 
> My mind reads "form" as "from" first. And then, when I re-checked, I see 
> "fORm". I believe we see "from" much more often than "form" as in code and in 
> our usual life, so we'll read it as "from" first.

Non-native speaker here, I had/have the exact same problem. Always read “from”.

> I have some kind of prove : "I cdn'uolt blveiee taht I cluod aulaclty 
> uesdnatnrd waht I was rdanieg"
> https://en.wikipedia.org/wiki/Typoglycemia
> 
> Additionally, I totally refuse to feel the meaning of "form" word as good 
> replacement for meaning for "InPlace". InPlace is probably "visually 
> heavyweight"(as noted in proposal) but IMO much more explicit on what we are 
> doing and what we'll have in result.
> 
> I have no right now good alternative for "form", and probably the proposal 
> was already accepted or probably really most of us agree with "form".
> 
> Probably I'll prefer to leave InPlace as in current Swift, or event make it a 
> suffix(but all lowecased, thinking if we are using "in-place" as one word, 
> not "in place" as two words):
> 
> y.inplaceUnion(z)
> 
> or probably
> 
> y.assignByUnion(z)
> (as we think of this command as
> y = y.union(z)
> , we can just read it - "y is assigned by the value of y.union(z) "
> "assign the variable "name" the value computed by "right_hand_expression""
> => "assign the y the value computer by union(z)" => assignByUnion(z)
> for example, first found: 
> http://www.cs.utah.edu/~germain/PPS/Topics/assignment_statement.html)
> 
> or may be
> 
> y.mutateByUnion(z)
> imo clear and explicit. we have 'mutating' when dealing with structs, here is 
> similar behavior.
> 
> Probably we should rethink the mutating methods at all, and not trying to 
> find a good word but introduce new syntax in Swift like.. I don't know.. some 
> kind of y&.union(z)  or y$.union(z) or y:union(z) etc.
> 
> Just some opinion. Thank you for reading this.
> 
> [/offtopic]
> 
> On 13.04.2016 21:24, Dave Abrahams via swift-evolution wrote:
>>> In other cases, the mutating pair of methods refer to the receiver, not the
>>> >argument.
>>> >
>>> >x = y.union(z) // new value x
>>> >y.formUnion(z) // mutates y, not z
>>> >
>>> >x = y.successor(z) // new value x
>>> >y.formSuccessor(z) // mutates z (or replaces), not y
>> This is true, but we need a way to deal with these cases as well.
>> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution