Re: [swift-evolution] [Review] SE-0084: Allow trailing commas in parameter lists and tuples

[Gwendal Roué via swift-evolution]

> Le 13 mai 2016 à 07:01, Chris Lattner via swift-evolution 
>  a écrit :
> 
> On May 12, 2016, at 4:50 PM, Joe Groff  wrote:
--- a.swift
+++ a.swift
 foo(
   x: 0,
-  y: 1
+  y: 1,
+  z: 2
 )
 
 Trailing commas avoid this:
 
--- a.swift
+++ a.swift
 foo(
   x: 0,
   y: 1,
+  z: 2,
 )
>>> 
>>> You’re arguing that you want to read Swift code written like this?
>> 
>> I wouldn't mind it.
> 
> I personally find that style repulsive :-) and I haven’t seen swift code 
> commonly doing it.  I’m not sure that we want to encourage it either.

Don't be too harsh :-) This style can be used with much profit when there are 
several closure arguments:

foo(
x: {
// several lines of code
},
y: {
// several lines of code
}
)

For example: 
https://github.com/groue/GRDBDemo/blob/cd8b9d5cadc3c6c66fd0da4869d820c6624fdf79/GRDBDemo/PersonsViewController.swift#L12-L44

Gwendal Roué

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

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

[Daniel A. Steffen via swift-evolution]

> On May 12, 2016, at 22:29, Zach Waldowski via swift-evolution 
> > wrote:
> 
> dispatch_get_context, dispatch_set_context are not around simply in the 
> absence of blocks. They're just as useful as the queue-specific data APIs as 
> they have thread-specific storage.

dispatch_get_context and dispatch_set_context are per-object storage of a 
single word, there is no connection to threads.

there are many problems with this API including the lack of synchronization 
between getters and setters and ill-defined ownership semantics (e.g. a setter 
replacing an already set context leaks the previous value).

On queues this API has been subsumed by the getSpecific/setSpecific API which 
does not have these problems, for other classes we felt that its drawbacks and 
problems outweighed the benefits that it provided.

Daniel

>  
> Zach Waldowski
> z...@waldowski.me 
>  
>  
> On Thu, May 12, 2016, at 08:50 PM, Pierre Habouzit via swift-evolution wrote:
>>> On May 12, 2016, at 10:49 AM, Jose Cheyo Jimenez via swift-evolution 
>>> > wrote:
>>>  
>>>  
 On May 11, 2016, at 7:09 AM, Matt Wright via swift-evolution 
 > wrote:
  
>  
> On May 10, 2016, at 11:52 PM, Jacob Bandes-Storch via swift-evolution 
> > wrote:
>  
>  
>* What is your evaluation of the proposal?
>  
> I'm generally in favor of a modernized API overlay like this (and I've 
> written something like it myself, albeit much simpler), but I'm hoping 
> this proposal can go through another round or two of 
> discussion/bikeshedding/revision before approval.
>  
> (Small note: I'm really happy about the strong-typed-ness of the Source 
> subclasses, e.g. how mergeData is only available for Add/Or.)
>  
> In no particular order, here are some things on which I'm unclear, or 
> not-so-+1:
>  
> - synchronously()'s block parameter should be @noescape. Perhaps more 
> arguably, it should have a generic return type and rethrows, like 
> autoreleasepool now does.
  
 Both of these are present in the changes I have for this proposal. The 
 former point is a mistake in my proposal text, the latter is an 
 unfortunate oversight on my part in putting together the proposal document.
  
> - The names asynchronously(execute:) and synchronously(execute:) don't 
> seem to fit with any API guidelines I'm aware of. Did you consider 
> including the verb in the method name?  
  
 We did. Of the number of names that we discussed, none of them were 
 perfect. sync/async are common in other languages but don’t fit the 
 general direction of the Swift 3 naming conventions. Using 
 `dispatchAsynchronously` is an extremely long method name, even more so 
 than `asynchronously`. `perform` does not capture the sync/async nature of 
 the calls particularly well, compared to DispatchWorkItem where `perform` 
 immediately executes the block.
  
> (And I'm guessing that "func synchronously(work:...)" is meant to be 
> "func synchronously(execute work:...)”?)
  
 Right.
  
> As another bikeshed-item, I'd vote for "Data.init(withoutCopying:...)" 
> rather than "(bytesNoCopy:...)", and perhaps whenDone() instead of 
> notify().
  
 Here the init() functions closely mirror Data from Foundation, the 
 Objective-C class is toll-free bridged to NSData and we desired a close 
 match to the Foundation Swift API. `notify` is Dispatch-only API though, 
 I’ll go think over that one.
  
> - Are DispatchWorkItemFlags meant to overlay dispatch_block_flags? It 
> would be nice to explicitly list these in the proposal.
  
 The dispatch_block_* API is completely superseded by DispatchWorkItem in 
 the proposal. DispatchWorkItemFlags is the equivalent to 
 dispatch_block_flags.
  
> - Are functions like dispatch_barrier_sync totally gone in favor of 
> passing a .barrier flag? It would be nice to explicitly state this in the 
> proposal.
  
 Yes, you can supply .barrier to either `synchronously` or 
 `asynchronously`, or create a DispatchWorkItem as a barrier item. Where 
 possible the multiple variants of a class (dispatch_async, 
 dispatch_barrier_async, etc) are collapsed into a single method with 
 default arguments.
  
> - I echo Austin's concerns about subclassability. I think it would be 
> dangerously misleading if the classes were subclassable from user code, 
> even if it didn't work properly.
  
 Building at compile time will fail. So you wouldn’t get very far trying to 
 use them, I plan to investigate 

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

[Zach Waldowski via swift-evolution]

dispatch_get_context, dispatch_set_context are not around simply in the
absence of blocks. They're just as useful as the queue-specific data
APIs as they have thread-specific storage.
 
Zach Waldowski
z...@waldowski.me
 
 
On Thu, May 12, 2016, at 08:50 PM, Pierre Habouzit via swift-evolution wrote:
>> On May 12, 2016, at 10:49 AM, Jose Cheyo Jimenez via swift-evolution
>>  wrote:
>>
>>
>>> On May 11, 2016, at 7:09 AM, Matt Wright via swift-evolution >> evolut...@swift.org> wrote:
>>>

 On May 10, 2016, at 11:52 PM, Jacob Bandes-Storch via swift-
 evolution  wrote:


 * What is your evaluation of the proposal?

 I'm generally in favor of a modernized API overlay like this (and
 I've written something like it myself, albeit much simpler), but
 I'm hoping this proposal can go through another round or two of
 discussion/bikeshedding/revision before approval.

 (Small note: I'm really happy about the strong-typed-ness of the
 Source subclasses, e.g. how mergeData is only available for
 Add/Or.)

 In no particular order, here are some things on which I'm unclear,
 or not-so-+1:

 - synchronously()'s block parameter should be @noescape. Perhaps
   more arguably, it should have a generic return type and rethrows,
   like autoreleasepool now does.
>>>
>>> Both of these are present in the changes I have for this proposal.
>>> The former point is a mistake in my proposal text, the latter is an
>>> unfortunate oversight on my part in putting together the proposal
>>> document.
>>>
 - The names asynchronously(execute:) and synchronously(execute:)
   don't seem to fit with any API guidelines I'm aware of. Did you
   consider including the verb in the method name?
>>>
>>> We did. Of the number of names that we discussed, none of them were
>>> perfect. sync/async are common in other languages but don’t fit the
>>> general direction of the Swift 3 naming conventions. Using
>>> `dispatchAsynchronously` is an extremely long method name, even more
>>> so than `asynchronously`. `perform` does not capture the sync/async
>>> nature of the calls particularly well, compared to DispatchWorkItem
>>> where `perform` immediately executes the block.
>>>
 (And I'm guessing that "func synchronously(work:...)" is meant to
 be "func synchronously(execute work:...)”?)
>>>
>>> Right.
>>>
 As another bikeshed-item, I'd vote for
 "Data.init(withoutCopying:...)" rather than "(bytesNoCopy:...)",
 and perhaps whenDone() instead of notify().
>>>
>>> Here the init() functions closely mirror Data from Foundation, the
>>> Objective-C class is toll-free bridged to NSData and we desired a
>>> close match to the Foundation Swift API. `notify` is Dispatch-only
>>> API though, I’ll go think over that one.
>>>
 - Are DispatchWorkItemFlags meant to overlay dispatch_block_flags?
   It would be nice to explicitly list these in the proposal.
>>>
>>> The dispatch_block_* API is completely superseded by
>>> DispatchWorkItem in the proposal. DispatchWorkItemFlags is the
>>> equivalent to dispatch_block_flags.
>>>
 - Are functions like dispatch_barrier_sync totally gone in favor of
   passing a .barrier flag? It would be nice to explicitly state
   this in the proposal.
>>>
>>> Yes, you can supply .barrier to either `synchronously` or
>>> `asynchronously`, or create a DispatchWorkItem as a barrier item.
>>> Where possible the multiple variants of a class (dispatch_async,
>>> dispatch_barrier_async, etc) are collapsed into a single method with
>>> default arguments.
>>>
 - I echo Austin's concerns about subclassability. I think it would
   be dangerously misleading if the classes were subclassable from
   user code, even if it didn't work properly.
>>>
>>> Building at compile time will fail. So you wouldn’t get very far
>>> trying to use them, I plan to investigate adding `final` here (it’s
>>> only absent for technical reasons, as the classes originate from
>>> Objective-C).
>>>
 - What of the APIs provided on Semaphore and Group objects? I'd
   like to see these before I vote for the proposal.
>>>
>>> These would be transformed similarly, I will include them when
>>> updating the proposal.
>>>
>>> class DispatchSemaphore : DispatchObject {
>>>
>>> init(value: Int)
>>>
>>> func wait(timeout: DispatchTime = default) -> Int
>>>
>>> func wait(walltime timeout: DispatchWalltime) -> Int
>>>
>>> func signal() -> Int
>>>
>>> }
>>>
>>> class DispatchGroup : DispatchObject {
>>>
>>> init()
>>>
>>> func wait(timeout: DispatchTime = default) -> Int
>>>
>>> func wait(walltime timeout: DispatchWalltime) -> Int
>>>
>>> func notify(queue: DispatchQueue, block: () -> Void)
>>>
>>> func enter()
>>>
>>> func leave()
>>>
>>> }
>>>
>>>
 - What will dispatch_set_target_queue's replacement look like look
   like?
>>>
>>> extension DispatchObject {
>>>
>>> func 

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

[Chris Lattner via swift-evolution]

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___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0084: Allow trailing commas in parameter lists and tuples

[Chris Lattner via swift-evolution]

On May 12, 2016, at 4:50 PM, Joe Groff  wrote:
>>> --- a.swift
>>> +++ a.swift
>>>  foo(
>>>x: 0,
>>> -  y: 1
>>> +  y: 1,
>>> +  z: 2
>>>  )
>>> 
>>> Trailing commas avoid this:
>>> 
>>> --- a.swift
>>> +++ a.swift
>>>  foo(
>>>x: 0,
>>>y: 1,
>>> +  z: 2,
>>>  )
>> 
>> You’re arguing that you want to read Swift code written like this?
> 
> I wouldn't mind it.

I personally find that style repulsive :-) and I haven’t seen swift code 
commonly doing it.  I’m not sure that we want to encourage it either.

> The standard library already uses this style for function parameters, modulo 
> the trailing comma, and I certainly prefer it to:
>   
>>  --- a.swift
>>  +++ a.swift
>>   foo( x: 0
>>  , y: 1
>>  +   , z: 2
>>  )

I agree that this is even worse, but I also haven’t seen this used in Swift 
code.  Have you?   Swift’s strictness with argument labels makes any of this 
pretty unappealing to use.

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.

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

Re: [swift-evolution] Referencing zero-parameter functions

[David Sweeris via swift-evolution]

What about :? You could reference "foo()" as "foo:()", 
"foo(arg: T)" as "foo:(arg:)", and the property "foo" as "foo:".

- Dave Sweeris

> On May 12, 2016, at 16:40, Alex Hoppen via swift-evolution 
>  wrote:
> 
> Since there doesn’t seem to be much support for the proposal, I’ll drop it 
> and incorporate Alternative 1 into the #selector proposal like Doug suggested.
> 
> – Alex
> 
>>> On 12 May 2016, at 20:52, Douglas Gregor  wrote:
>>> 
>>> 
>>> On May 6, 2016, at 12:34 AM, Alex Hoppen via swift-evolution 
>>>  wrote:
>>> 
>>> Thanks for your feedback so far. Based on the discussion, I have updated 
>>> the proposal to let `foo` refer to the zero-parameter function instead of 
>>> `foo(_)`.
>>> 
>>> The updated proposal is also available on GitHub: 
>>> https://github.com/ahoppen/swift-evolution/blob/reference-zero-param-func/proposals/-refernce-zero-param-func.md.
>> 
>>> 
>>> Again comments would be greatly appreciated.
>> 
>> General comment: now that this proposal has pivoted to always requiring the 
>> argument labels when referencing a function, the title and introduction are 
>> misleading. This is a *much* larger change than Alternative 1 or Alternative 
>> 2, and is now source-breaking.
>> 
>> (Personally, I still think “Alternative 1” is the right answer)
>> 
>>  - Doug
>> 
>>> 
>>> – Alex
>>> 
>>> Referencing zero-parameter functions
>>> Proposal: SE-
>>> Author(s): Alex Hoppen, Pyry Jahkola
>>> Status: Draft
>>> Review manager: TBD
>>> Introduction
>>> 
>>> Since the approval of SE-0021 it is possible to reference a function by its 
>>> argument names using the foo(arg:) syntax but there is no way to reference 
>>> a zero-parameter function. foo currently references all methods with base 
>>> name foo. If there are multiple methods with this base name, one has to 
>>> disambiguate the referenced function by its type using as.
>>> 
>>> 
>>> This proposal changes the behaviour of foo to always reference a 
>>> zero-parameter function. To reference a function with more parameters, the 
>>> argument labels have to be explicitly named (e.g. foo(arg:)).
>>> 
>>> Originally, the proposal sought to introduce the new syntax foo(_) to 
>>> reference an overloaded function with zero parameters, but was discarded 
>>> based on the discussion on swift-evolution.
>>> 
>>> Motivation
>>> 
>>> Consider the following example
>>> 
>>> class Bar {
>>>   func foo() {
>>>   }
>>> 
>>>   func foo(arg: Int) {
>>>   }
>>> }
>>> You can reference foo(arg: Int) using Bar.foo(arg:) but there is currently 
>>> no syntax to reference foo() without using disambiguation by type Bar.foo 
>>> as () -> Void. We believe this is a major hole in the current 
>>> disambiguation syntax.
>>> 
>>> Proposed solution
>>> 
>>> We propose that Bar.foo only references methods with no parameters just as 
>>> Bar.foo(arg:) references the methods with one argument named arg.
>>> 
>>> This is a breaking change since Bar.foo currently refers to all methods 
>>> with base name foo.
>>> 
>>> Detailed design
>>> 
>>> The existing syntax Bar.foo is reinterpreted to not reference any method on 
>>> Bar with base name foo but to only reference functions named foo that take 
>>> no parameters.
>>> 
>>> If two overloads with zero-parameters exist with different return types, 
>>> disambiguation has still to be done via as just like with the foo(arg:) 
>>> syntax.
>>> 
>>> Impact on existing code
>>> 
>>> Existing code that uses Bar.foo to reference methods with parameters needs 
>>> to be changed. We believe this will effect many developers, so a fix-it 
>>> would be essential.
>>> 
>>> Possible issues
>>> 
>>> Bar.foo may be mistaken for a reference to a property, since all other 
>>> references to functions will contain parenthesis if this proposal is 
>>> accepted.
>>> 
>>> Most functions are not overloaded and using the base name only offers a 
>>> shorthand way to reference these functions. If this proposal is accepted, 
>>> this shorthand is no longer available for methods with parameters.
>>> 
>>> Alternatives considered
>>> 
>>> Alternative 1: Bar.foo() inside #selector
>>> 
>>> Let Bar.foo() refer to the zero-parameter function only inside #selector as 
>>> it was proposed by Doug Gregor here. This requires the proposal to disallow 
>>> arbitrary expressions in #selector (GitHub-Link) to be approved. Issues we 
>>> see are:
>>> 
>>> This gives the illusion that foo is actually called which it isn't
>>> It doesn't solve the issue of referencing a zero-parameter function in 
>>> arbitrary expressions somewhere else in code.
>>> Alternative 2: Bar.foo(_)
>>> 
>>> The original idea of using Bar.foo(_) to refer to the zero-parameter method 
>>> was discarded after discussion on the mailing list because of the following 
>>> reasons:
>>> 
>>> It is only a single typo away from Bar.foo(_:) which references the method 
>>> with one unnamed argument
>>> In 

Re: [swift-evolution] [Draft] Introducing StaticSelf, an Invariant Self

[Thorsten Seitz via swift-evolution]

+1

Good description of the motivating problem!

As for bikeshedding: ConformingSelf, ConformingType, BaseSelf, BaseType

-Thorsten 

> Am 13.05.2016 um 02:49 schrieb Matthew Johnson via swift-evolution 
> :
> 
> Erica Sadun and I have written a proposal are following up the recent 
> discussion thread "[RFC] #Self” with a proposal to introduce StaticSelf, an 
> invariant Self.
> 
> The recent discussion can be found here: 
> http://thread.gmane.org/gmane.comp.lang.swift.evolution/16565
> 
> The proposal can be found here: 
> https://github.com/anandabits/swift-evolution/blob/static-self/proposals/-static-self.md
> 
> We look forward to continuing the discussion.  We plan to submit a PR in the 
> near future after incorporating your final feedback.
> 
> Thanks,
> Matthew
> Introducing StaticSelf, an Invariant Self
> 
> Proposal: TBD
> Authors: Matthew Johnson, Erica Sadun
> Status: TBD
> Review manager: TBD
> Introduction
> 
> This proposal introduces a new keyword that provides consistent invariant 
> type semantics in all contexts.
> 
> The Swift-evolution thread about this topic can be found here: [RFC] #Self
> 
> Motivation
> 
> The distinction between covariant and non-covariant type references come into 
> play when
> conforming non-final classes to protocols. Fixing a protocol requirement to a 
> covarying type
> means that a method returning Self must be overriden by all subclasses in 
> order to return
> the correct, matching type.
> 
> This proposal builds on the covariant construct Self accepted in SE–0068
> to introduce an invariant type identifier. It enables protocol declarations 
> to consistently
> refer to a type that is fixed at compile time. This ensures that subclasses 
> can inherit
> protocol implementations without having to re-implement that code at each 
> level of
> inheritance.
> 
> Under this proposal, a new identifier keyword is fixed in use at the point of 
> protocol conformance
> to the static type of that construct. 
> 
> class A: MyProtocol
> The invariant StaticSelf identifier will always refer to A, unlike Self, 
> which is covarying and refers to
> the type of the actual instance. Since multiple inheritance for non-protocol 
> types is disallowed,
> this establishes this invariant type identifier with no possibility for 
> conflict.
> 
> Consider the following example, under the current system:
> 
> protocol StringCreatable {
> static func createWithString(s: String) -> Self
> }
> 
> extension NSURL: StringCreatable {
>  // cannot conform because NSURL is non-final
>  // error: method 'createWithString' in non-final class 'NSURL' must return 
> `Self` to conform to protocol 'A'
> }
> Introducing a static, invariant version of Self permits the desired 
> conformance:
> 
> protocol StringCreatable {
> static func createWithString(s: String) -> StaticSelf
> }
> 
> extension NSURL: StringCreatable {
>  // can now conform conform because NSURL is fixed and matches the static
>  // type of the conforming construct. Subclasses need not re-implement
>  // NOTE: the return type can be declared as StaticSelf *or* as NSURL
>  //   they are interchangeable
>  static func createWithString(s: String) -> StaticSelf { 
>  // ...
>  }
> }
> Additional Utility
> 
> The utility of StaticSelf is not limited to protocols. A secondary use 
> enables code to refer to the lexical context’s current type without 
> explicitly mentioning its name. This provides a useful shortcut when 
> referencing static type members with especially long names and when 
> re-purposing code between types.
> 
> class StructWithAVeryLongName {
> static func foo() -> String {
>   // ...
> }
> func bar() {
>   // ...
>   let s = StaticSelf.foo()
>   //
> }
> }
> Detailed Design
> 
> This proposal introduces StaticSelf, a new keyword that may be used in 
> protocols to refer to the invariant static type of a conforming construct. 
> StaticSelf may also be used in the lexical context of any type declaration. 
> In such use, the keyword is identical to spelling out the full name of that 
> type.
> 
> Impact on existing code
> 
> Being additive, there should be no impact on existing code.
> 
> Alternatives considered
> 
> The keyword is not fixed at this time. Alternatives that have been discussed 
> include StaticType, InvariantSelf, SelfType, or Type. The community is 
> welcome to bikeshed on the most clear and concise name for this keyword.
> 
> ___
> 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] Allowing `guard let self = self else { … }` for weakly captured self in a closure.

[Patrick Smith via swift-evolution]

How about [weak(guard) self]? It would only work with closures returning -> () 
as if you are weakly capturing something you are likely to be messaging that 
not returning some, so they can be ignored.

networkRequest.fetchData() { [weak(guard) self] result in
switch result {
case .succeeded(let data):
self.processData(data)

case .failed(let err):
self.handleError(err)
}
}

Patrick


> On 13 May 2016, at 2:10 AM, Hoon H. via swift-evolution 
>  wrote:
> 
> I am replying months lately, but anyway, I just read your proposal, and I 
> think this is cool.
> 
>[guard self]
> 
> I am in doubt about another stuffs such as `[guard self else …]`. I hope your 
> proposal to be accepted. I am getting a bit tired of writing `guard let S = 
> self else { … }`.
> 
> I am still not sure how to use mailing list… but I hope this to be a correct 
> way.
> …Sending again because I mistyped Evan’s address.
> 
> — Hoon H.
> 
> ___
> 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] [Draft] Introducing StaticSelf, an Invariant Self

[Patrick Smith via swift-evolution]

I didn’t really understand some of the lead in discussion examples regarding 
protocols A and B each being interwoven, but I would prefer to see StaticSelf 
only used for concrete types, and protocols only to use Self. If Self has 
problems with non-final classes, then maybe how it works in protocols could 
change. A class could interpret a protocol’s ‘Self’ as ‘myself or my 
subclasses’?

Maybe instead of introducing StaticSelf it could be renamed simply Self, and 
‘Self’ as used in protocols could change to something else? ‘Instance’ perhaps?

> On 13 May 2016, at 12:21 PM, Joe Groff via swift-evolution 
>  wrote:
> 
> 
>> On May 12, 2016, at 5:49 PM, Matthew Johnson via swift-evolution 
>>  wrote:
>> 
>> The invariant StaticSelf identifier will always refer to A, unlike Self, 
>> which is covarying and refers to
>> the type of the actual instance. Since multiple inheritance for non-protocol 
>> types is disallowed,
>> this establishes this invariant type identifier with no possibility for 
>> conflict.
>> 
>> Consider the following example, under the current system:
>> 
>> protocol StringCreatable 
>> {
>> 
>> static func createWithString(s: String) -> Self
>> 
>> }
>> 
>> 
>> extension NSURL: StringCreatable 
>> {
>> 
>> // cannot conform because NSURL is non-final
>> 
>> 
>> // error: method 'createWithString' in non-final class 'NSURL' must return 
>> `Self` to conform to protocol 'A'
>> 
>> }
>> 
>> Introducing a static, invariant version of Self permits the desired 
>> conformance:
>> 
>> protocol StringCreatable 
>> {
>> 
>> static func createWithString(s: String) -> StaticSelf
>> 
>> }
>> 
>> 
>> extension NSURL: StringCreatable 
>> {
>> 
>> // can now conform conform because NSURL is fixed and matches the static
>> 
>> 
>> // type of the conforming construct. Subclasses need not re-implement
>> 
>> 
>> // NOTE: the return type can be declared as StaticSelf *or* as NSURL
>> 
>> 
>> //   they are interchangeable
>> 
>> 
>> static func createWithString(s: String) -> StaticSelf
>> { 
>> 
>> // ...
>> 
>> }
>> }
>> 
>> 
> 
> As I've noted before, I don't think this makes sense to encode in the 
> protocol. `Self` is already effectively invariant within a protocol. If a 
> protocol doesn't have the foresight to use StaticSelf, then you still have 
> the same problems retroactively conforming class hierarchies to the protocol. 
> Whether a conformance is inherited or not feels more natural as a property of 
> a conformance, not something that can be legislated a priori by a protocol 
> definition.
> 
> Something like StaticSelf might still be useful as shorthand within a class 
> definition with a long-winded name, though `StaticSelf` feels kind of long as 
> a shortcut to me.
> 
> -Joe
> ___
> 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] multi-line string literals.

[Ricardo Parada via swift-evolution]

I don't think the intent of multi-line string literals is to replace files or 
templating libraries. I use those all the time and are superior. 

I think it would be handy and make it more pleasant to use for simple cases. 

Who has not run into a little multi-line literal in your code where you 
concatenate the pieces using +, add \n at the end of each line and have to 
escape quotes?


> On May 12, 2016, at 12:36 PM, Leonardo Pessoa  wrote:
> 
> I'm not in favour of multiline strings. I believe such strings should be 
> stored in plain files and loaded as needed. It makes both the code and the 
> string cleaner to read and maintain. I've had experiences with many languages 
> that offer that resource and I could see what your code can become in terms 
> of maintainability when you have such feature on the language.
> 
> -1 from me.
> 
> - Leonardo
> 
>> On 12 May 2016 at 01:05, Eduardo Mourey Lopez Ne via swift-evolution 
>>  wrote:
>> Something like this might work
>> 
>> //string ends on the first line that doesnt start with a "
>> foo( @"
>>"
>>"   
>>"   \(author)
>>"   XML Developer's Guide
>>"   Computer
>>"   44.95
>>"   2000-10-01
>>"   An in-depth look at creating applications with   
>>  XML.
>>"   
>>"\n
>> )
>> 
>> //additionally using a +" could be used to indicate a line break
>> foo( @"
>>   +"
>>   +"   
>>   +"   \(author)
>>   +"   XML Developer's Guide
>>   +"   Computer
>>   +"   44.95
>>   +"   2000-10-01
>>   +"   An in-depth look at creating applications with   
>>  XML.
>>   +"   
>>   +"\n
>> )
>> 
>>> On May 11, 2016, at 9:48 PM, Ricardo Parada via swift-evolution 
>>>  wrote:
>>> 
>>> 
>>> 
>>> On May 11, 2016, at 2:34 PM, Vladimir.S  wrote:
>>> 
> For example:
> 
> 
> letsourceCode =@“NSString *firstName = @“John”;
> "NSString *lastName = @“Doe”;
> “NSString *fullName = [NSString stringWithFormat: @“%@
> %@“, firstName, lastName];"@
> 
> The one that would be a bit of a problem is the closing delimiter,
 
 Yes.. this is why I asked about `"@` - closing delimiter
 so.. what is the solution in your case ?
>>> 
>>> Hi Vladimir,
>>> 
>>> I don't really have a solution. Perhaps escaping the closing delimiter like 
>>> this \"@
>>> 
>>> It is not pretty but I can't think of anything else. I imagine the other 
>>> alternatives, i.e.   the triple quote `"""` and the quote plus underscore 
>>> `"_ `  have the same problem. 
>>> 
>>> If we make the continuation quote required then we don't need a closing 
>>> delimiter. That would solve the problem. But I've seen several people say 
>>> they don't like the continuation quote because they want to be able to 
>>> paste text and not have to worry much about formatting it afterwards. 
>>> ___
>>> 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] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions

[Patrick Smith via swift-evolution]

+1 to naming like this. dispatch() and dispatchSynchronously() if needed to 
please thy naming gods.


> On 13 May 2016, at 4:16 AM, Thorsten Seitz via swift-evolution 
>  wrote:
> 
> dispatch() and dispatchSync() would be my preference as asynchronous dispatch 
> is the point of GCD and synchronous dispatch is a special case and therefore 
> I think the visual asymmetry is an advantage.
> 
> -Thorsten
> 
> 
>> Am 12.05.2016 um 20:10 schrieb James Dempsey via swift-evolution 
>> >:
>> 
>> 
>>> On May 11, 2016, at 8:02 PM, Ricardo Parada >> > wrote:
>>> 
>>> 
>>> 
>>> For synchronously and asynchronously how about the adverbs before the verb:
>>> 
>>> syncDispatch()
>>> asyncDispatch()
>> 
>> 
>> I think with the abbreviation ‘sync’ it’s very easy to read ‘sync’ as a verb 
>> and dispatch as a noun.
>> 
>> i.e. I’m going to sync up with you about our plan
>> i.e. I received a dispatch from headquarters
>> 
>> I would be very fine with
>> 
>> dispatchAsync() and dispatchSync() as method names.
>> 
>> 
>> 
>>> 
>>> ?
>>> 
>>> On May 11, 2016, at 10:50 AM, James Dempsey >> > wrote:
>>> 
> So maybe that will conform to the API naming guideline?  Or would the 
> verb have to be in the base name of the func?
 
 
 It seems from the guidelines that the intent is for the verb to be in the 
 base name of the func, especially since there is another set of guidelines 
 for naming function parameters.
 
 In general the other methods in the proposal are verbs (perform(), 
 notify(), wait(), cancel(), etc.)
 
 At least for me, not including a verb makes the API read like the sentence 
 “The dog quickly”.  This wasn’t so bad in the C API, because you could 
 read the word ‘dispatch’ as the verb.
 
 
 Looking at the current GDC API, it does seem like dispatching 
 synchronously is the rare and special case.
 
 Could there be just a single dispatch() method, with async as a flag with 
 a default value of true?
 
 It might be a little ugly because most of the other parameters of the 
 proposed asynchronously() method would not apply in the sync case.
 
 James
 
 
 
> On May 11, 2016, at 7:14 AM, Ricardo Parada  > wrote:
> 
> Jacob Bandes-Storch suggested:
> 
> synchronously(execute work: …)
> 
> So maybe that will conform to the API naming guideline?  Or would the 
> verb have to be in the base name of the func?
> 
> Or perhaps:
> 
> synchronously(dispatch work: …)
> asynchronously(dispatch work: …)
> 
> 
> 
>> On May 11, 2016, at 9:32 AM, James Dempsey via swift-evolution 
>> > wrote:
>> 
>> The method names
>> 
>>  synchronously()
>>  asynchronously() 
>> 
>> are both adverbs, not noun phrases or verb phrases.
>> These methods have side effects, so each name should have a verb in it 
>> to make it a verb phrase.
>> 
>> 
>> Since these are the methods where you actually dispatch a block into a 
>> queue
>> 
>> dispatchSynchronously()
>> dispatchAsynchronously()
>> 
>> would include the verb in the name of the methods.
>> 
> 
 
>> 
>> ___
>> 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-0086: Drop NS Prefix in Swift Foundation

[Patrick Smith via swift-evolution]

Hi Tony,

Thanks for the response! As Kevin said:

“And if done right, the swiftified types can operate without Foundation at all”

This is why I think DispatchData would be superior to NSData, as NSData brings 
along all the rest of Foundation, whereas the entire Dispatch library looks 
like a great fit for Swift.

In fact, won’t Foundation require Dispatch as a dependency? So there’s already 
a doubling there if it is.

I think Dispatch is much more native than Foundation, and would vote to have 
its Dispatch- prefixes removed rather than Foundation remove its NS- ones.

Patrick


> On 13 May 2016, at 5:06 AM, Tony Parker  wrote:
> 
>> 
>> On May 12, 2016, at 1:32 AM, Patrick Smith via swift-evolution 
>> > wrote:
>> 
>> I second Matthew’s points. I believe dropping NS- is more harmful than 
>> helpful, especially for the future. People have been using Foundation with 
>> the prefix for decades, so I don’t think there’s a longing need that will 
>> make using it in Swift unbearable. It has an older Objective-C flavoured 
>> approach, relying heavily on classes, run loops, key value observing (e.g. 
>> NSOperation), exceptions, and notifications. I think its philosophy will 
>> stand out more than its NS- prefix. Even if many classes become value types, 
>> it feels more like a port.
>> 
>> I think for something to be so central as the recommended ‘foundational’ 
>> library for Swift, it carries too much baggage, which is unfortunate in the 
>> light of Swift’s radical eagerness to reject unnecessary legacy.
>> 
>> Many Foundation classes expect NSObject subclasses for delegates and for key 
>> value coding & observing. Key value observing requires on-the-fly 
>> subclassing at run time, something which goes strongly against Swift’s 
>> philosophy AFAIK.
>> 
>> Foundation is in some cases a wrapper around underlying technologies such as 
>> GCD, because years ago an Objective-C wrapper was seen as a more friendly, 
>> more safe, and a more familiar object-oriented approach. With Swift we have 
>> the power to make those technologies themselves more friendly, safe, and 
>> familiar with modernisations such as the current proposal for libdispatch. 
>> Extensions allow us to add properties and methods directly to the native 
>> types.
>> 
>> NSURL has methods such as .getResourceValue(_:forKey:) that involve mutable 
>> state.
>> 
>> I think removing the prefixes will take valuable real estate for types such 
>> as ‘URL’ and ‘Data’, which instead can have new replacements made, focused 
>> on the use-cases of only Swift. I think DispatchData could be a fine choice 
>> for ‘Data’, and has the strong benefit that it bridges to NSData on Darwin.
>> 
> 
> Perhaps you missed it, but SE-0069 adds corresponding value types for URL and 
> Data, among others.
> 
> - Tony
> 
>> I fully support the idea of improving Foundation, and of there being a 
>> Linux-compatible version. I don’t support it being as first class as the 
>> standard library or libdispatch, and don’t support removing the NS prefixes.
>> 
>> Patrick
>> 
>> 
>>> On 11 May 2016, at 1:36 AM, Matthew Johnson via swift-evolution 
>>> > wrote:
>>> 
 What is your evaluation of the proposal?
>>> I very much support hoisting types, updating enumerations, and updating the 
>>> NSStringEncoding constants.  
>>> 
>>> I do not support dropping NS on type level names.  Dropping the 2 character 
>>> prefix is a very small benefit and it comes with very real costs.  I 
>>> believe unprefixed top level names should not be taken without a manual 
>>> review of the API design.  
>>> 
>>> Types which will be value types in the future are obvious candidates for 
>>> redesign but are not the only types whose API would benefit by human 
>>> consideration and Swiftification.  Keeping the NS prefix until this happens 
>>> recognizes that the Swiftification of Foundation is a work in progress.  It 
>>> will give us more options in the future that don’t involve breaking 
>>> changes.  
>>> 
>>> It will also serve as a signal to developers about what kinds of APIs 
>>> should be considered idiomatic in Swift.  If we want developers to learn 
>>> how to distinguish idiomatic Swift, our API guidelines, etc from 
>>> Objective-C mappings we need to provide some cues.  I believe name prefixes 
>>> are a good way to do this.
>>> 
>>> I hope that we will move forward with most of this proposal while keeping 
>>> the NS prefix for top-level names.
>>> 
 Is the problem being addressed significant enough to warrant a change to 
 Swift?
>>> Yes, but we need to do this carefully, deliberately and in a way that we 
>>> won’t regret in the future.  I believe several parts of the proposal are 
>>> warranted, but the namesake “drop NS prefix” portion should deferred until 
>>> each type receives manual consideration and possibly 

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

[Pierre Habouzit via swift-evolution]

> On May 12, 2016, at 10:49 AM, Jose Cheyo Jimenez via swift-evolution 
>  wrote:
> 
> 
>> On May 11, 2016, at 7:09 AM, Matt Wright via swift-evolution 
>> > wrote:
>> 
>>> 
>>> On May 10, 2016, at 11:52 PM, Jacob Bandes-Storch via swift-evolution 
>>> > wrote:
>>> 
>>> 
>>>* What is your evaluation of the proposal?
>>> 
>>> I'm generally in favor of a modernized API overlay like this (and I've 
>>> written something like it myself, albeit much simpler), but I'm hoping this 
>>> proposal can go through another round or two of 
>>> discussion/bikeshedding/revision before approval.
>>> 
>>> (Small note: I'm really happy about the strong-typed-ness of the Source 
>>> subclasses, e.g. how mergeData is only available for Add/Or.)
>>> 
>>> In no particular order, here are some things on which I'm unclear, or 
>>> not-so-+1:
>>> 
>>> - synchronously()'s block parameter should be @noescape. Perhaps more 
>>> arguably, it should have a generic return type and rethrows, like 
>>> autoreleasepool now does.
>> 
>> Both of these are present in the changes I have for this proposal. The 
>> former point is a mistake in my proposal text, the latter is an unfortunate 
>> oversight on my part in putting together the proposal document.
>> 
>>> - The names asynchronously(execute:) and synchronously(execute:) don't seem 
>>> to fit with any API guidelines I'm aware of. Did you consider including the 
>>> verb in the method name?  
>> 
>> We did. Of the number of names that we discussed, none of them were perfect. 
>> sync/async are common in other languages but don’t fit the general direction 
>> of the Swift 3 naming conventions. Using `dispatchAsynchronously` is an 
>> extremely long method name, even more so than `asynchronously`. `perform` 
>> does not capture the sync/async nature of the calls particularly well, 
>> compared to DispatchWorkItem where `perform` immediately executes the block.
>> 
>>> (And I'm guessing that "func synchronously(work:...)" is meant to be "func 
>>> synchronously(execute work:...)”?)
>> 
>> Right.
>> 
>>> As another bikeshed-item, I'd vote for "Data.init(withoutCopying:...)" 
>>> rather than "(bytesNoCopy:...)", and perhaps whenDone() instead of notify().
>> 
>> Here the init() functions closely mirror Data from Foundation, the 
>> Objective-C class is toll-free bridged to NSData and we desired a close 
>> match to the Foundation Swift API. `notify` is Dispatch-only API though, 
>> I’ll go think over that one.
>> 
>>> - Are DispatchWorkItemFlags meant to overlay dispatch_block_flags? It would 
>>> be nice to explicitly list these in the proposal.
>> 
>> The dispatch_block_* API is completely superseded by DispatchWorkItem in the 
>> proposal. DispatchWorkItemFlags is the equivalent to dispatch_block_flags.
>> 
>>> - Are functions like dispatch_barrier_sync totally gone in favor of passing 
>>> a .barrier flag? It would be nice to explicitly state this in the proposal.
>> 
>> Yes, you can supply .barrier to either `synchronously` or `asynchronously`, 
>> or create a DispatchWorkItem as a barrier item. Where possible the multiple 
>> variants of a class (dispatch_async, dispatch_barrier_async, etc) are 
>> collapsed into a single method with default arguments.
>> 
>>> - I echo Austin's concerns about subclassability. I think it would be 
>>> dangerously misleading if the classes were subclassable from user code, 
>>> even if it didn't work properly.
>> 
>> Building at compile time will fail. So you wouldn’t get very far trying to 
>> use them, I plan to investigate adding `final` here (it’s only absent for 
>> technical reasons, as the classes originate from Objective-C).
>> 
>>> - What of the APIs provided on Semaphore and Group objects? I'd like to see 
>>> these before I vote for the proposal.
>> 
>> These would be transformed similarly, I will include them when updating the 
>> proposal.
>> 
>> class DispatchSemaphore : DispatchObject {   
>>   
>> 
>>  init(value: Int)
>> 
>>  func wait(timeout: DispatchTime = default) -> Int
>> 
>>  func wait(walltime timeout: DispatchWalltime) -> Int
>> 
>>  func signal() -> Int
>> 
>> }
>> 
>> class DispatchGroup : DispatchObject {
>> 
>>  init()  
>>   
>> 
>>  func wait(timeout: DispatchTime = default) -> Int
>> 
>>  func wait(walltime timeout: DispatchWalltime) -> Int
>> 
>>  func notify(queue: DispatchQueue, block: () -> Void)
>> 
>>  func enter()
>> 
>>  func leave()
>> 
>> }
>> 
>> 
>>> - What will dispatch_set_target_queue's replacement look like look like?
>> 
>> extension DispatchObject {   
>>
>> 
>>  func 

Re: [swift-evolution] [Pitch] Consistent bridging for NSErrors at the language boundary

[Charles Srstka via swift-evolution]

> On May 6, 2016, at 10:16 PM, Charles Srstka  wrote:
> 
>> On May 5, 2016, at 2:06 PM, Charles Srstka via swift-evolution 
>> > wrote:
>> 
>> I formerly posted a less-fleshed-out version of this in the “Reducing 
>> bridging magic” thread, but I thought this might warrant its own pitch. What 
>> do you all think?
>> 
>> MOTIVATION:
>> 
>> Over the past couple of years, Swift has made great strides toward seamless 
>> interoperability with existing Objective-C APIs, and with SE-0005, SE-0033, 
>> SE-0057, SE-0062, SE-0064, and SE-0070, seems poised to become even better 
>> in that regard. However, there still exists one major pain point when going 
>> back and forth between Swift and Objective-C, and that lies in the area of 
>> error reporting. Passing errors between Objective-C and Swift APIs is 
>> currently quite awkward, for several reasons:
>> 
>> - The Swift-approved mechanism for reporting errors is a protocol named 
>> ErrorType (ErrorProtocol in the latest sources). However, Objective-C 
>> represent errors using a class named NSError. In addition to being a 
>> reference type, which feels quite unnatural for an error object by Swift’s 
>> conventions, NSError follows a completely paradigm from what most 
>> ErrorProtocol objects use to store errors, using a string-based domain and 
>> and integer code, along with a userInfo dictionary to store information to 
>> be presented to the user. While the domain and code are available as methods 
>> on ErrorProtocol, they are prefixed with underscores, and there is no direct 
>> equivalent to userInfo.
>> 
>> - Unlike other Objective-C classes like NSString and NSArray which are 
>> consistently bridged to value types when presenting Objective-C interfaces 
>> to Swift, the handling of NSError objects is inconsistent. Objective-C APIs 
>> which return an error by reference using an autoreleasing NSError ** pointer 
>> are converted to use the Swift try/catch mechanism, presenting the returned 
>> error as an ErrorProtocol (which is actually an NSError). Similarly, Swift 
>> APIs using try/catch are presented to Objective-C as autoreleasing NSError 
>> ** pointers, and the ErrorProtocol-conforming error is converted to an 
>> NSError when it is called by Objective-C. However, when passing around error 
>> objects in any way other than these, the errors are not bridged. An 
>> Objective-C API that takes an NSError, such as NSApp’s -presentError: 
>> method, still leaves NSError as the type in the interface presented to 
>> Swift, as do the many asynchronous APIs in Cocoa that return an NSError as 
>> one of the arguments to a completion handler. Swift APIs that accept 
>> ErrorProtocols, on the other hand, are not presented to Objective-C at all, 
>> necessitating any such APIs also be declared to take NSErrors.
>> 
>> - To convert ErrorProtocols to NSErrors, Swift provides a bridging 
>> mechanism, invoked via “as NSError”, which wraps the error in a private 
>> NSError subclass class called _SwiftNativeNSError. This subclass can be cast 
>> back to the original error type, thus returning the original wrapped error. 
>> When a Swift API that is marked “throws” is called from Objective-C and then 
>> throws an error, the same bridging mechanism is invoked. However, this 
>> bridging is not very useful, since Cocoa tends to use NSError’s userInfo 
>> dictionary to present error information to the user, and ErrorProtocol 
>> contains no equivalent to the userInfo dictionary. The result of this is 
>> that when a Swift API throws an error, and this error is passed to Cocoa, 
>> the user tends to get a generic error message instead of something actually 
>> useful.
>> 
>> - The above problem means that a Swift developer must be very careful never 
>> to use “as NSError”, and to be sure to construct an NSError when throwing an 
>> error in an API that may be called from Objective-C, rather than simply 
>> throwing the error directly, or else the error will not be properly 
>> presented. If the developer makes a mistake here, it will not be known until 
>> runtime. I have personally wasted quite a bit of time trying to hunt down 
>> points in a complicated program where an error was accidentally converted to 
>> NSError via the bridge rather than explicitly.
>> 
>> - The same problem also puts the Swift developer between a rock and a hard 
>> place, if they have other code that wants to check these errors. In a 
>> pure-Swift program, checking against a particular error can often be done 
>> simply via an equality check. If the error has been converted to NSError via 
>> the bridge, this also works, since the bridge will return the original Swift 
>> error when casted. However, if the API that threw the error has been 
>> conscientious about constructing an NSError to avoid the userInfo issue, the 
>> NSError will not be easily castable back to the original Swift error 

Re: [swift-evolution] [Review] SE-0075: Adding a Build Configuration Import Test

[Erica Sadun via swift-evolution]

> On May 12, 2016, at 7:30 PM, Dany St-Amant via swift-evolution 
>  wrote:
> 
> 
>> On May 10, 2016, at 2:49 PM, Chris Lattner via swift-evolution 
>>  wrote:
>> 
>> Hello Swift community,
>> 
>> The review of "SE-0075: Adding a Build Configuration Import Test" begins now 
>> and runs through May 16. The proposal is available here:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0075-import-test.md
>> 
>> * What is your evaluation of the proposal?
> 
> The goal is valid, but I do have an issue with the 'canImport'. In my world 
> it's not because you can import something that you want to use it. So for 
> conditional compile code, I see this more as a 'didImport'. 
> 
> Unfortunately for the conditional import, since I'm on the page of it's not 
> because you can, that you should; I think it better serve by checking against 
> the os() or arch(). Though, there is a need to ask to import something that 
> might not exist; will this require both 'canImport' and 'didImport', or 
> should we, along my 'didImport', include a 
> 'weakImport/quietImport/importIfExist' which ignores failure to import?


canImport (or whatever it ends up being called) is deliberate.

You test before you import:

#if canImport(x)
import x
#else
...
#endif

and you test at the use-site

#if canImport(x)
   // use things that are available in x
#else
...

So you don't import UIKit unless you *can*, and you don't use UIColor unless 
you can import UIKit. This follows closely on the design of __has_include.

-- E


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

Re: [swift-evolution] [Review] SE-0075: Adding a Build Configuration Import Test

[Dany St-Amant via swift-evolution]

> On May 10, 2016, at 2:49 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> Hello Swift community,
> 
> The review of "SE-0075: Adding a Build Configuration Import Test" begins now 
> and runs through May 16. The proposal is available here:
> 
>  
> https://github.com/apple/swift-evolution/blob/master/proposals/0075-import-test.md
> 
>  * What is your evaluation of the proposal?

The goal is valid, but I do have an issue with the 'canImport'. In my world 
it's not because you can import something that you want to use it. So for 
conditional compile code, I see this more as a 'didImport'. 

Unfortunately for the conditional import, since I'm on the page of it's not 
because you can, that you should; I think it better serve by checking against 
the os() or arch(). Though, there is a need to ask to import something that 
might not exist; will this require both 'canImport' and 'didImport', or should 
we, along my 'didImport', include a 'weakImport/quietImport/importIfExist' 
which ignores failure to import?

>  * Is the problem being addressed significant enough to warrant a change to 
> Swift?

With common source there's a need to be able to compile code against different 
API providing the same functionality, so something like this is needed

>  * 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?

Followed, the initial discussion, but not recalling much about it.

Dany

> More information about the Swift evolution process is available at
> 
>  https://github.com/apple/swift-evolution/blob/master/process.md
> 
> Thank you,
> 
> -Chris Lattner
> Review Manager
> ___
> swift-evolution mailing list
> swift-evolution@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] [Draft] Introducing StaticSelf, an Invariant Self

[Matthew Johnson via swift-evolution]

Erica Sadun and I have written a proposal are following up the recent 
discussion thread "[RFC] #Self” with a proposal to introduce StaticSelf, an 
invariant Self.

The recent discussion can be found here: 
http://thread.gmane.org/gmane.comp.lang.swift.evolution/16565 


The proposal can be found here: 
https://github.com/anandabits/swift-evolution/blob/static-self/proposals/-static-self.md
 


We look forward to continuing the discussion.  We plan to submit a PR in the 
near future after incorporating your final feedback.

Thanks,
Matthew
Introducing StaticSelf, an Invariant Self

Proposal: TBD
Authors: Matthew Johnson , Erica Sadun 

Status: TBD
Review manager: TBD
Introduction

This proposal introduces a new keyword that provides consistent invariant type 
semantics in all contexts.

The Swift-evolution thread about this topic can be found here: [RFC] #Self 

Motivation

The distinction between covariant and non-covariant type references come into 
play when
conforming non-final classes to protocols. Fixing a protocol requirement to a 
covarying type
means that a method returning Self must be overriden by all subclasses in order 
to return
the correct, matching type.

This proposal builds on the covariant construct Self accepted in SE–0068 

to introduce an invariant type identifier. It enables protocol declarations to 
consistently
refer to a type that is fixed at compile time. This ensures that subclasses can 
inherit
protocol implementations without having to re-implement that code at each level 
of
inheritance.

Under this proposal, a new identifier keyword is fixed in use at the point of 
protocol conformance
to the static type of that construct. 

class A: MyProtocol
The invariant StaticSelf identifier will always refer to A, unlike Self, which 
is covarying and refers to
the type of the actual instance. Since multiple inheritance for non-protocol 
types is disallowed,
this establishes this invariant type identifier with no possibility for 
conflict.

Consider the following example, under the current system:

protocol StringCreatable {
static func createWithString(s: String) -> Self
}

extension NSURL: StringCreatable {
 // cannot conform because NSURL is non-final
 // error: method 'createWithString' in non-final class 'NSURL' must return 
`Self` to conform to protocol 'A'
}
Introducing a static, invariant version of Self permits the desired conformance:

protocol StringCreatable {
static func createWithString(s: String) -> StaticSelf
}

extension NSURL: StringCreatable {
 // can now conform conform because NSURL is fixed and matches the static
 // type of the conforming construct. Subclasses need not re-implement
 // NOTE: the return type can be declared as StaticSelf *or* as NSURL
 //   they are interchangeable
 static func createWithString(s: String) -> StaticSelf { 
 // ...
 }
}
Additional Utility

The utility of StaticSelf is not limited to protocols. A secondary use enables 
code to refer to the lexical context’s current type without explicitly 
mentioning its name. This provides a useful shortcut when referencing static 
type members with especially long names and when re-purposing code between 
types.

class StructWithAVeryLongName {
static func foo() -> String {
  // ...
}
func bar() {
  // ...
  let s = StaticSelf.foo()
  //
}
}
Detailed Design

This proposal introduces StaticSelf, a new keyword that may be used in 
protocols to refer to the invariant static type of a conforming construct. 
StaticSelf may also be used in the lexical context of any type declaration. In 
such use, the keyword is identical to spelling out the full name of that type.

Impact on existing code

Being additive, there should be no impact on existing code.

Alternatives considered

The keyword is not fixed at this time. Alternatives that have been discussed 
include StaticType, InvariantSelf, SelfType, or Type. The community is welcome 
to bikeshed on the most clear and concise name for this keyword.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0084: Allow trailing commas in parameter lists and tuples

[Joe Groff via swift-evolution]

> On May 12, 2016, at 4:47 PM, Chris Lattner  wrote:
> 
> On May 11, 2016, at 9:47 AM, Joe Groff  wrote:
>> +1 from me. We should be consistent in either accepting or rejecting 
>> trailing commas everywhere we have comma-delimited syntax. I'm in favor of 
>> accepting it, since it's popular in languages where it's supported to enable 
>> a minimal-diff style, so that changes to code don't impact neighboring lines 
>> for purely syntactic reasons. If you add an argument to a function, without 
>> trailing comma support, a comma has to be added to dirty the previous line:
>> 
>>  --- a.swift
>>  +++ a.swift
>>   foo(
>> x: 0,
>>  -  y: 1
>>  +  y: 1,
>>  +  z: 2
>>   )
>> 
>> Trailing commas avoid this:
>> 
>>  --- a.swift
>>  +++ a.swift
>>   foo(
>> x: 0,
>> y: 1,
>>  +  z: 2,
>>   )
> 
> You’re arguing that you want to read Swift code written like this?

I wouldn't mind it. The standard library already uses this style for function 
parameters, modulo the trailing comma, and I certainly prefer it to:

>   --- a.swift
>   +++ a.swift
>foo( x: 0
>   , y: 1
>   +   , z: 2
>   )

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

Re: [swift-evolution] [Review] SE-0084: Allow trailing commas in parameter lists and tuples

[Chris Lattner via swift-evolution]

On May 11, 2016, at 9:47 AM, Joe Groff  wrote:
> +1 from me. We should be consistent in either accepting or rejecting trailing 
> commas everywhere we have comma-delimited syntax. I'm in favor of accepting 
> it, since it's popular in languages where it's supported to enable a 
> minimal-diff style, so that changes to code don't impact neighboring lines 
> for purely syntactic reasons. If you add an argument to a function, without 
> trailing comma support, a comma has to be added to dirty the previous line:
> 
>   --- a.swift
>   +++ a.swift
>foo(
>  x: 0,
>   -  y: 1
>   +  y: 1,
>   +  z: 2
>)
> 
> Trailing commas avoid this:
> 
>   --- a.swift
>   +++ a.swift
>foo(
>  x: 0,
>  y: 1,
>   +  z: 2,
>)

You’re arguing that you want to read Swift code written like this?

-Chris

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

Re: [swift-evolution] [Review] SE-0086: Drop NS Prefix in Swift Foundation

[Kevin Ballard via swift-evolution]

On Mon, May 9, 2016, at 03:20 PM, Douglas Gregor via swift-evolution wrote:
>  * What is your evaluation of the proposal?
 
+1 to enum renaming / hoisting, including turning NSStringEncoding into
an enum, but -1 on dropping the NS prefix. I agree with a lot of what
the other -1 people have said, but the 2 biggest reasons for me are:
 
1. The NS prefix is a signal that the type is probably an Objective-C
   class, and with the enum renaming/hoisting this signal will become
   even stronger. The fact that it's an Objective-C class means that
   it's not Swift-like, it's a reference type, it doesn't participate in
   copy-on-write mutation, etc.
 
2. Dropping the NS prefix means that a *lot* of pretty generic names are
   now owned by Foundation, which makes it difficult to implement the
   same concept in the Swift standard library. A lot of these names
   aren't likely to end up in the Swift stdlib, but I'd rather be
   cautious about this and not take any of these names.
 
By keeping the NS prefixes, we can then "swiftify" these APIs on an
ongoing basis and drop the prefix once a type has been "swiftified"
(which includes turning things into value types when applicable, not
merely renaming methods). And if done right, the swiftified types can
operate without Foundation at all, the same way
String/Array/Dictionary/Set are independent implementations that bridge
to/from Obj-C.
 
As a side note, regardless of everything else, we really should not
rename NSJSONSerialization to JSONSerialization. This class is a
specific implementation of a JSON encoder/decoder that operates on
Foundation types. The name JSONSerialization should be reserved for the
potential use of a Swift-native JSON encoder/decoder.

>  * Is the problem being addressed significant enough to warrant a
>change to Swift?
 
I don't think so. I'm not sure what the benefit of dropping the "NS"
prefix is supposed to be at all, besides saving 2 keystrokes. The
proposal says this is to "establish these libraries as fundamental and
native Swift libraries" by "making their naming style match the
convention established by the standard library", but I don't think this
is actually the right way to do this. Renaming these classes doesn't
make the API feel like native Swift (biggest example is value vs
reference types). What would make them feel like native Swift is writing
a native Swift type with a native Swift API and native Swift conventions
that bridges to/from the obj-c class (e.g. how Swift 3 is gaining the
URL value type).

>  * How much effort did you put into your review? A glance, a quick
>reading, or an in-depth study?
 
A quick reading of the proposal, as well as reading previous discussions
about this topic.
 
-Kevin Ballard
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Optional assignment operator

[Chris Lattner via swift-evolution]

> On May 12, 2016, at 2:38 PM, Tod Cunningham via swift-evolution 
>  wrote:
> 
> I ended up creating a ??= operator about a month ago to do something very 
> similar.  It’s a shame it won’t be made part of the official library.  
> Although, it is very easy to add.
> 
> 
> Just like the ?? operator the default value is only evaluated if the optional 
> in nil.  However, unlike ?? it will
> 
> change the optional to be equal to the value on the right, iff the optional 
> was nil.

We formally discussed & rejected this already:
http://article.gmane.org/gmane.comp.lang.swift.evolution/7694

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

Re: [swift-evolution] Referencing zero-parameter functions

[Alex Hoppen via swift-evolution]

Since there doesn’t seem to be much support for the proposal, I’ll drop it and 
incorporate Alternative 1 into the #selector proposal like Doug suggested.

– Alex

> On 12 May 2016, at 20:52, Douglas Gregor  wrote:
> 
> 
>> On May 6, 2016, at 12:34 AM, Alex Hoppen via swift-evolution 
>> > wrote:
>> 
>> Thanks for your feedback so far. Based on the discussion, I have updated the 
>> proposal to let `foo` refer to the zero-parameter function instead of 
>> `foo(_)`.
>> 
>> The updated proposal is also available on GitHub: 
>> https://github.com/ahoppen/swift-evolution/blob/reference-zero-param-func/proposals/-refernce-zero-param-func.md
>>  
>> .
> 
>> 
>> Again comments would be greatly appreciated.
> 
> General comment: now that this proposal has pivoted to always requiring the 
> argument labels when referencing a function, the title and introduction are 
> misleading. This is a *much* larger change than Alternative 1 or Alternative 
> 2, and is now source-breaking.
> 
> (Personally, I still think “Alternative 1” is the right answer)
> 
>   - Doug
> 
>> 
>> – Alex
>> 
>> Referencing zero-parameter functions
>> 
>> Proposal: SE- 
>> 
>> Author(s): Alex Hoppen , Pyry Jahkola 
>> 
>> Status: Draft
>> Review manager: TBD
>> 
>>  
>> Introduction
>> 
>> Since the approval of SE-0021 
>> 
>>  it is possible to reference a function by its argument names using the 
>> foo(arg:) syntax but there is no way to reference a zero-parameter function. 
>> foo currently references all methods with base name foo. If there are 
>> multiple methods with this base name, one has to disambiguate the referenced 
>> function by its type using as.
>> 
>> 
>> This proposal changes the behaviour of foo to always reference a 
>> zero-parameter function. To reference a function with more parameters, the 
>> argument labels have to be explicitly named (e.g. foo(arg:)).
>> 
>> Originally, the proposal sought to introduce the new syntax foo(_) to 
>> reference an overloaded function with zero parameters, but was discarded 
>> based on the discussion on swift-evolution 
>> .
>> 
>> 
>>  
>> Motivation
>> 
>> Consider the following example
>> 
>> class Bar {
>>   func foo() {
>>   }
>> 
>>   func foo(arg: Int) {
>>   }
>> }
>> You can reference foo(arg: Int) using Bar.foo(arg:) but there is currently 
>> no syntax to reference foo() without using disambiguation by type Bar.foo as 
>> () -> Void. We believe this is a major hole in the current disambiguation 
>> syntax.
>> 
>> 
>>  
>> Proposed
>>  solution
>> 
>> We propose that Bar.foo only references methods with no parameters just as 
>> Bar.foo(arg:) references the methods with one argument named arg.
>> 
>> This is a breaking change since Bar.foo currently refers to all methods with 
>> base name foo.
>> 
>> 
>>  
>> Detailed
>>  design
>> 
>> The existing syntax Bar.foo is reinterpreted to not reference any method on 
>> Bar with base name foo but to only reference functions named foo that take 
>> no parameters.
>> 
>> If two overloads with zero-parameters exist with different return types, 
>> disambiguation has still to be done via as just like with the foo(arg:) 
>> syntax.
>> 
>> 
>>  
>> Impact
>>  on existing code
>> 
>> Existing code that uses Bar.foo to reference methods with parameters needs 
>> to be changed. We believe this will effect many developers, so a fix-it 
>> would be essential.
>> 
>> 
>>  
>> Possible
>>  issues
>> 
>> Bar.foo may be mistaken for a reference to a property, since all other 
>> references to functions will contain parenthesis if this proposal is 
>> accepted.
>> 
>> Most functions are not overloaded and using the base name only offers a 
>> shorthand way to reference these functions. If this proposal is accepted, 
>> this shorthand is no longer available for methods with parameters.
>> 
>> 
>>  
>> Alternatives
>>  

Re: [swift-evolution] Optional assignment operator

[Tod Cunningham via swift-evolution]

I ended up creating a ??= operator about a month ago to do something very 
similar.  It’s a shame it won’t be made part of the official library.  
Although, it is very easy to add.


Just like the ?? operator the default value is only evaluated if the optional 
in nil.  However, unlike ?? it will

change the optional to be equal to the value on the right, iff the optional was 
nil.


infix operator ??= {

associativity right

precedence 90

assignment

}


public func ??=(inout optional: VALUE?, @autoclosure defaultValue: () 
throws -> VALUE) rethrows -> VALUE {

if let value = optional {

return value

} else {

let value = try defaultValue()

optional = value

return value

}

}


- Tod

From: 
> 
on behalf of Trent Nadeau via swift-evolution 
>
Reply-To: Trent Nadeau >
Date: Thursday, May 12, 2016 at 10:52 AM
To: Rod Brown >
Cc: Douglas Gregor via swift-evolution 
>
Subject: Re: [swift-evolution] Optional assignment operator

This same operator (except spelled as ??=) was up as a proposal and rejected in 
February. See http://thread.gmane.org/gmane.comp.lang.swift.evolution/7694.

On Thu, May 12, 2016 at 10:41 AM, Rod Brown via swift-evolution 
> wrote:
I’m tentatively supportive of this proposal. I definitely see the use case 
(assign only if not not nil).  Interested to hear the opinions of others here :)

-Rod


> On 12 May 2016, at 11:59 PM, Jose Manuel Sánchez Peñarroja via 
> swift-evolution > 
> wrote:
>
> Sorry if this has already been discussed, if so I couldn’t find it.
>
> I would like to propose to add to Swift an optional assignment operator ?=
> I think this would nicely align with the other uses of ?, and avoid 
> repetition in this case:
>
>   var value = 5
>
>   var possibleNewValue: Int? = nil
>
>   value = possibleNewValue ?? value
>
> It would be used like this:
>
>   value ?= possibleNewValue
>
> I’ve found quite a few cases in which this would be very useful to me. It is 
> already possible to implement it, but having it defined in the standard 
> library would define an standard, and prevent different semantics depending 
> on who implements it.
>
>
>   infix operator ?= {
> associativity right
>  precedence 90
>  assignment
>   }
>
>   func ?= (inout lhs: T, rhs: T?) {
>   lhs = rhs ?? lhs
>   }
>
>
> Regards,
> José Manuel Sanchez
> ___
> 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



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

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

[Ben Rimmington via swift-evolution]

> On 12 May 2016, at 19:03, Matt Wright  wrote:
> 
> Are you talking about ambiguity at a compiler level, or in human-reading?

I meant ambiguous for people familiar with libdispatch. For example, the 
`interval`, `leeway`, and `delta` parameters of the following are all in 
nanoseconds:

* dispatch_io_set_interval
* dispatch_source_set_timer
* dispatch_time
* dispatch_walltime

```
_ = DispatchTime.now() + 3_500_000_000 // 3.5 seconds or 111 years?
_ = DispatchTime.now() + .seconds(3.5) // OK
```

The other associated value types were changed (from Int to Int64) to support 
32-bit platforms.

DISPATCH_TIME_FOREVER can also be represented as an optional parameter:

```
func wait(timeout: DispatchTime? = nil)
```

Is it possible to eliminate the DispatchWalltime type?

```
public struct DispatchTime {

private let _value: dispatch_time_t

public init() {
_value = dispatch_time(DISPATCH_TIME_NOW, 0)
}

public init(walltime: UnsafePointer?) {
_value = dispatch_walltime(walltime, 0)
}
}
```

-- Ben

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

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

[Jordan Rose via swift-evolution]

We've been over this a few times before on the list. I personally like naming 
this thing "Any<…>" in the same vein as "AnyObject", "AnyClass", and 
"AnySequence". I also see Thorsten (and in the past Brent's?) argument for 
calling it "all" or "All", because it's enforcing multiple constraints.

I will say that "type" is unlikely to see much traction simply because it is an 
incredibly common name for both properties and locals. We went through that 
exercise when trying to name both "static" and "dynamicType" and decided that 
it would be too confusing, even if we could make the parsing work.

The feature itself has definitely been shown to be useful when working with the 
Cocoa frameworks, if not in general. I don't see it on JIRA yet but we have it 
internally tracked in Radar as rdar://problem/15873071 
.

Jordan


> On May 12, 2016, at 13:08, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> I don’t get the part how `all<>` should allow `any<>`. Could you explain that 
> a little bit in detail (I’m not familiar with Ceylon)?
> 
> From my point of view `any<>` is something different that I pitched here. 
> `any<>` could be proposed in its own thread, because it is way different than 
> `type<>`. Or can we refine the rules of `type<>` to get to `any<>`?
> 
> Here is a little example where `any<>` gets strange:
> 
> func foo(value: any) -> any {
> 
> // how would one use value here?
> // what about its properties
> // what will foo return and how to use the result
> }
> 
> One benefit of `any<>` is the replacement of overloading, at least for the 
> type part of the function.
> 
> I’d like to propose `type<>` as the base extension to the language in that 
> direction, before we’ll move forward with more complex scenarios (just like 
> Chris did with generic typealias).
> 
> This function is clear that it only will work if you provide a subclass of an 
> UIView which conforms to SomeProtocol (nice addition for library design).
> 
> func foo(value: type) -> type {
> 
> // use it as a UIView and SomeProtocol at the same type
> return value // return type works great
> }
> 
> We can split the value just fine:
> 
> let mergedValue = foo(SomeViewThatWorks)
> let view: UIView = mergedValue
> let protocolValue: SomeProtocol = mergedValue
> 
> And merge it back together:
> 
> guard let newMergedValue = view as? type else { /* do 
> something */ }
> 
> `all<>` could be seen as an alternative name for `type<>`, but to me its not 
> clear what `all<>` can do, whereas `type<>` is almost like `protocol<>`.
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 12. Mai 2016 bei 21:40:24, Thorsten Seitz (tseit...@icloud.com 
> ) schrieb:
> 
>> Ceylon uses „&" for intersection types, i.e.
>> 
>> SomeRealClass & SomeProtocol
>> 
>> and the bar („|“) for union types, i.e. 
>> 
>> String | Int
>> 
>> That has proven to be very lightweight and readable in Ceylon where it is 
>> heavily used to good effect.
>> 
>> 
>> I agree with you that
>> 
>> type 
>> 
>> is much nicer than protocol<> for intersection types but to keep the door 
>> open for union types, I would prefer
>> 
>> all
>> 
>> This would allow
>> 
>> any
>> 
>> to be used for union types.
>> 
>> -Thorsten
>> 
>> 
>>> Am 12.05.2016 um 16:09 schrieb Adrian Zubarev via swift-evolution 
>>> >:
>>> 
>>> protocol 
>>> protocol 
>>> 
>>> This feels really odd to me. 
>>> 
>>> `type` is more clear I’d say.
>>> 
>>> I think this would be a good addition to the type system and allow us to 
>>> build more complex and type save code.
>>> 
>>> But still I’d love to discuss if there might be any disadvantages to this 
>>> feature.
>>> 
>>> -- 
>>> Adrian Zubarev
>>> Sent with Airmail
>>> 
>>> Am 12. Mai 2016 bei 15:11:00, Vladimir.S (sva...@gmail.com 
>>> ) schrieb:
>>> 
 protocol<> 
>>> ___
>>> 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] merge types and protocols back together with type<Type, Protocol, ...>

[Adrian Zubarev via swift-evolution]

I don’t get the part how `all<>` should allow `any<>`. Could you explain that a 
little bit in detail (I’m not familiar with Ceylon)?

>From my point of view `any<>` is something different that I pitched here. 
>`any<>` could be proposed in its own thread, because it is way different than 
>`type<>`. Or can we refine the rules of `type<>` to get to `any<>`?

Here is a little example where `any<>` gets strange:

func foo(value: any) -> any {

    // how would one use value here?
    // what about its properties
    // what will foo return and how to use the result
}

One benefit of `any<>` is the replacement of overloading, at least for the type 
part of the function.

I’d like to propose `type<>` as the base extension to the language in that 
direction, before we’ll move forward with more complex scenarios (just like 
Chris did with generic typealias).

This function is clear that it only will work if you provide a subclass of an 
UIView which conforms to SomeProtocol (nice addition for library design).

func foo(value: type) -> type {

    // use it as a UIView and SomeProtocol at the same type
    return value // return type works great
}

We can split the value just fine:

let mergedValue = foo(SomeViewThatWorks)
let view: UIView = mergedValue
let protocolValue: SomeProtocol = mergedValue

And merge it back together:

guard let newMergedValue = view as? type else { /* do 
something */ }

`all<>` could be seen as an alternative name for `type<>`, but to me its not 
clear what `all<>` can do, whereas `type<>` is almost like `protocol<>`.

-- 
Adrian Zubarev
Sent with Airmail

Am 12. Mai 2016 bei 21:40:24, Thorsten Seitz (tseit...@icloud.com) schrieb:

Ceylon uses „&" for intersection types, i.e.

SomeRealClass & SomeProtocol

and the bar („|“) for union types, i.e. 

String | Int

That has proven to be very lightweight and readable in Ceylon where it is 
heavily used to good effect.


I agree with you that

type 

is much nicer than protocol<> for intersection types but to keep the door open 
for union types, I would prefer

all

This would allow

any

to be used for union types.

-Thorsten


Am 12.05.2016 um 16:09 schrieb Adrian Zubarev via swift-evolution 
:

protocol 
protocol 

This feels really odd to me. 

`type` is more clear I’d say.

I think this would be a good addition to the type system and allow us to build 
more complex and type save code.

But still I’d love to discuss if there might be any disadvantages to this 
feature.

-- 
Adrian Zubarev
Sent with Airmail

Am 12. Mai 2016 bei 15:11:00, Vladimir.S (sva...@gmail.com) schrieb:

protocol<> 
___
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-0084: Allow trailing commas in parameter lists and tuples

[Thorsten Seitz via swift-evolution]

> Am 11.05.2016 um 23:12 schrieb Douglas McKenna via swift-evolution 
> :
> 
> In all this discussion of trailing commas, there is a use-case that's not 
> been discussed, which is whether or not a trailing comma after the last of a 
> list of comma-separated items (typically on separate lines) makes it easier 
> to write a program that outputs Swift code declaring that list.  It does.
> 
> If such a trailing comma is going to raise a syntax error, and one writes a 
> loop for a set of listed items that will print those listed items, one either 
> has to special case the first item to not be preceded by a ",\n", and print 
> all subsequent items prefixed with a ",\n"; or one has to end all items 
> except the last with a ",\n".  Either way is a pain, adds an extra test to 
> the loop, and likely will be implemented erroneously the first time.

I would expect that loop to be abstracted away so that special case has to be 
written only once. You would probably like indentation for nesting as well in 
the generated code, so there is already reason to write a little helper (let’s 
call it IndentingWriter) or maybe use a full blown framework for pretty 
printing (e.g. like Haskell’s Text.PrettyPrint, see 
https://downloads.haskell.org/~ghc/latest/docs/html/libraries/pretty-1.1.2.0/Text-PrettyPrint.html).

-Thorsten


> 
> Code that is written by other code always has a strong incentive to avoid 
> raising any compiler error/warnings, and so tends not to be read as much by 
> humans who might think there's a missing item after the last extra comma.
> 
> How about a syntax warning/error for only those trailing commas that end a 
> line that contains a previous comma serving the same syntactic function at 
> the same syntactic level?
> 
> 
> Doug McKenna
> 
> ___
> 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] merge types and protocols back together with type<Type, Protocol, ...>

[Thorsten Seitz via swift-evolution]

Ceylon uses „&" for intersection types, i.e.

SomeRealClass & SomeProtocol

and the bar („|“) for union types, i.e. 

String | Int

That has proven to be very lightweight and readable in Ceylon where it is 
heavily used to good effect.


I agree with you that

type 

is much nicer than protocol<> for intersection types but to keep the door open 
for union types, I would prefer

all

This would allow

any

to be used for union types.

-Thorsten


> Am 12.05.2016 um 16:09 schrieb Adrian Zubarev via swift-evolution 
> :
> 
> protocol 
> protocol 
> 
> This feels really odd to me. 
> 
> `type` is more clear I’d say.
> 
> I think this would be a good addition to the type system and allow us to 
> build more complex and type save code.
> 
> But still I’d love to discuss if there might be any disadvantages to this 
> feature.
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 12. Mai 2016 bei 15:11:00, Vladimir.S (sva...@gmail.com 
> ) schrieb:
> 
>> protocol<> 
> ___
> 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-0086: Drop NS Prefix in Swift Foundation

[Tony Parker via swift-evolution]

> On May 12, 2016, at 1:32 AM, Patrick Smith via swift-evolution 
>  wrote:
> 
> I second Matthew’s points. I believe dropping NS- is more harmful than 
> helpful, especially for the future. People have been using Foundation with 
> the prefix for decades, so I don’t think there’s a longing need that will 
> make using it in Swift unbearable. It has an older Objective-C flavoured 
> approach, relying heavily on classes, run loops, key value observing (e.g. 
> NSOperation), exceptions, and notifications. I think its philosophy will 
> stand out more than its NS- prefix. Even if many classes become value types, 
> it feels more like a port.
> 
> I think for something to be so central as the recommended ‘foundational’ 
> library for Swift, it carries too much baggage, which is unfortunate in the 
> light of Swift’s radical eagerness to reject unnecessary legacy.
> 
> Many Foundation classes expect NSObject subclasses for delegates and for key 
> value coding & observing. Key value observing requires on-the-fly subclassing 
> at run time, something which goes strongly against Swift’s philosophy AFAIK.
> 
> Foundation is in some cases a wrapper around underlying technologies such as 
> GCD, because years ago an Objective-C wrapper was seen as a more friendly, 
> more safe, and a more familiar object-oriented approach. With Swift we have 
> the power to make those technologies themselves more friendly, safe, and 
> familiar with modernisations such as the current proposal for libdispatch. 
> Extensions allow us to add properties and methods directly to the native 
> types.
> 
> NSURL has methods such as .getResourceValue(_:forKey:) that involve mutable 
> state.
> 
> I think removing the prefixes will take valuable real estate for types such 
> as ‘URL’ and ‘Data’, which instead can have new replacements made, focused on 
> the use-cases of only Swift. I think DispatchData could be a fine choice for 
> ‘Data’, and has the strong benefit that it bridges to NSData on Darwin.
> 

Perhaps you missed it, but SE-0069 adds corresponding value types for URL and 
Data, among others.

- Tony

> I fully support the idea of improving Foundation, and of there being a 
> Linux-compatible version. I don’t support it being as first class as the 
> standard library or libdispatch, and don’t support removing the NS prefixes.
> 
> Patrick
> 
> 
>> On 11 May 2016, at 1:36 AM, Matthew Johnson via swift-evolution 
>> > wrote:
>> 
>>> What is your evaluation of the proposal?
>> I very much support hoisting types, updating enumerations, and updating the 
>> NSStringEncoding constants.  
>> 
>> I do not support dropping NS on type level names.  Dropping the 2 character 
>> prefix is a very small benefit and it comes with very real costs.  I believe 
>> unprefixed top level names should not be taken without a manual review of 
>> the API design.  
>> 
>> Types which will be value types in the future are obvious candidates for 
>> redesign but are not the only types whose API would benefit by human 
>> consideration and Swiftification.  Keeping the NS prefix until this happens 
>> recognizes that the Swiftification of Foundation is a work in progress.  It 
>> will give us more options in the future that don’t involve breaking changes. 
>>  
>> 
>> It will also serve as a signal to developers about what kinds of APIs should 
>> be considered idiomatic in Swift.  If we want developers to learn how to 
>> distinguish idiomatic Swift, our API guidelines, etc from Objective-C 
>> mappings we need to provide some cues.  I believe name prefixes are a good 
>> way to do this.
>> 
>> I hope that we will move forward with most of this proposal while keeping 
>> the NS prefix for top-level names.
>> 
>>> Is the problem being addressed significant enough to warrant a change to 
>>> Swift?
>> Yes, but we need to do this carefully, deliberately and in a way that we 
>> won’t regret in the future.  I believe several parts of the proposal are 
>> warranted, but the namesake “drop NS prefix” portion should deferred until 
>> each type receives manual consideration and possibly redesign.
>> 
>>> Does this proposal fit well with the feel and direction of Swift?
>> Mostly yes.  However, taking top-level unprefixed names without a process of 
>> Swiftification does not.
>> 
>>> If you have used other languages or libraries with a similar feature, how 
>>> do you feel that this proposal compares to those?
>> I think this question is N/A for this proposal.
>> 
>> I hesitate in saying this, but I think the best comparison to consider is 
>> the origin of Foundation and Cocoa themselves.  They are fantastic 
>> Objective-C APIs.  If they had originated by wrapping pre-existing APIs 
>> written in a different language with different idioms and then incrementally 
>> enhanced I wonder if they may have been less fantastic.  
>> 
>> I believe reserving unprefixed top-level names 

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

[Jacob Bandes-Storch via swift-evolution]

This would defeat @noescape and any generic return type we might want to
add to dispatchSync.
On Thu, May 12, 2016 at 11:52 AM Hooman Mehr via swift-evolution <
swift-evolution@swift.org> wrote:

>
> Exactly: I also consider synchronous dispatch a special case not worthy of
> sacrificing a better name (`dispatch`) for it. I prefer to have a single
> `dispatch` as the main function name. Here is my proposed modified
> signature based on the proposal
> 
> :
>
> class DispatchQueue : DispatchObject {
> func dispatch(synchronous: Bool, work: @convention(block) () -> Void)
>
>
>
> func dispatch(
> group: DispatchGroup? = nil,
> qos: DispatchQoS = .unspecified,
> flags: DispatchWorkItemFlags = [],
> work: @convention(block) () -> Void
>
> )
> }
>
> queue. dispatch(group: group) {
> print("Hello World")
> }
>
> queue.dispatch(synchronous: true) {
> print("Hello World")
> }
>
>
> In the above synchronous variant, passing synchronous flag as false simply
> delegates to async function. This saves us from having to use a name like
> dispatchSync().
>
> Actually, I currently have my own wrapper for libdispatch that works in
> this way. My wrapper also unifies more of the API under the same `dispatch`
> function with more optional parameters. For example, `apply` functions are
> also handled with `dispatch` function. It will iterate if `iterations:`
> optional parameter is specified and so on. I find it very convenient to use
> and the resulting code is very clear and readable.
>
> I know, this goes further than importing the existing API, but concurrency
> API has such a profound impact on the overall style and readability of code
> that it is worth going even further than what proposal suggests to get a
> really clear and readable API.
>
> Hooman
>
> On May 12, 2016, at 11:16 AM, Thorsten Seitz via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> dispatch() and dispatchSync() would be my preference as asynchronous
> dispatch is the point of GCD and synchronous dispatch is a special case and
> therefore I think the visual asymmetry is an advantage.
>
> -Thorsten
>
>
> Am 12.05.2016 um 20:10 schrieb James Dempsey via swift-evolution <
> swift-evolution@swift.org>:
>
>
> On May 11, 2016, at 8:02 PM, Ricardo Parada  wrote:
>
>
>
> For synchronously and asynchronously how about the adverbs before the verb:
>
> syncDispatch()
> asyncDispatch()
>
>
>
> I think with the abbreviation ‘sync’ it’s very easy to read ‘sync’ as a
> verb and dispatch as a noun.
>
> i.e. I’m going to sync up with you about our plan
> i.e. I received a dispatch from headquarters
>
> I would be very fine with
>
> dispatchAsync() and dispatchSync() as method names.
>
>
>
>
> ?
>
> On May 11, 2016, at 10:50 AM, James Dempsey  wrote:
>
> So maybe that will conform to the API naming guideline?  Or would the verb
> have to be in the base name of the func?
>
>
> It seems from the guidelines that the intent is for the verb to be in the
> base name of the func, especially since there is another set of guidelines
> for naming function parameters.
>
> In general the other methods in the proposal are verbs (perform(),
> notify(), wait(), cancel(), etc.)
>
> At least for me, not including a verb makes the API read like the sentence
> “The dog quickly”.  This wasn’t so bad in the C API, because you could read
> the word ‘dispatch’ as the verb.
>
>
> Looking at the current GDC API, it does seem like dispatching
> synchronously is the rare and special case.
>
> Could there be just a single dispatch() method, with async as a flag with
> a default value of true?
>
> It might be a little ugly because most of the other parameters of the
> proposed asynchronously() method would not apply in the sync case.
>
> James
>
>
>
> On May 11, 2016, at 7:14 AM, Ricardo Parada  wrote:
>
> Jacob Bandes-Storch suggested:
>
> synchronously(execute work: …)
>
> So maybe that will conform to the API naming guideline?  Or would the verb
> have to be in the base name of the func?
>
> Or perhaps:
>
> synchronously(dispatch work: …)
> asynchronously(dispatch work: …)
>
>
>
> On May 11, 2016, at 9:32 AM, James Dempsey via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> The method names
>
> synchronously()
> asynchronously()
>
> are both adverbs, not noun phrases or verb phrases.
> These methods have side effects, so each name should have a verb in it to
> make it a verb phrase.
>
>
> Since these are the methods where you actually dispatch a block into a
> queue
>
> dispatchSynchronously()
> dispatchAsynchronously()
>
> would include the verb in the name of the methods.
>
>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> 

Re: [swift-evolution] Referencing zero-parameter functions

[Douglas Gregor via swift-evolution]

> On May 6, 2016, at 12:34 AM, Alex Hoppen via swift-evolution 
>  wrote:
> 
> Thanks for your feedback so far. Based on the discussion, I have updated the 
> proposal to let `foo` refer to the zero-parameter function instead of 
> `foo(_)`.
> 
> The updated proposal is also available on GitHub: 
> https://github.com/ahoppen/swift-evolution/blob/reference-zero-param-func/proposals/-refernce-zero-param-func.md
>  
> .

> 
> Again comments would be greatly appreciated.

General comment: now that this proposal has pivoted to always requiring the 
argument labels when referencing a function, the title and introduction are 
misleading. This is a *much* larger change than Alternative 1 or Alternative 2, 
and is now source-breaking.

(Personally, I still think “Alternative 1” is the right answer)

- Doug

> 
> – Alex
> 
> Referencing zero-parameter functions
> 
> Proposal: SE- 
> 
> Author(s): Alex Hoppen , Pyry Jahkola 
> 
> Status: Draft
> Review manager: TBD
> 
>  
> Introduction
> 
> Since the approval of SE-0021 
> 
>  it is possible to reference a function by its argument names using the 
> foo(arg:) syntax but there is no way to reference a zero-parameter function. 
> foo currently references all methods with base name foo. If there are 
> multiple methods with this base name, one has to disambiguate the referenced 
> function by its type using as.
> 
> 
> This proposal changes the behaviour of foo to always reference a 
> zero-parameter function. To reference a function with more parameters, the 
> argument labels have to be explicitly named (e.g. foo(arg:)).
> 
> Originally, the proposal sought to introduce the new syntax foo(_) to 
> reference an overloaded function with zero parameters, but was discarded 
> based on the discussion on swift-evolution 
> .
> 
> 
>  
> Motivation
> 
> Consider the following example
> 
> class Bar {
>   func foo() {
>   }
> 
>   func foo(arg: Int) {
>   }
> }
> You can reference foo(arg: Int) using Bar.foo(arg:) but there is currently no 
> syntax to reference foo() without using disambiguation by type Bar.foo as () 
> -> Void. We believe this is a major hole in the current disambiguation syntax.
> 
> 
>  
> Proposed
>  solution
> 
> We propose that Bar.foo only references methods with no parameters just as 
> Bar.foo(arg:) references the methods with one argument named arg.
> 
> This is a breaking change since Bar.foo currently refers to all methods with 
> base name foo.
> 
> 
>  
> Detailed
>  design
> 
> The existing syntax Bar.foo is reinterpreted to not reference any method on 
> Bar with base name foo but to only reference functions named foo that take no 
> parameters.
> 
> If two overloads with zero-parameters exist with different return types, 
> disambiguation has still to be done via as just like with the foo(arg:) 
> syntax.
> 
> 
>  
> Impact
>  on existing code
> 
> Existing code that uses Bar.foo to reference methods with parameters needs to 
> be changed. We believe this will effect many developers, so a fix-it would be 
> essential.
> 
> 
>  
> Possible
>  issues
> 
> Bar.foo may be mistaken for a reference to a property, since all other 
> references to functions will contain parenthesis if this proposal is accepted.
> 
> Most functions are not overloaded and using the base name only offers a 
> shorthand way to reference these functions. If this proposal is accepted, 
> this shorthand is no longer available for methods with parameters.
> 
> 
>  
> Alternatives
>  considered
> 
>  
> Alternative
>  1: Bar.foo() inside #selector
> 
> Let Bar.foo() refer to the zero-parameter function only inside #selector as 
> it was proposed by Doug Gregor here 
> . 
> This requires the proposal to disallow 

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

[Hooman Mehr via swift-evolution]

Exactly: I also consider synchronous dispatch a special case not worthy of 
sacrificing a better name (`dispatch`) for it. I prefer to have a single 
`dispatch` as the main function name. Here is my proposed modified signature 
based on the proposal 
:

class DispatchQueue : DispatchObject {
func dispatch(synchronous: Bool, work: @convention(block) () -> Void)

func dispatch(
group: DispatchGroup? = nil, 
qos: DispatchQoS = .unspecified, 
flags: DispatchWorkItemFlags = [], 
work: @convention(block) () -> Void)
}

queue. dispatch(group: group) {
print("Hello World")
}

queue.dispatch(synchronous: true) {
print("Hello World")
}

In the above synchronous variant, passing synchronous flag as false simply 
delegates to async function. This saves us from having to use a name like 
dispatchSync(). 

Actually, I currently have my own wrapper for libdispatch that works in this 
way. My wrapper also unifies more of the API under the same `dispatch` function 
with more optional parameters. For example, `apply` functions are also handled 
with `dispatch` function. It will iterate if `iterations:` optional parameter 
is specified and so on. I find it very convenient to use and the resulting code 
is very clear and readable.

I know, this goes further than importing the existing API, but concurrency API 
has such a profound impact on the overall style and readability of code that it 
is worth going even further than what proposal suggests to get a really clear 
and readable API.

Hooman 
> On May 12, 2016, at 11:16 AM, Thorsten Seitz via swift-evolution 
>  wrote:
> 
> dispatch() and dispatchSync() would be my preference as asynchronous dispatch 
> is the point of GCD and synchronous dispatch is a special case and therefore 
> I think the visual asymmetry is an advantage.
> 
> -Thorsten
> 
> 
>> Am 12.05.2016 um 20:10 schrieb James Dempsey via swift-evolution 
>> >:
>> 
>> 
>>> On May 11, 2016, at 8:02 PM, Ricardo Parada >> > wrote:
>>> 
>>> 
>>> 
>>> For synchronously and asynchronously how about the adverbs before the verb:
>>> 
>>> syncDispatch()
>>> asyncDispatch()
>> 
>> 
>> I think with the abbreviation ‘sync’ it’s very easy to read ‘sync’ as a verb 
>> and dispatch as a noun.
>> 
>> i.e. I’m going to sync up with you about our plan
>> i.e. I received a dispatch from headquarters
>> 
>> I would be very fine with
>> 
>> dispatchAsync() and dispatchSync() as method names.
>> 
>> 
>> 
>>> 
>>> ?
>>> 
>>> On May 11, 2016, at 10:50 AM, James Dempsey >> > wrote:
>>> 
> So maybe that will conform to the API naming guideline?  Or would the 
> verb have to be in the base name of the func?
 
 
 It seems from the guidelines that the intent is for the verb to be in the 
 base name of the func, especially since there is another set of guidelines 
 for naming function parameters.
 
 In general the other methods in the proposal are verbs (perform(), 
 notify(), wait(), cancel(), etc.)
 
 At least for me, not including a verb makes the API read like the sentence 
 “The dog quickly”.  This wasn’t so bad in the C API, because you could 
 read the word ‘dispatch’ as the verb.
 
 
 Looking at the current GDC API, it does seem like dispatching 
 synchronously is the rare and special case.
 
 Could there be just a single dispatch() method, with async as a flag with 
 a default value of true?
 
 It might be a little ugly because most of the other parameters of the 
 proposed asynchronously() method would not apply in the sync case.
 
 James
 
 
 
> On May 11, 2016, at 7:14 AM, Ricardo Parada  > wrote:
> 
> Jacob Bandes-Storch suggested:
> 
> synchronously(execute work: …)
> 
> So maybe that will conform to the API naming guideline?  Or would the 
> verb have to be in the base name of the func?
> 
> Or perhaps:
> 
> synchronously(dispatch work: …)
> asynchronously(dispatch work: …)
> 
> 
> 
>> On May 11, 2016, at 9:32 AM, James Dempsey via swift-evolution 
>> > wrote:
>> 
>> The method names
>> 
>>  synchronously()
>>  asynchronously() 
>> 
>> are both adverbs, not noun phrases or verb phrases.
>> These methods have side effects, so each name should have a verb in it 
>> to make it a verb phrase.
>> 
>> 
>> Since these are the methods where you actually dispatch a block into a 
>> queue
>> 
>> dispatchSynchronously()
>> dispatchAsynchronously()
>> 
>> would 

Re: [swift-evolution] [Review] SE-0084: Allow trailing commas in parameter lists and tuples

[David Owens II via swift-evolution]

What is your evaluation of the proposal?
+1. Commas are already redundant syntax to provide additional clarity over 
spaces in nearly all use cases. Being strict on this provides no material 
benefit. On the other hand, being super strict about this does have measurable, 
real-world impacts. I can provide examples of days of build time and breaking 
change back-outs because C++ lacks this very feature.

Is the problem being addressed significant enough to warrant a change to Swift?
Yes.

Does this proposal fit well with the feel and direction of Swift?
Yes

If you have used other languages or libraries with a similar feature, how do 
you feel that this proposal compares to those?
Yes. It scales well to large team sizes as well, especially within the context 
of merging code together. The code that used trailing commas never has 
potentially build breaking merges in this same context. However, when merging C 
or C++ code, this is often a headache to deal with this.

How much effort did you put into your review? A glance, a quick reading, or an 
in-depth study?
I’ve read the proposal and used languages both with and without this feature.

-David

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

[Thorsten Seitz via swift-evolution]

dispatch() and dispatchSync() would be my preference as asynchronous dispatch 
is the point of GCD and synchronous dispatch is a special case and therefore I 
think the visual asymmetry is an advantage.

-Thorsten


> Am 12.05.2016 um 20:10 schrieb James Dempsey via swift-evolution 
> :
> 
> 
>> On May 11, 2016, at 8:02 PM, Ricardo Parada > > wrote:
>> 
>> 
>> 
>> For synchronously and asynchronously how about the adverbs before the verb:
>> 
>> syncDispatch()
>> asyncDispatch()
> 
> 
> I think with the abbreviation ‘sync’ it’s very easy to read ‘sync’ as a verb 
> and dispatch as a noun.
> 
> i.e. I’m going to sync up with you about our plan
> i.e. I received a dispatch from headquarters
> 
> I would be very fine with
> 
> dispatchAsync() and dispatchSync() as method names.
> 
> 
> 
>> 
>> ?
>> 
>> On May 11, 2016, at 10:50 AM, James Dempsey > > wrote:
>> 
 So maybe that will conform to the API naming guideline?  Or would the verb 
 have to be in the base name of the func?
>>> 
>>> 
>>> It seems from the guidelines that the intent is for the verb to be in the 
>>> base name of the func, especially since there is another set of guidelines 
>>> for naming function parameters.
>>> 
>>> In general the other methods in the proposal are verbs (perform(), 
>>> notify(), wait(), cancel(), etc.)
>>> 
>>> At least for me, not including a verb makes the API read like the sentence 
>>> “The dog quickly”.  This wasn’t so bad in the C API, because you could read 
>>> the word ‘dispatch’ as the verb.
>>> 
>>> 
>>> Looking at the current GDC API, it does seem like dispatching synchronously 
>>> is the rare and special case.
>>> 
>>> Could there be just a single dispatch() method, with async as a flag with a 
>>> default value of true?
>>> 
>>> It might be a little ugly because most of the other parameters of the 
>>> proposed asynchronously() method would not apply in the sync case.
>>> 
>>> James
>>> 
>>> 
>>> 
 On May 11, 2016, at 7:14 AM, Ricardo Parada > wrote:
 
 Jacob Bandes-Storch suggested:
 
 synchronously(execute work: …)
 
 So maybe that will conform to the API naming guideline?  Or would the verb 
 have to be in the base name of the func?
 
 Or perhaps:
 
 synchronously(dispatch work: …)
 asynchronously(dispatch work: …)
 
 
 
> On May 11, 2016, at 9:32 AM, James Dempsey via swift-evolution 
> > wrote:
> 
> The method names
> 
>   synchronously()
>   asynchronously() 
> 
> are both adverbs, not noun phrases or verb phrases.
> These methods have side effects, so each name should have a verb in it to 
> make it a verb phrase.
> 
> 
> Since these are the methods where you actually dispatch a block into a 
> queue
> 
> dispatchSynchronously()
> dispatchAsynchronously()
> 
> would include the verb in the name of the methods.
> 
 
>>> 
> 
> ___
> 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] [RFC] #Self

[Thorsten Seitz via swift-evolution]

I absolutely share Matthew’s view of #Self (or whatever it ends up being 
called) and think this is really needed.

On the other hand I don’t think that a simple placeholder for the defining type 
is necessary as proposed by Vladimir, especially not if it is the third variant 
of something Self-like. 

-Thorsten


> Am 12.05.2016 um 17:36 schrieb Matthew Johnson via swift-evolution 
> :
> 
>> 
>> On May 12, 2016, at 10:19 AM, Vladimir.S > > wrote:
>> 
>> Inline
>> 
>> On 11.05.2016 21:31, Matthew Johnson wrote:
>>> 
>>> 
>>> Sent from my iPad
>>> 
 On May 11, 2016, at 11:43 AM, Vladimir.S > wrote:
 
 Well, I believe I understand now what *you mean* under #Self. OK.
 Thank you for clarifications. In my terminology 'this' could be called
 BaseSelf. Your "thing" just can not be called #Self. IMO in initial
 proposal #Self means not more than placeholder for the concrete type
 name(inside type declaration or inside protocol).
 
 You propose just something different, more advanced than initial
 #Self, you propose not some static "thing" but extended behavior if
 #Self is a return type of protocol requirement.
 
 I strictly against to couple the initial proposal of #Self and your
 proposal for extended features (for protocol conformance of
 `->#Self`). Please be clear and obvious regarding the name of that
 feature. I really think the behavior you propose can not be called
 #Self(or Type)
 
 What I suggest: de-couple these proposals to:
 
 a) initial proposal of #Self as placeholder for concrete type name.
 Choose the name for it. Probably StaticSelf, or Type, or somehting
 else
 
 b) your proposal for BaseSelf feature. I'll definitely support it with
 just name changed to clearly reflect its propose.
>>> 
>>> I don't believe the initial proposal stated how it would behave in a
>>> protocol.  However I do believe the feature I am talking about covers
>>> all of the use cases Erica had in mind while also providing useful
>>> semantics when used in a protocol requirement.  Erica, please correct me
>>> if I'm wrong.
>> 
>> Well.. Yes, I also don't see statements regarding how `->#Self` would behave 
>> in a protocol in initial proposal. *This is why* I suggest to de-couple what 
>> *was* in initial proposall, and what you are suggesting as *addition* to the 
>> proposal.
>> 
>> Again. I fully support the behavior you suggest, but I strongly feel like 
>> 'that' #Self can't be named #Self, as some derived(from conformed class) 
>> class X does not return 'self'. It return 'self or one of base classes'. 
>> Let's call it 'SelfOrBase' for now.
>> 
>> What we have now:
>> 
>> protocol A {
>>  func f1() -> Self
>>  func f2(s: Self)
>> }
>> 
>> struct S: A {
>>  func f1() -> S/*#Self*/ {return self}
>>  func f2(s: S/*#Self*/) {}
>> }
>> 
>> class C: A {
>>  func f1() -> Self /*only Self, can't write C here*/ {return self}
>>  func f2(s: C/*#Self*/) {}
>> }
>> 
>> final class FC: A {
>>  func f1() -> Self /*can write FC here, ==#Self*/ {return self}
>>  func f2(s: FC/*#Self*/) {}
>> }
>> 
>> I believe, for clarity, after we introduce #Self(or whatever name it will 
>> have) we need to require `#Self` in protocol as type of method parameter:
>> 
>> protocol A {
>>  func f1() -> Self // this could be Self and could be #Self
> 
> What in the original proposal makes you think Self and #Self would be 
> interchangeable here?  Again, the proposal was for #Self to be invariant.  
> Self is covariant.  Those are very different things.  
> 
> The semantics in the original proposal were unspecified with regards to 
> protocols.  I am simply extending it to retain the invariant semantics that 
> the proposal *did* specified when it is used as a protocol requirement.
> 
>>  func f2(s: #Self) // this always will be #Self in implementation
>> 
>>  // this should not be allowed any more
>>  //func f2(s: Self)
>> }
>> 
>> struct S: A {
>>  // as you see we'd have `->#Self` in implementation
>>  func f1() -> #Self {return self}
>>  func f2(s: #Self) {}
>> }
>> 
>> class C: A {
>>  func f1() -> Self /*only Self, can't write C here*/ {return self}
>>  func f2(s: #Self) {}
>> }
>> 
>> final class FC: A {
>>  func f1() -> Self /*can write FC here, ==#Self*/ {return self}
>>  func f2(s: #Self) {}
>> }
>> 
>> The above is what *I think* was in initial proposal regarding #Self.
>> 
>> About your suggestion. I just trying to understand it in details.
>> Please point me where I understand your suggestion incorrectly.
>> 
>> Do you think about such start points? :
>> 
>> class Base {
>>  func f() -> Base  {return Base()}
>> }
>> 
>> class Derived1: Base {
>>  override func f() -> Derived1  {return Derived1()}
>> }
>> 
>> class Derived2: Base {
>>  override func f() -> Derived2  {return Derived2()}
>> }
>> 
>> If so, do you 

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

[James Dempsey via swift-evolution]

> On May 11, 2016, at 8:02 PM, Ricardo Parada  wrote:
> 
> 
> 
> For synchronously and asynchronously how about the adverbs before the verb:
> 
> syncDispatch()
> asyncDispatch()


I think with the abbreviation ‘sync’ it’s very easy to read ‘sync’ as a verb 
and dispatch as a noun.

i.e. I’m going to sync up with you about our plan
i.e. I received a dispatch from headquarters

I would be very fine with

dispatchAsync() and dispatchSync() as method names.



> 
> ?
> 
> On May 11, 2016, at 10:50 AM, James Dempsey  > wrote:
> 
>>> So maybe that will conform to the API naming guideline?  Or would the verb 
>>> have to be in the base name of the func?
>> 
>> 
>> It seems from the guidelines that the intent is for the verb to be in the 
>> base name of the func, especially since there is another set of guidelines 
>> for naming function parameters.
>> 
>> In general the other methods in the proposal are verbs (perform(), notify(), 
>> wait(), cancel(), etc.)
>> 
>> At least for me, not including a verb makes the API read like the sentence 
>> “The dog quickly”.  This wasn’t so bad in the C API, because you could read 
>> the word ‘dispatch’ as the verb.
>> 
>> 
>> Looking at the current GDC API, it does seem like dispatching synchronously 
>> is the rare and special case.
>> 
>> Could there be just a single dispatch() method, with async as a flag with a 
>> default value of true?
>> 
>> It might be a little ugly because most of the other parameters of the 
>> proposed asynchronously() method would not apply in the sync case.
>> 
>> James
>> 
>> 
>> 
>>> On May 11, 2016, at 7:14 AM, Ricardo Parada >> > wrote:
>>> 
>>> Jacob Bandes-Storch suggested:
>>> 
>>> synchronously(execute work: …)
>>> 
>>> So maybe that will conform to the API naming guideline?  Or would the verb 
>>> have to be in the base name of the func?
>>> 
>>> Or perhaps:
>>> 
>>> synchronously(dispatch work: …)
>>> asynchronously(dispatch work: …)
>>> 
>>> 
>>> 
 On May 11, 2016, at 9:32 AM, James Dempsey via swift-evolution 
 > wrote:
 
 The method names
 
synchronously()
asynchronously() 
 
 are both adverbs, not noun phrases or verb phrases.
 These methods have side effects, so each name should have a verb in it to 
 make it a verb phrase.
 
 
 Since these are the methods where you actually dispatch a block into a 
 queue
 
 dispatchSynchronously()
 dispatchAsynchronously()
 
 would include the verb in the name of the methods.
 
>>> 
>> 

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

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

[Matt Wright via swift-evolution]

> On May 12, 2016, at 7:00 AM, Ben Rimmington via swift-evolution 
>  wrote:
> 
>  0088-libdispatch-for-swift3.md>
> 
> ## Type Names
> 
> I was going to suggest unprefixed type names, but having to qualify both
> `Dispatch.Data` and `Foundation.Data` would be an issue. If libdispatch
> had originally been part of Foundation, you'd need prefixes anyway:
> 
> * DispatchQueue
> * NotificationQueue
> * OperationQueue
> 
> ## Quality of Service
> 
> Should argument labels and type names match those in Foundation?
> 
> * qos:=> qualityOfService:
> * DispatchQoS => DispatchQualityOfService
> 
> Could there be a shared `Swift.QualityOfService` enum?
> 
> * QOS_CLASS_DEFAULT = 0x15
> * NSQualityOfServiceDefault = -1
> 
> The `.unspecified` QoS is not defined in NSQualityOfService.
> Would an optional QoS parameter (defaulting to nil) be better?
> 
> ## Time
> 
> The `dispatch_time` function uses a nanoseconds delta, so the operator
> overloads taking `seconds: Double` might be ambiguous at the call site.
> You could try changing the associated value types of your enum.
> 
> ```
> enum DispatchTimeInterval {
>case  seconds(Double) // changed from `Int`
>case milliseconds(Int64)  // changed from `Int`
>case microseconds(Int64)  // changed from `Int`
>case  nanoseconds(Int64)  // changed from `Int`
> }
> 
> let _ = DispatchTime.now + 3.5 // ambiguous?

Are you talking about ambiguity at a compiler level, or in human-reading? The 
other four examples are an addition with an enum type, the first one is a 
double. There’s no compiler ambiguity here.

> let a = DispatchTime.now +  .seconds(3.5)
> let b = DispatchTime.now + .milliseconds(3_500)
> let c = DispatchTime.now + .microseconds(3_500_000)
> let d = DispatchTime.now +  .nanoseconds(3_500_000_000)
> ```
> 
> Is the `DispatchTime.now` in your example a type property?

DispatchTime.now() is a function that returns the current time. The subsequent 
examples are typos (now() became a method quite late in the proposal’s 
development) and I’ll fix it up before pushing a v2 proposal that’s fixed up a 
lot of the typos that arose from late changes.

> 
> ## Data
> 
> Should the `DispatchData.append` methods have `contentsOf:` labels?
> Or could it conform to the RangeReplaceableCollection protocol?
> 
> ## Queues
> 
> My suggestions for the async/sync methods:
> 
> * enqueue(...)
> * enqueueAndWaitUntilFinished(...)
> 
> -- Ben
> 
> 
> ___
> 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-0084: Allow trailing commas in parameter lists and tuples

[Thorsten Seitz via swift-evolution]

> The review of "SE-0084: Allow trailing commas in parameter lists and tuples" 
> begins now and runs through May 16. The proposal is available here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0084-trailing-commas.md
> 
>   * What is your evaluation of the proposal?

-0.5

Trailing commas look like a mistake. While having to clean them up when editing 
parameter lists is unfortunate I prefer it to the untidy and erroneous look of 
trailing commas in the code. Remember that code is more often read than 
written, so the preference should be on readability.

I am not convinced by the diff argument either.

I am reluctantly ok with the existing ability to place trailing commas in 
arrays or dictionaries because these are conceptually more open than parameter 
lists or tuples or generic argument lists etc.

I’d prefer the alternative proposal of being able to omit commas when placing 
expressions on different lines (just like with semicolons), although I haven’t 
thought about possible parsing problems which might arise because of that.


But as long as I am not required to use trailing commas, I’m not strongly 
against this. There are more important changes to be made. I just think it is a 
bad idea :-)


>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?

No, the task of cleaning up parameter lists is small compared to the untidy and 
erroneous look of trailing commas. In addition cleaning up is only necessary at 
the end of lists.


>   * Does this proposal fit well with the feel and direction of Swift?

No. An important feature of Swift is readability which is disturbed by trailing 
commas.


>   * If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?

I haven’t.


>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

Followed the discussion and weighed the convenience of trailing commas against 
the impact on readability.

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

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

[Jose Cheyo Jimenez via swift-evolution]

> On May 11, 2016, at 7:09 AM, Matt Wright via swift-evolution 
>  wrote:
> 
>> 
>> On May 10, 2016, at 11:52 PM, Jacob Bandes-Storch via swift-evolution 
>>  wrote:
>> 
>> 
>>* What is your evaluation of the proposal?
>> 
>> I'm generally in favor of a modernized API overlay like this (and I've 
>> written something like it myself, albeit much simpler), but I'm hoping this 
>> proposal can go through another round or two of 
>> discussion/bikeshedding/revision before approval.
>> 
>> (Small note: I'm really happy about the strong-typed-ness of the Source 
>> subclasses, e.g. how mergeData is only available for Add/Or.)
>> 
>> In no particular order, here are some things on which I'm unclear, or 
>> not-so-+1:
>> 
>> - synchronously()'s block parameter should be @noescape. Perhaps more 
>> arguably, it should have a generic return type and rethrows, like 
>> autoreleasepool now does.
> 
> Both of these are present in the changes I have for this proposal. The former 
> point is a mistake in my proposal text, the latter is an unfortunate 
> oversight on my part in putting together the proposal document.
> 
>> - The names asynchronously(execute:) and synchronously(execute:) don't seem 
>> to fit with any API guidelines I'm aware of. Did you consider including the 
>> verb in the method name?  
> 
> We did. Of the number of names that we discussed, none of them were perfect. 
> sync/async are common in other languages but don’t fit the general direction 
> of the Swift 3 naming conventions. Using `dispatchAsynchronously` is an 
> extremely long method name, even more so than `asynchronously`. `perform` 
> does not capture the sync/async nature of the calls particularly well, 
> compared to DispatchWorkItem where `perform` immediately executes the block.
> 
>> (And I'm guessing that "func synchronously(work:...)" is meant to be "func 
>> synchronously(execute work:...)”?)
> 
> Right.
> 
>> As another bikeshed-item, I'd vote for "Data.init(withoutCopying:...)" 
>> rather than "(bytesNoCopy:...)", and perhaps whenDone() instead of notify().
> 
> Here the init() functions closely mirror Data from Foundation, the 
> Objective-C class is toll-free bridged to NSData and we desired a close match 
> to the Foundation Swift API. `notify` is Dispatch-only API though, I’ll go 
> think over that one.
> 
>> - Are DispatchWorkItemFlags meant to overlay dispatch_block_flags? It would 
>> be nice to explicitly list these in the proposal.
> 
> The dispatch_block_* API is completely superseded by DispatchWorkItem in the 
> proposal. DispatchWorkItemFlags is the equivalent to dispatch_block_flags.
> 
>> - Are functions like dispatch_barrier_sync totally gone in favor of passing 
>> a .barrier flag? It would be nice to explicitly state this in the proposal.
> 
> Yes, you can supply .barrier to either `synchronously` or `asynchronously`, 
> or create a DispatchWorkItem as a barrier item. Where possible the multiple 
> variants of a class (dispatch_async, dispatch_barrier_async, etc) are 
> collapsed into a single method with default arguments.
> 
>> - I echo Austin's concerns about subclassability. I think it would be 
>> dangerously misleading if the classes were subclassable from user code, even 
>> if it didn't work properly.
> 
> Building at compile time will fail. So you wouldn’t get very far trying to 
> use them, I plan to investigate adding `final` here (it’s only absent for 
> technical reasons, as the classes originate from Objective-C).
> 
>> - What of the APIs provided on Semaphore and Group objects? I'd like to see 
>> these before I vote for the proposal.
> 
> These would be transformed similarly, I will include them when updating the 
> proposal.
> 
> class DispatchSemaphore : DispatchObject {
>  
> 
>  init(value: Int)
> 
>  func wait(timeout: DispatchTime = default) -> Int
> 
>  func wait(walltime timeout: DispatchWalltime) -> Int
> 
>  func signal() -> Int
> 
> }
> 
> class DispatchGroup : DispatchObject {
> 
>  init()   
>  
> 
>  func wait(timeout: DispatchTime = default) -> Int
> 
>  func wait(walltime timeout: DispatchWalltime) -> Int
> 
>  func notify(queue: DispatchQueue, block: () -> Void)
> 
>  func enter()
> 
>  func leave()
> 
> }
> 
> 
>> - What will dispatch_set_target_queue's replacement look like look like?
> 
> extension DispatchObject {
>   
> 
>  func setTargetQueue(queue: DispatchQueue?)
> 
> }
> 
>> 
>> - What about dispatch_once?
> 
> Removed. Swift already has lazy initialisation at the language level, 
> dispatch_once is neither needed nor safe in Swift.

Hi Matt, 

What other API would be removed ? Could the proposal be updated with the API 

Re: [swift-evolution] [Review] SE-0081: Move where clause to end of declaration

[Thorsten Seitz via swift-evolution]

> Am 10.05.2016 um 20:51 schrieb Chris Lattner via swift-evolution 
> :
> 
> Hello Swift community,
> 
> The review of "SE-0081: Move where clause to end of declaration" begins now 
> and runs through May 16. The proposal is available here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0081-move-where-expression.md
> 
> 
>   * What is your evaluation of the proposal?

+1

It increases readability of generics by a far margin.
I appreciate that the proposal allows to pull out the inheritance/conformance 
constraints into the where clause, too, very much!


>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?

Yes, as more complex generics are a powerful feature of Swift and the increased 
readability helps designing and using them very much.


>   * Does this proposal fit well with the feel and direction of Swift?

Absolutely.


>   * If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?

Ceylon uses a similar syntax to declare the constraints of generic parameters:
shared interface DirectedGraph satisfies IncidenceGraph
  given V satisfies Object
  given E satisfies DirectedEdge { … }
I always found this very readable but with Swift’s ability to declare 
constraints between associated types of generic parameters this is even more 
important.


>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

Read the proposal carefully and followed the discussion.

-Thorsten

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

Re: [swift-evolution] [Review] SE-0084: Allow trailing commas in parameter lists and tuples

[L. Mihalkovic via swift-evolution]

I find it symptomatic that the 'popular' languages where this is allowed all 
seem to be rooted in scripting++ rather than in hard core, strong grammar 
languages. But i guess the two shall at some point meet... in swift?! 

Could the feature perhaps be reserved for SwiftScript 1.0 then, instead of 
added to Swift 3.0? The situation somehow reminds me of Martin Orderski's early 
decision to make XML a first class citizen in Scala to fish for more audience, 
and his recent about face and cleaning up of the grammar.

Regards
(From mobile)

> On May 12, 2016, at 6:31 PM, Erica Sadun via swift-evolution 
>  wrote:
> 
> 
>>> On May 10, 2016, at 2:58 PM, Chris Lattner via swift-evolution 
>>>  wrote:
>>> On May 10, 2016, at 12:36 PM, Tony Allevato  wrote:
>>> 
>>> Likewise for function calls; I would argue that if a function 
>>> call/definition's parameter list is likely to grow so much and/or so 
>>> frequently that a trailing comma provides significant savings, that's a 
>>> code smell that should encourage the author to redesign the function.
>> 
>> FWIW, I personally agree with this observation.
>> 
>> Parameter lists and tuples are also structurally different than collections. 
>>  Parameter lists also have labels, and (depending on how the ‘disable 
>> reordering default arguments’ decision goes) parameters may not be added and 
>> reordered arbitrarily.  Tuples are different because adding a member will 
>> often break all the code downstream because it changes the type of the 
>> value.  This is different than array and dictionary literals.
>> 
>> The only “collection like” aspect I can think of is for variadic parameter 
>> lists, but I don’t think they’re common enough to provide a special case for.
> 
> 
> I agree that the trailing comma offers its best support for situations that 
> express variadic properties. I propose that all three of the following 
> scenarios share this nature:
> At call sites with variadic arguments
> At call sites with defaulted arguments
> At definition sites with large complex argument lists or tuple members
> It's slightly easier to make the case for call sites, the first two of these 
> uses, as they exactly mirror the way collections parse members. Supporting 
> the third style of trailing commas requires the consideration of real world 
> modern Swift. 
> 
> Allowing cut and paste or commenting of entire parameter lines means simple 
> changes do not ripple out to affect other lines. In this, trailing commas 
> serve programmer intent and limit the effect in diff comparisons. As Joe 
> pointed out in one of his responses on this thread, one edit becomes one 
> diff, without extra housekeeping for other affected lines. When considered 
> together, I do believe the use cases for these scenarios are common enough to 
> be considered something other than a "special case". 
> 
> Given that SE-0060 is accepted, the third case is narrowed but should not be 
> ignored. Reordering and commenting out lines during prototyping, working in 
> playgrounds, and scripting is still common. Also, a reorder or comment when 
> trailing commas are permitted ensures that such changes are single-point 
> edits. 
> 
> As Brent points out in his review, "I was skeptical of this until a week or 
> two ago, when I had some code where I ended up commenting out certain 
> parameters." Trailing commas, although a minor feature in a major language, 
> still serves the developer and supports the overall philosophy of Swift, 
> which is as you have pointed out multiple times, an opinionated language.
> 
> -- E
> 
> ___
> 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] [RFC] #Self

[Vladimir.S via swift-evolution]

Inline

On 12.05.2016 18:36, Matthew Johnson wrote:

I believe, for clarity, after we introduce #Self(or whatever name it will
have) we need to require `#Self` in protocol as type of method parameter:

protocol A {
 func f1() -> Self // this could be Self and could be #Self


What in the original proposal makes you think Self and #Self would be
interchangeable here?  Again, the proposal was for #Self to be invariant.
 Self is covariant.  Those are very different things.


Just incorrect comment for my code. Please add in mind *in implementation* 
to the end of the comment. I don't mean that they can be interchangeable in 
protocol definition, no, I mean at the moment of implementation `->Self` 
could became `->Self` or `->#Self` depending on where it will be 
implemented. Examples of implementation was below.




The semantics in the original proposal were unspecified with regards to
protocols.  I am simply extending it to retain the invariant semantics that
the proposal *did* specified when it is used as a protocol requirement.



IMO your suggestion can not be coupled with initial proposal.
And I mean the recent(last) proposal in email I quoted in one of previous 
message, where nothing was said regarding protocols.


...

let a : A = Derived2()
let some = a.f() // you expect some.dynamicType is Derived2


The protocol specifies #Self (or Type, which we are not calling it).  It is
conformed to by Base.  This means the return type of `f` is only guaranteed
to be Base.  It *may* be Derived2, but it need not be.  Obviously given
this example we know it is Derived2 because we can see the implementation
but the type system does not.  This means `some` has type of Base.  Its
dynamicsType *may* be Derived2 (and again in this case we can see that it
will be) but that is not guaranteed by the type system.



I'm tired ;-)
You are trying to couple two IMO different things.
`#Self` as parameter's type in protocol and inside class/struct means 
'placeholder for exactly this concrete type name in implementation'. Not 
base class!
I can't understand how you can extend this meaning to "derived class 
conforms to ->#Self, but returns some base class".



What you are missing is that #Self is not the same as Self.  It is
invariant.  A was originally conformed to by Base.  The requirement is
invariant and becomes fixed by the conformance declaration.  In this case
it is fixed to Base.


Again. I'm not missing this. It is clear they are no the same. Please point 
where exactly I missed this.
But you are trying to use the same keyword `#Self`(or Type,not important) 
in meaning 'this concrete type' and in 'this or base type'.




You have not explained why you think #Self should be invariant when used in
a type context and covariant when used in a protocol context.  This
expectation is what is confusing you.  If you really what that semantic I
think the burden is on you to make the case that we need something with
this mixed semantic.  I think it is much more confusing than having
separate constructs for covariant and invariant semantics.


Just because of meaning(description) of #Self in initial proposal and its 
behavior at the implementation side(inside type body).


If you extend the meaning of your `#Self` to 'any type in hierarchy of that 
type', that I can understand.



Again, what you are calling SelfOrBase is *exactly* what I am calling Type
(or #Self).  It has consistent invariant semantics in all contexts.


Again ;-), Yes. And I'm against to name your 'thing' with the same name as 
#Self(or Type) because they mean different things, different behavior.


Actually I think I got your points, I can't accept them and it seems like 
there is no some 'common' solution. You think that it is OK to have 
`->#Self` in protocol requirements in meaning "self of any base class", but 
I can't accept and understand this.


Thank you for discussion, probably I need to re-think all of this and find 
out that I was not right. I'll let then know ;-)

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

Re: [swift-evolution] Allowing `guard let self = self else { … }` for weakly captured self in a closure.

[Hoon H. via swift-evolution]

I am replying months lately, but anyway, I just read your proposal, and I think 
this is cool.

[guard self]

I am in doubt about another stuffs such as `[guard self else …]`. I hope your 
proposal to be accepted. I am getting a bit tired of writing `guard let S = 
self else { … }`.

I am still not sure how to use mailing list… but I hope this to be a correct 
way.
…Sending again because I mistyped Evan’s address.

— Hoon H.

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

Re: [swift-evolution] [RFC] UnsafeBytePointer API for In-Memory Layout

[Andrew Trick via swift-evolution]

> On May 12, 2016, at 8:41 AM, Joe Groff  wrote:
> 
>> Future improvements
>> 
>> UnsafeBytePointer should eventually support unaligned memory access. I 
>> believe that we will eventually have a modifier that allows "packed" struct 
>> members. At that time we may also want to add a "packed" flag to 
>> UnsafeBytePointer's load and initialize methods.
> 
> We should probably call out the fact that `load` and `initialize` require 
> alignment in the meantime.

Will do.

>> When accessing a memory buffer, it is generally convenient to cast to a type 
>> with known layout and compute offsets relative to the type's size. This is 
>> how UnsafePointer works. A generic UnsafeTypePunnedPointer 
>> could be introduced with the same interface as UnsafePointer, but 
>> without the strict aliasing requirements. This seems like an overdesign 
>> simply to avoid calling strideof() in an rare use case, but nothing prevents 
>> adding this type later.
> 
> This need could also be addressed with some additional convenience methods on 
> UnsafeBytePointer to load or store at a given index, something like:
> 
>   func load(asArrayOf type: T.Type, at index: Int) -> T {
>   return (self + strideof(T) * index).load(T)
>   }
>   func initialize(asArrayOf type: T.Type, initialValue: T, at index: Int) 
> {
>   return (self + strideof(T) * index).initialize(initialValue)
>   }

Yep. I like that.

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

Re: [swift-evolution] [Review] SE-0084: Allow trailing commas in parameter lists and tuples

[Erica Sadun via swift-evolution]

> On May 10, 2016, at 2:58 PM, Chris Lattner via swift-evolution 
>  wrote:
>> On May 10, 2016, at 12:36 PM, Tony Allevato > > wrote:
>> 
>> Likewise for function calls; I would argue that if a function 
>> call/definition's parameter list is likely to grow so much and/or so 
>> frequently that a trailing comma provides significant savings, that's a code 
>> smell that should encourage the author to redesign the function.
> 
> FWIW, I personally agree with this observation.
> 
> Parameter lists and tuples are also structurally different than collections.  
> Parameter lists also have labels, and (depending on how the ‘disable 
> reordering default arguments’ decision goes) parameters may not be added and 
> reordered arbitrarily.  Tuples are different because adding a member will 
> often break all the code downstream because it changes the type of the value. 
>  This is different than array and dictionary literals.
> 
> The only “collection like” aspect I can think of is for variadic parameter 
> lists, but I don’t think they’re common enough to provide a special case for.


I agree that the trailing comma offers its best support for situations that 
express variadic properties. I propose that all three of the following 
scenarios share this nature:
At call sites with variadic arguments
At call sites with defaulted arguments
At definition sites with large complex argument lists or tuple members
It's slightly easier to make the case for call sites, the first two of these 
uses, as they exactly mirror the way collections parse members. Supporting the 
third style of trailing commas requires the consideration of real world modern 
Swift. 

Allowing cut and paste or commenting of entire parameter lines means simple 
changes do not ripple out to affect other lines. In this, trailing commas serve 
programmer intent and limit the effect in diff comparisons. As Joe pointed out 
in one of his responses on this thread, one edit becomes one diff, without 
extra housekeeping for other affected lines. When considered together, I do 
believe the use cases for these scenarios are common enough to be considered 
something other than a "special case". 

Given that SE-0060 is accepted, the third case is narrowed but should not be 
ignored. Reordering and commenting out lines during prototyping, working in 
playgrounds, and scripting is still common. Also, a reorder or comment when 
trailing commas are permitted ensures that such changes are single-point edits. 

As Brent points out in his review, "I was skeptical of this until a week or two 
ago, when I had some code where I ended up commenting out certain parameters." 
Trailing commas, although a minor feature in a major language, still serves the 
developer and supports the overall philosophy of Swift, which is as you have 
pointed out multiple times, an opinionated language.

-- E

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

Re: [swift-evolution] Swift 3 and cross platform development

[William Dillon via swift-evolution]

Hi Michael,

This topic (in a form) has come up on list before.  It's my understanding that 
the portability that is targeted is core Swift, not so much Obj-C 
interoperability.

That said, there are a few people working on Swift for MSVC, and Swift already 
works with Cygwin.  Someone has considered making Swift work with an open 
source implementation of the Obj-C libraries (I don't think it was GnuSTEP), 
but I haven't heard from them in quite a while.

I hope that helps.
- Will

> On May 12, 2016, at 8:42 AM, Michael Peternell via swift-evolution 
>  wrote:
> 
> Hi,
> 
> I've seen on the swift-evolution git repository README.md page that 
> Portability is one of the design goals for Swift 3.
> 
> Does this mean that Swift 3 will be available and useful on Windows too? So 
> that it could be used for cross platform app development on both Windows and 
> OS X (and probably also Android)?
> 
> For example, will Swift 3 be able to interoperate with Objective-C on Windows 
> (e.g. using GnuSTEP or the WinObjC bridge from Microsoft)? Maybe using 
> WinObjC+Swift on Windows, GnuSTEP+Swift on Linux and Native-objc+Swift on OS 
> X? Such an application could probably share very much code between different 
> platforms.
> 
> Regards,
> Michael
> 
> ___
> 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-0081: Move where clause to end of declaration

[Joe Groff via swift-evolution]

> On May 11, 2016, at 10:23 AM, Joe Groff via swift-evolution 
>  wrote:
> 
>> 
>> On May 11, 2016, at 6:54 AM, Thorsten Seitz  wrote:
>> 
>>> 
>>> Am 11.05.2016 um 03:56 schrieb Joe Groff via swift-evolution 
>>> :
>>> 
>>> 
> On May 10, 2016, at 4:19 PM, Douglas Gregor via swift-evolution 
>  wrote:
> 
> 
> On May 10, 2016, at 3:46 PM, Jordan Rose via swift-evolution 
>  wrote:
> 
> I think actual keyword “where” provides enough of a delimiter that it 
> won’t be hard to put something before it, and it seems unlikely to me 
> that we would want to add anything after it without some other delimiter. 
> So I’m not too concerned.
 
 Yeah, that’s my feeling as well.
>>> 
>>> One conceivable use of `where` that this would shut the door on: infix 
>>> `where` for generalized existentials, e.g. `Protocol where AssociatedType 
>>> == Int` could be the Protocol existential with Self.AssociatedType 
>>> constrained to Int.
>> 
>> Why do you think that?
> 
> This proposal moves `where` after the return type, which would be ambiguous 
> with any infix use of `where` in the type grammar.

To be clear, I'm not saying we *should* add infix `where` to the type grammar, 
only pointing out that this would prevent its use in the future.

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

Re: [swift-evolution] [Proposal] More lenient subscript methods over Collections

[Luis Henrique B. Sousa via swift-evolution]

I agree with your parenthesis, but it might not be a valid argument if we
consider that "clamp" is already a word used in the standard library

.
(but I have to say that also as a non-native speaker "within" was way more
clear to me at first sight... 8-) )

- Luis

On Thu, May 12, 2016 at 12:08 PM, Vladimir.S  wrote:

> If there is a method with such name in Range(with equal meaning) - then it
> seems like `clamping` will be the best solution here.
> (as non-native speaker I don't feel this word is often used especially in
> software development, but.. it seems like anyone who is writing in Swift
> must be strong native English speaker/writer :-P I also mean all these
> naming conversions, verb/noun, -ing/-ed/-able etc ;-) )
>
> On 12.05.2016 12:56, Luis Henrique B. Sousa wrote:
>
>> Yes, it would really be more consistent. "within" sounds great to me as
>> well, but I don't know if there is a naming convention for it.
>> I am okay to change our proposal to have those labels as two verbs -
>> instead of a preposition and a verb - as suggested by @Brent.
>>
>> More opinions?
>>
>> - Luis
>>
>> On Thu, May 12, 2016 at 7:25 AM, Brent Royal-Gordon <
>> br...@architechies.com
>> > wrote:
>>
>> > It sounds good, thanks for you suggestions @Vladimir, @Patrick and
>> @Brent.
>> >
>> > I've just updated the proposal:
>> >
>> https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/-more-lenient-collections-subscripts.md#detailed-design
>> >
>> > - Luis
>>
>> Hmm. If you're going with `checking` for one of them, perhaps the
>> other
>> should be `clamping` (for the analogous method on `Range`, which you
>> might want to use in the implementation of that subscript). That would
>> create a nicely matched pair:
>>
>> array[checking: 0..<10]
>> array[clamping: 0..<10]
>>
>> --
>> Brent Royal-Gordon
>> Architechies
>>
>>
>>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Swift 3 and cross platform development

[Michael Peternell via swift-evolution]

Hi,

I've seen on the swift-evolution git repository README.md page that Portability 
is one of the design goals for Swift 3.

Does this mean that Swift 3 will be available and useful on Windows too? So 
that it could be used for cross platform app development on both Windows and OS 
X (and probably also Android)?

For example, will Swift 3 be able to interoperate with Objective-C on Windows 
(e.g. using GnuSTEP or the WinObjC bridge from Microsoft)? Maybe using 
WinObjC+Swift on Windows, GnuSTEP+Swift on Linux and Native-objc+Swift on OS X? 
Such an application could probably share very much code between different 
platforms.

Regards,
Michael

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

Re: [swift-evolution] [RFC] UnsafeBytePointer API for In-Memory Layout

[Joe Groff via swift-evolution]

> Future improvements
> 
> UnsafeBytePointer should eventually support unaligned memory access. I 
> believe that we will eventually have a modifier that allows "packed" struct 
> members. At that time we may also want to add a "packed" flag to 
> UnsafeBytePointer's load and initialize methods.

We should probably call out the fact that `load` and `initialize` require 
alignment in the meantime.

> When accessing a memory buffer, it is generally convenient to cast to a type 
> with known layout and compute offsets relative to the type's size. This is 
> how UnsafePointer works. A generic UnsafeTypePunnedPointer 
> could be introduced with the same interface as UnsafePointer, but 
> without the strict aliasing requirements. This seems like an overdesign 
> simply to avoid calling strideof() in an rare use case, but nothing prevents 
> adding this type later.

This need could also be addressed with some additional convenience methods on 
UnsafeBytePointer to load or store at a given index, something like:

func load(asArrayOf type: T.Type, at index: Int) -> T {
return (self + strideof(T) * index).load(T)
}
func initialize(asArrayOf type: T.Type, initialValue: T, at index: Int) 
{
return (self + strideof(T) * index).initialize(initialValue)
}

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

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

[Andrew Brown via swift-evolution]

Apologies all, my iPad and I are not getting on today !

> On 12 May 2016, at 16:33, Andrew Brown via swift-evolution 
>  wrote:
> 
> 
> On First, this is a huge breaking change, and it doesn’t really have to be 
> one. The current SPM convention is to prefix C libraries with Lib. Following 
> this convention, Dispatch (which is the C version) would be renamed to 
> LibDispatch, and this new wrapper library would be called just Dispatch. With 
> this setup, the old C api would still be there (under the module 
> LibDispatch), which makes migration much easier. In the proposal, this issue 
> is not addressed at all and it even says that all code using libdispatch 
> would be affected. As it stands, that is not ok.


> Separating existing dispatch from a new SwiftDispatch is a great idea.  It 
> would give the opportunity to really spend time working on the right approach 
> for concurrency in swift without affecting existing production code and the 
> hundreds of dispatch wrappers out there.
> 
> While we're on the subject: Dispatch Queues are 'queues' ... Isn't the right 
> verb append (for asynchronous dispatch)?
> 
> DispatchQueue.main.append {
>   print("Hello Swift")
> }
> 
> After all, asyncDispatch or dispatchAsync imply you are dispatching a 
> synchronously - which you are not.  The dispatch (sending for execution) is 
> always synchronous, it's the execution which is asynchronous.
> 
> DispatchQueue.main.dispatchForAsynchronousExecution {
>   print("Help, I have repetitive strain injury")
> }
> 
> Just my 2¢
> Andrew.
> ___
> 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] [RFC] #Self

[Matthew Johnson via swift-evolution]

> On May 12, 2016, at 10:19 AM, Vladimir.S  wrote:
> 
> Inline
> 
> On 11.05.2016 21:31, Matthew Johnson wrote:
>> 
>> 
>> Sent from my iPad
>> 
>>> On May 11, 2016, at 11:43 AM, Vladimir.S  wrote:
>>> 
>>> Well, I believe I understand now what *you mean* under #Self. OK.
>>> Thank you for clarifications. In my terminology 'this' could be called
>>> BaseSelf. Your "thing" just can not be called #Self. IMO in initial
>>> proposal #Self means not more than placeholder for the concrete type
>>> name(inside type declaration or inside protocol).
>>> 
>>> You propose just something different, more advanced than initial
>>> #Self, you propose not some static "thing" but extended behavior if
>>> #Self is a return type of protocol requirement.
>>> 
>>> I strictly against to couple the initial proposal of #Self and your
>>> proposal for extended features (for protocol conformance of
>>> `->#Self`). Please be clear and obvious regarding the name of that
>>> feature. I really think the behavior you propose can not be called
>>> #Self(or Type)
>>> 
>>> What I suggest: de-couple these proposals to:
>>> 
>>> a) initial proposal of #Self as placeholder for concrete type name.
>>> Choose the name for it. Probably StaticSelf, or Type, or somehting
>>> else
>>> 
>>> b) your proposal for BaseSelf feature. I'll definitely support it with
>>> just name changed to clearly reflect its propose.
>> 
>> I don't believe the initial proposal stated how it would behave in a
>> protocol.  However I do believe the feature I am talking about covers
>> all of the use cases Erica had in mind while also providing useful
>> semantics when used in a protocol requirement.  Erica, please correct me
>> if I'm wrong.
> 
> Well.. Yes, I also don't see statements regarding how `->#Self` would behave 
> in a protocol in initial proposal. *This is why* I suggest to de-couple what 
> *was* in initial proposall, and what you are suggesting as *addition* to the 
> proposal.
> 
> Again. I fully support the behavior you suggest, but I strongly feel like 
> 'that' #Self can't be named #Self, as some derived(from conformed class) 
> class X does not return 'self'. It return 'self or one of base classes'. 
> Let's call it 'SelfOrBase' for now.
> 
> What we have now:
> 
> protocol A {
>  func f1() -> Self
>  func f2(s: Self)
> }
> 
> struct S: A {
>  func f1() -> S/*#Self*/ {return self}
>  func f2(s: S/*#Self*/) {}
> }
> 
> class C: A {
>  func f1() -> Self /*only Self, can't write C here*/ {return self}
>  func f2(s: C/*#Self*/) {}
> }
> 
> final class FC: A {
>  func f1() -> Self /*can write FC here, ==#Self*/ {return self}
>  func f2(s: FC/*#Self*/) {}
> }
> 
> I believe, for clarity, after we introduce #Self(or whatever name it will 
> have) we need to require `#Self` in protocol as type of method parameter:
> 
> protocol A {
>  func f1() -> Self // this could be Self and could be #Self

What in the original proposal makes you think Self and #Self would be 
interchangeable here?  Again, the proposal was for #Self to be invariant.  Self 
is covariant.  Those are very different things.  

The semantics in the original proposal were unspecified with regards to 
protocols.  I am simply extending it to retain the invariant semantics that the 
proposal *did* specified when it is used as a protocol requirement.

>  func f2(s: #Self) // this always will be #Self in implementation
> 
>  // this should not be allowed any more
>  //func f2(s: Self)
> }
> 
> struct S: A {
>  // as you see we'd have `->#Self` in implementation
>  func f1() -> #Self {return self}
>  func f2(s: #Self) {}
> }
> 
> class C: A {
>  func f1() -> Self /*only Self, can't write C here*/ {return self}
>  func f2(s: #Self) {}
> }
> 
> final class FC: A {
>  func f1() -> Self /*can write FC here, ==#Self*/ {return self}
>  func f2(s: #Self) {}
> }
> 
> The above is what *I think* was in initial proposal regarding #Self.
> 
> About your suggestion. I just trying to understand it in details.
> Please point me where I understand your suggestion incorrectly.
> 
> Do you think about such start points? :
> 
> class Base {
>  func f() -> Base  {return Base()}
> }
> 
> class Derived1: Base {
>  override func f() -> Derived1  {return Derived1()}
> }
> 
> class Derived2: Base {
>  override func f() -> Derived2  {return Derived2()}
> }
> 
> If so, do you want to introduce such a protocol:
> 
> protocol A {
>func f() -> #Self
> }
> 
> and then conforms Base class to it? :
> 
> extension Base : A {}
> 
> To be able to use :
> 
> let a : A = Derived2()
> let some = a.f() // you expect some.dynamicType is Derived2

The protocol specifies #Self (or Type, which we are not calling it).  It is 
conformed to by Base.  This means the return type of `f` is only guaranteed to 
be Base.  It *may* be Derived2, but it need not be.  Obviously given this 
example we know it is Derived2 because we can see the implementation but the 
type system does not.  This means `some` has type 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0081: Move where clause to end of declaration

[Ray Fix via swift-evolution]

> The review of "SE-0081: Move where clause to end of declaration" begins now 
> and runs through May 16. The proposal is available here:
> 
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0081-move-where-expression.md
> 
>   * What is your evaluation of the proposal?

+1

>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?

Yes. Although this is (IIUC) syntax sweetener so needs to be prioritized with 
other changes.

>   * Does this proposal fit well with the feel and direction of Swift?

Yes. The given example does look more readable and I can’t think of a situation 
where it becomes less readable.  Generics are difficult so anything that makes 
them easier to approach is welcome.  The fact that there is now greater 
consistency with extension declarations is also +1.

There was an objection raised that it would close the door on a future features 
or types of constraint. It is difficult for me to evaluate that, but the 
consensus seemed to be it could be handled with additional syntax and possible 
keywords.  The consistency and readability for these more common cases should 
be prioritized IMO.

>   * If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?

No

>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

This morning.  Read proposal, pitch and current review thread.  [Tried to parse 
the proposed grammar changes, but didn’t spend a lot of time with it.] Thanks 
to the authors and contributors for thinking about this stuff and pushing it 
forward.



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

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

[Andrew Brown via swift-evolution]

> On First, this is a huge breaking change, and it doesn’t really have to be 
> one. The current SPM convention is to prefix C libraries with Lib. Following 
> this convention, Dispatch (which is the C version) would be renamed to 
> LibDispatch, and this new wrapper library would be called just Dispatch. With 
> this setup, the old C api would still be there (under the module 
> LibDispatch), which makes migration much easier. In the proposal, this issue 
> is not addressed at all and it even says that all code using libdispatch 
> would be affected. As it stands, that is not ok.

Separating existing dispatch from a new SwiftDispatch is a great idea.  It 
would give the opportunity to really spend time working on the right approach 
for concurrency in swift without affecting existing production code and the 
hundreds of dispatch wrappers out there.

While we're on the subject: Dispatch Queues are 'queues' ... Isn't the right 
verb append (for asynchronous dispatch)?

DispatchQueue.main.append {
  print("Hello Swift")
}

After all, asyncDispatch or dispatchAsync imply you are dispatching a 
synchronously - which you are not.  The dispatch (sending for execution) is 
always synchronous, it's the execution which is asynchronous.

DispatchQueue.main.dispatchForAsynchronousExecution {
  print("Help, I have repetitive strain injury")
}

Just my 2¢
Andrew.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [RFC] #Self

[Vladimir.S via swift-evolution]

Inline

On 11.05.2016 21:31, Matthew Johnson wrote:



Sent from my iPad


On May 11, 2016, at 11:43 AM, Vladimir.S  wrote:

Well, I believe I understand now what *you mean* under #Self. OK.
Thank you for clarifications. In my terminology 'this' could be called
BaseSelf. Your "thing" just can not be called #Self. IMO in initial
proposal #Self means not more than placeholder for the concrete type
name(inside type declaration or inside protocol).

You propose just something different, more advanced than initial
#Self, you propose not some static "thing" but extended behavior if
#Self is a return type of protocol requirement.

I strictly against to couple the initial proposal of #Self and your
proposal for extended features (for protocol conformance of
`->#Self`). Please be clear and obvious regarding the name of that
feature. I really think the behavior you propose can not be called
#Self(or Type)

What I suggest: de-couple these proposals to:

a) initial proposal of #Self as placeholder for concrete type name.
Choose the name for it. Probably StaticSelf, or Type, or somehting
else

b) your proposal for BaseSelf feature. I'll definitely support it with
just name changed to clearly reflect its propose.


I don't believe the initial proposal stated how it would behave in a
protocol.  However I do believe the feature I am talking about covers
all of the use cases Erica had in mind while also providing useful
semantics when used in a protocol requirement.  Erica, please correct me
if I'm wrong.


Well.. Yes, I also don't see statements regarding how `->#Self` would 
behave in a protocol in initial proposal. *This is why* I suggest to 
de-couple what *was* in initial proposall, and what you are suggesting as 
*addition* to the proposal.


Again. I fully support the behavior you suggest, but I strongly feel like 
'that' #Self can't be named #Self, as some derived(from conformed class) 
class X does not return 'self'. It return 'self or one of base classes'. 
Let's call it 'SelfOrBase' for now.


What we have now:

protocol A {
  func f1() -> Self
  func f2(s: Self)
}

struct S: A {
  func f1() -> S/*#Self*/ {return self}
  func f2(s: S/*#Self*/) {}
}

class C: A {
  func f1() -> Self /*only Self, can't write C here*/ {return self}
  func f2(s: C/*#Self*/) {}
}

final class FC: A {
  func f1() -> Self /*can write FC here, ==#Self*/ {return self}
  func f2(s: FC/*#Self*/) {}
}

I believe, for clarity, after we introduce #Self(or whatever name it will 
have) we need to require `#Self` in protocol as type of method parameter:


protocol A {
  func f1() -> Self // this could be Self and could be #Self
  func f2(s: #Self) // this always will be #Self in implementation

  // this should not be allowed any more
  //func f2(s: Self)
}

struct S: A {
  // as you see we'd have `->#Self` in implementation
  func f1() -> #Self {return self}
  func f2(s: #Self) {}
}

class C: A {
  func f1() -> Self /*only Self, can't write C here*/ {return self}
  func f2(s: #Self) {}
}

final class FC: A {
  func f1() -> Self /*can write FC here, ==#Self*/ {return self}
  func f2(s: #Self) {}
}

The above is what *I think* was in initial proposal regarding #Self.

About your suggestion. I just trying to understand it in details.
Please point me where I understand your suggestion incorrectly.

Do you think about such start points? :

class Base {
  func f() -> Base  {return Base()}
}

class Derived1: Base {
  override func f() -> Derived1  {return Derived1()}
}

class Derived2: Base {
  override func f() -> Derived2  {return Derived2()}
}

If so, do you want to introduce such a protocol:

protocol A {
func f() -> #Self
}

and then conforms Base class to it? :

extension Base : A {}

To be able to use :

let a : A = Derived2()
let some = a.f() // you expect some.dynamicType is Derived2

I understand correctly?

At this point you say that all is OK and #Self works as expected, each 
class returns really #Self and protocol conformation applied.

But I believe this is not true. We *can* have this:

class Derived3: Base {
  // no override for f(). will be used from base class
}

Now. What does Derived3().f() returns? It returns instance of Base.
Is #Self for Derived3 equals to `Base` ? No.
Does Derived3 conforms to protocol `A` in this case? No.
But it *must* conform as you think you can conform its base class.
This is the problem I see.

This is why I think it must be something separate from #Self, like 
SelfOrBase - in this case, protocol will looks like:


protocol A {
func f() -> SelfOrBase
}

then you can conform Base to A,

extension Base : A {}

and Derived3 fully conforms to this protocol(it returns instance of base 
class), all is OK and all is consistent.


If I'm wrong somewhere please point me with clarification. Thank you.



You want to make the semantics of #Self / Type be covariant when used in
a protocol requirement.  This makes no sense to me as it is explicitly
*not* covariant when used within a class 

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

[Tony Allevato via swift-evolution]

I'm +1 on this. It seems like it would solve the issue of Objective-C APIs
losing their protocol conformances on properties/arguments/return values
when they're added to a class, like UIView. That always
seemed like a major hole in the cross-language support and when writing
ObjC libraries I've had to explicitly use id instead of a stronger
class-based type simply to ensure Swift interoperability.

The other option of course is to import those things as generic functions
with constraints, but (1) that doesn't solve it for properties, and (2) if
we already support composing protocols in this way, why not also allow it
for other types, where it can be used for properties and variables? This
approach feels like it would round out the type system nicely.


On Thu, May 12, 2016 at 7:09 AM Adrian Zubarev via swift-evolution <
swift-evolution@swift.org> wrote:

> protocol
> protocol
>
> This feels really odd to me.
>
> `type` is more clear I’d say.
>
> I think this would be a good addition to the type system and allow us to
> build more complex and type save code.
>
> But still I’d love to discuss if there might be any disadvantages to this
> feature.
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 12. Mai 2016 bei 15:11:00, Vladimir.S (sva...@gmail.com) schrieb:
>
> protocol<>
>
> ___
> 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] Optional assignment operator

[Trent Nadeau via swift-evolution]

This same operator (except spelled as ??=) was up as a proposal and
rejected in February. See
http://thread.gmane.org/gmane.comp.lang.swift.evolution/7694.

On Thu, May 12, 2016 at 10:41 AM, Rod Brown via swift-evolution <
swift-evolution@swift.org> wrote:

> I’m tentatively supportive of this proposal. I definitely see the use case
> (assign only if not not nil).  Interested to hear the opinions of others
> here :)
>
> -Rod
>
>
> > On 12 May 2016, at 11:59 PM, Jose Manuel Sánchez Peñarroja via
> swift-evolution  wrote:
> >
> > Sorry if this has already been discussed, if so I couldn’t find it.
> >
> > I would like to propose to add to Swift an optional assignment operator
> ?=
> > I think this would nicely align with the other uses of ?, and avoid
> repetition in this case:
> >
> >   var value = 5
> >
> >   var possibleNewValue: Int? = nil
> >
> >   value = possibleNewValue ?? value
> >
> > It would be used like this:
> >
> >   value ?= possibleNewValue
> >
> > I’ve found quite a few cases in which this would be very useful to me.
> It is already possible to implement it, but having it defined in the
> standard library would define an standard, and prevent different semantics
> depending on who implements it.
> >
> >
> >   infix operator ?= {
> > associativity right
> >  precedence 90
> >  assignment
> >   }
> >
> >   func ?= (inout lhs: T, rhs: T?) {
> >   lhs = rhs ?? lhs
> >   }
> >
> >
> > Regards,
> > José Manuel Sanchez
> > ___
> > 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
>



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

Re: [swift-evolution] Optional assignment operator

[Rod Brown via swift-evolution]

I’m tentatively supportive of this proposal. I definitely see the use case 
(assign only if not not nil).  Interested to hear the opinions of others here :)

-Rod


> On 12 May 2016, at 11:59 PM, Jose Manuel Sánchez Peñarroja via 
> swift-evolution  wrote:
> 
> Sorry if this has already been discussed, if so I couldn’t find it.
> 
> I would like to propose to add to Swift an optional assignment operator ?=
> I think this would nicely align with the other uses of ?, and avoid 
> repetition in this case:
> 
>   var value = 5
> 
>   var possibleNewValue: Int? = nil
> 
>   value = possibleNewValue ?? value
> 
> It would be used like this:
> 
>   value ?= possibleNewValue
> 
> I’ve found quite a few cases in which this would be very useful to me. It is 
> already possible to implement it, but having it defined in the standard 
> library would define an standard, and prevent different semantics depending 
> on who implements it.
> 
> 
>   infix operator ?= {
> associativity right
>  precedence 90
>  assignment
>   }
> 
>   func ?= (inout lhs: T, rhs: T?) {
>   lhs = rhs ?? lhs
>   }
> 
> 
> Regards,
> José Manuel Sanchez
> ___
> 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] merge types and protocols back together with type<Type, Protocol, ...>

[Adrian Zubarev via swift-evolution]

protocol 
protocol 

This feels really odd to me. 

`type` is more clear I’d say.

I think this would be a good addition to the type system and allow us to build 
more complex and type save code.

But still I’d love to discuss if there might be any disadvantages to this 
feature.

-- 
Adrian Zubarev
Sent with Airmail

Am 12. Mai 2016 bei 15:11:00, Vladimir.S (sva...@gmail.com) schrieb:

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0084: Allow trailing commas in parameter lists and tuples

[Rainer Brockerhoff via swift-evolution]

On 5/12/16 10:52, Vladimir.S via swift-evolution wrote:
> On 12.05.2016 16:22, Rainer Brockerhoff via swift-evolution wrote:
>> I'm +1 on allowing either trailing commas *or* a line-break instead of
>> where a comma is expected.
>>
>> Just as we allow a line-break where a semicolon is expected in a list of
>> statements.
> 
> Well.. Although I'm still -1 on allowing trailing comma anywhere other
> than array/dict initialization, and think we need just line-breaks as
> separator, I feel(am I wrong?) like core team wants to accept the
> initial proposal(at least replies from @apple.com are supporting the
> initial proposal).
> 
> So, I believe this proposal(SE-0084) should be changed to something like:
> "Allow trailing commas *everywhere* in comma-separated lists(parameters,
> tuples, generic type list, func/method call,etc) *and* allow line-break
> to be treated as a separator in comma-separated lists"
> 
> I believe such changed proposal, if will be accepted, will suite the
> needs of most developers - trailing comma + line-breaks.

Agreed. Everyone can use whatever feels best. Teams will mandate some
specific style, anyway.


> But again.. will you use comma as separator in multi-line list if you
> can just don't type it and 'use' line-break? Do you use semicolons in
> code now? ;-)

I use commas with items on the same line, and semicolons with statements
on the same line. ;-)

Now, the choice of when to put items or statements on the same line
varies...

-- 
Rainer Brockerhoff  
Belo Horizonte, Brazil
"In the affairs of others even fools are wise
In their own business even sages err."
http://brockerhoff.net/blog/

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

[swift-evolution] [Pitch] Nesting types without nesting in place (additional)

[Adrian Zubarev via swift-evolution]

As you may know we can nest types for shiny namespacing (protocol nesting might 
follow in Swift 3 as well).

What if we could create Types separated by a `.` character to determine that 
this is a nested type to stop building type pyramides, which could be/look ugly 
in some cases.

Imagine SomeClass and NestedClass are some huge and complex types. It might 
become hard to read if we had to build them in place just for good namespacing.

class SomeClass {

   class NestedClass {
      enum Error {}
   }
   enum Error {}
}

Split this to something like this:

class SomeClass {}

enum SomeClass.Error {}

class SomeClass.NestedClass {
    enum Error {} // nesting is still allowed
}

Extensions already allow that.

extension SomeClass.NestedType {}

What do you think? Is it something for Swift 3?

-- 
Adrian Zubarev
Sent with Airmail___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ben Rimmington via swift-evolution]

## Type Names

I was going to suggest unprefixed type names, but having to qualify both
`Dispatch.Data` and `Foundation.Data` would be an issue. If libdispatch
had originally been part of Foundation, you'd need prefixes anyway:

* DispatchQueue
* NotificationQueue
* OperationQueue

## Quality of Service

Should argument labels and type names match those in Foundation?

* qos:=> qualityOfService:
* DispatchQoS => DispatchQualityOfService

Could there be a shared `Swift.QualityOfService` enum?

* QOS_CLASS_DEFAULT = 0x15
* NSQualityOfServiceDefault = -1

The `.unspecified` QoS is not defined in NSQualityOfService.
Would an optional QoS parameter (defaulting to nil) be better?

## Time

The `dispatch_time` function uses a nanoseconds delta, so the operator
overloads taking `seconds: Double` might be ambiguous at the call site.
You could try changing the associated value types of your enum.

```
enum DispatchTimeInterval {
case  seconds(Double) // changed from `Int`
case milliseconds(Int64)  // changed from `Int`
case microseconds(Int64)  // changed from `Int`
case  nanoseconds(Int64)  // changed from `Int`
}

let _ = DispatchTime.now + 3.5 // ambiguous?
let a = DispatchTime.now +  .seconds(3.5)
let b = DispatchTime.now + .milliseconds(3_500)
let c = DispatchTime.now + .microseconds(3_500_000)
let d = DispatchTime.now +  .nanoseconds(3_500_000_000)
```

Is the `DispatchTime.now` in your example a type property?

## Data

Should the `DispatchData.append` methods have `contentsOf:` labels?
Or could it conform to the RangeReplaceableCollection protocol?

## Queues

My suggestions for the async/sync methods:

* enqueue(...)
* enqueueAndWaitUntilFinished(...)

-- Ben


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

[swift-evolution] Optional assignment operator

[Jose Manuel Sánchez Peñarroja via swift-evolution]

Sorry if this has already been discussed, if so I couldn’t find it.

I would like to propose to add to Swift an optional assignment operator ?=
I think this would nicely align with the other uses of ?, and avoid repetition 
in this case:

var value = 5

var possibleNewValue: Int? = nil

value = possibleNewValue ?? value

It would be used like this:

value ?= possibleNewValue

I’ve found quite a few cases in which this would be very useful to me. It is 
already possible to implement it, but having it defined in the standard library 
would define an standard, and prevent different semantics depending on who 
implements it.


infix operator ?= {
  associativity right
   precedence 90
   assignment
}

func ?= (inout lhs: T, rhs: T?) {
lhs = rhs ?? lhs
}


Regards,
José Manuel Sanchez
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0084: Allow trailing commas in parameter lists and tuples

[Vladimir.S via swift-evolution]

On 12.05.2016 16:22, Rainer Brockerhoff via swift-evolution wrote:

I'm +1 on allowing either trailing commas *or* a line-break instead of
where a comma is expected.

Just as we allow a line-break where a semicolon is expected in a list of
statements.


Well.. Although I'm still -1 on allowing trailing comma anywhere other than 
array/dict initialization, and think we need just line-breaks as separator, 
I feel(am I wrong?) like core team wants to accept the initial proposal(at 
least replies from @apple.com are supporting the initial proposal).


So, I believe this proposal(SE-0084) should be changed to something like:
"Allow trailing commas *everywhere* in comma-separated lists(parameters, 
tuples, generic type list, func/method call,etc) *and* allow line-break to 
be treated as a separator in comma-separated lists"


I believe such changed proposal, if will be accepted, will suite the needs 
of most developers - trailing comma + line-breaks.


But again.. will you use comma as separator in multi-line list if you can 
just don't type it and 'use' line-break? Do you use semicolons in code now? ;-)




-1 on making trailing commas mandatory, just as I'm against making
semicolons mandatory again :-)


OK. Probably I was wrong regarding my suggestion to make them mandatory.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0084: Allow trailing commas in parameter lists and tuples

[Rainer Brockerhoff via swift-evolution]

On 5/11/16 14:29, Ricardo Parada via swift-evolution wrote:
> Dropping the commas looks good and doesn't look like someone made a mistake. 
> I don't know what other implications / complications dropping the commas 
> would have but I like it. 
> 
>> On May 11, 2016, at 12:20 PM, Vladimir.S via swift-evolution 
>>  wrote:
>>
>> Personally I support the idea of dropping comma in array/dict to allow line 
>> break separate elements(like operations in Swift code):
>> let a = [
>>10
>>20
>>30
>>40
>>]
>>
>> let d = [
>>10 : "a"
>>20 : "b"
>>30 : "c"
>>40 : "d"
>>]

I'm +1 on allowing either trailing commas *or* a line-break instead of
where a comma is expected.

Just as we allow a line-break where a semicolon is expected in a list of
statements.

-1 on making trailing commas mandatory, just as I'm against making
semicolons mandatory again :-)


-- 
Rainer Brockerhoff  
Belo Horizonte, Brazil
"In the affairs of others even fools are wise
In their own business even sages err."
http://brockerhoff.net/blog/

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

Re: [swift-evolution] [Pitch] merge types and protocols back together with type<Type, Protocol, ...>

[Vladimir.S via swift-evolution]

I feel like this could be a useful feature. We can right now couple protocols

protocol A { func a() }
protocol B { func b() }

func z(o: protocol) {
o.a()
o.b()
}

let o = some as! protocol
o.a()
o.b()

But how to be if we need to specify some class/struct in addition to protocol?
So, if this feature could be implemented, I'm +1 on this `type<>` feature
Or probably we can allow class in protocol<>

On 11.05.2016 21:06, Adrian Zubarev via swift-evolution wrote:

Sorry for pushing this back, but I really would like to read any feedback
for this idea of mine. ;)

--
Adrian Zubarev
Sent with Airmail

Am 4. Mai 2016 bei 22:38:33, Adrian Zubarev
(adrian.zuba...@devandartist.com )
schrieb:


This one have bothered me for days, since the idea came to my mind.

I don't want to be too futuristic so here are my first thoughts.

What if Swift 3 would have the ability to merge types and protocols together?

Sure we will see generic typealias in Swift 3 but it doesn't allow us
merge value types which conforms to specific protocols (if there is a need).

protocol SomeProtocol {
func boo()
}

// this use-case can be solved with generic typealias in Swift 3 (at
least for classes), but it is not the only one usecase of type merging
func foo(mergedInstance: type) {
mergedInstance.removeFromSuperview() // just for the example
mergedInstance.boo()
}

extension UIButton: SomeProtocol { /* implemnt boo() */ }

let button: SomeProtocol = UIButton() // decouple UIButton first

Ok now I want to use one instance as SomeProtocol and UIView.

// another possible use-case
if let mergedView = button as? type {
mergedView.removeFromSuperview() // just for the example
mergedView.boo()
}

More detailed design:

- type<> can contain only one value or reference type and n protocols
- value or reference type should always be the first type
- type<> should always contain at least 2 types (one value or reference
type and min. one protocol)
- reference types does represent one possible super/base type of the
actuall type
 * class A {}
 * class B: A {}
 * class C: B {}
 * possible types for B and C: type or
type
- the dynamicType/Self instance passed to type<> conforms to all
protocols type<> contains

If there is more rules one would apply to this idea feel free to discuss
them here.

--
Adrian Zubarev
Sent with Airmail



___
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-0084: Allow trailing commas in parameter lists and tuples

[Ricardo Parada via swift-evolution]

I agree. 


> On May 12, 2016, at 3:36 AM, Vladimir.S via swift-evolution 
>  wrote:
> 
> Fully support your opinion.
> 
> > PS: can they actually be removed EVERYWHERE instead?!
> 
> Yes, I believe it will be much better to propose feature to allow line break 
> instead of comma, so we can have:
> 
> let x = [10
>20
>30]
> 
> let y = [1 : "one"
>2 : "two"]
> 
> (from proposal):
> 
> func padStringToLength(
>sourceString: String
>destinationCount: Int
>paddingStyle: StringPaddingStyle = .Left
>paddingCharacter: Character = " "
> ) -> String {
>/* ... */
> }
> 
> padStringToLength(
>sourceString: "source"
>destinationCount: 4
>paddingStyle: .Right
>paddingCharacter: ""
> )
> 
> let tuple: (
>string: String
>number: Int
> ) = (
>   string: "string"
>   number: 0
> )
> 
> ...SomeU
>SomeV> ...
> 
> This solves all the problems with diffs, makes code much clean and nice, no 
> additional noise. Why we need these commas instead of this solution? IMO this 
> will be real step forward.
> 
> Is there such a proposal? (Or probably was discussed already?)
> 
>> On 12.05.2016 7:46, L Mihalkovic via swift-evolution wrote:
>> 
>> -1 - for ever
>> 
>> 
>>> On May 11, 2016, at 6:47 PM, Joe Groff via swift-evolution
>>> > wrote:
>>> 
>>> 
 On May 10, 2016, at 11:53 AM, Chris Lattner via swift-evolution
 > wrote:
 
 Hello Swift community,
 
 The review of "SE-0084: Allow trailing commas in parameter lists and
 tuples" begins now and runs through May 16. The proposal is available here:
 
 https://github.com/apple/swift-evolution/blob/master/proposals/0084-trailing-commas.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
>>> 
>>> +1 from me. We should be consistent in either accepting or rejecting
>>> trailing commas everywhere we have comma-delimited syntax. I'm in favor
>>> of accepting it, since it's popular in languages where it's supported to
>>> enable a minimal-diff style, so that changes to code don't impact
>>> neighboring lines for purely syntactic reasons. If you add an argument to
>>> a function, without trailing comma support, a comma has to be added to
>>> dirty the previous line:
>>> 
>>> --- a.swift
>>> +++ a.swift
>>> foo(
>>>   x: 0,
>>> -  y: 1
>>> +  y: 1,
>>> +  z: 2
>>> )
>>> 
>>> Trailing commas avoid this:
>>> 
>>> --- a.swift
>>> +++ a.swift
>>> foo(
>>>   x: 0,
>>>   y: 1,
>>> +  z: 2,
>>> )
>>> 
>>> 
>>> In languages that don't support trailing commas, many users resort to the
>>> abomination of leading-comma style, strangely popular in Haskell and
>>> related languages:
>> 
>> I am not sure I understand where the “abomination” lies in using
>> leading-comma style… but I will try to see it.
>> 
>>> --- a.swift
>>> +++ a.swift
>>> foo( x: 0
>>>, y: 1
>>> +   , z: 2
>>>)
>>> 
>>> I think the trailing-comma syntax jives much better with Swift style.
>> 
>> 
>> If commas are to be construed as elegantly but meaninglessly dropped little
>> crumbs, then one can see why it might not matter where they go, or how many
>> there are, which as well as begging the question of allowing them at the
>> end, should equally prompt the question of completely removing them
>> altogether. And if having extras is just /great anticipation on future
>> needs/, should we think about considering the following lines as all 
>> equivalent
>> 
>> let v0 = (1,
>>  2,
>>  3)
>> let v1 = (1,
>>  2,
>>  3,
>> )
>> let v2 = (,// just in case I want to add something at the front 
>> later?!
>>  1,
>> 

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

[Gwendal Roué via swift-evolution]

Hello,

Does the proposal fixes the errors introduced by the latest May 9 snapshot ?

Since IUO are abolished 
(https://github.com/apple/swift-evolution/blob/master/proposals/0054-abolish-iuo.md)
 and pointer nullability is expressed using Optional 
(https://github.com/apple/swift-evolution/blob/master/proposals/0055-optional-unsafe-pointers.md),
 I get many errors as soon as I use libdispatch:

let sem = dispatch_semaphore_create(0)
dispatch_semaphore_wait(sem, …) // Error: Value 
of optional type not unwrapped
dispatch_semaphore_signal(sem)  // 
Error: Value of optional type not unwrapped

let source = dispatch_source_create(…)
dispatch_source_set_event_handler(source) { … } // Error: Value of 
optional type not unwrapped
dispatch_source_set_cancel_handler(source) { … }// Error: Value 
of optional type not unwrapped
dispatch_resume(source) // 
Error: Value of optional type not unwrapped

Of course, it's easy to fix. Still, the fix is usually adding a bang (!), 
because most apps prefer crashing when dispatch_semaphore_create or 
dispatch_source_create fails. And if I don't mind using bangs when it's the 
best solution, I can't be happy to see bangs everywhere.

In short: libdispatch is currently in its worst state ever :-)

Cheers to all,
Gwendal Roué


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

[Jeremy Pereira via swift-evolution]

I think there is a typo on the initialiser from a hex tuple string. The 
external name of the first parameter should not be `base64EncodedString`. In 
fact, I’m not sure why base64String and hexTupleString aren’t OK for the 
external name of first parameter of those initialisers.



> On 12 May 2016, at 11:42, Austin Zheng via swift-evolution 
>  wrote:
> 
> Hello developers,
> 
> After considering everyone's feedback, I decided to completely rewrite my 
> trial balloon proposal 
> (https://github.com/austinzheng/swift-evolution/blob/d2/proposals/-stdlib-data.md).
> 
> In short, much of the API interface has been extracted into a `Data` 
> protocol; two concrete implementations (one exploiting Swift 3's conditional 
> protocol conformances) can be used for different purposes. The API should 
> properly model data objects using both contiguous and non-contiguous backing 
> stores.
> 
> Further thoughts, opinions, criticism, or just ideas as to what a great 
> `Data` type would be capable of doing are much appreciated. Thanks again!
> 
> Best,
> Austin
> 
> 
>> On May 11, 2016, at 11:29 AM, Austin Zheng  wrote:
>> 
>> Hi Dmitri,
>> 
>> Thanks for the feedback! I'm glad that we could start a conversation on the 
>> lists, and happy to see people offering their unvarnished opinions.
>> 
>> I think conditional conformances upon Array is definitely an avenue 
>> worth exploring. I'm not sure what the performance implications are - Zach 
>> brought up use cases in which the ability for a data type to be backed by 
>> non-contiguous storage was important. More generally, I wanted to open up 
>> discussion as to what people wanted from a native Data type.
>> 
>> It seems like a DataProtocol-like protocol may be a good idea. Array 
>> could conform through conditional conformances to provide an implementation 
>> for people wanting a simple contiguous buffer that could be punned to an 
>> array or other linear collection, while a more robust dispatch_data_t-like 
>> conforming Swift stdlib type could be provided for more demanding use cases. 
>> This actually seems to be a good fit - if you only care about a data buffer 
>> as an arbitrary collection of bytes, the abstract protocol interface gives 
>> you flexibility, while if you have requirements that require a specific 
>> representation of data in memory you should use a concrete type.
>> 
>> Best,
>> Austin
>> 
>> 
>> 
>> On Wed, May 11, 2016 at 11:01 AM, Dmitri Gribenko  
>> wrote:
>> On Wed, May 11, 2016 at 2:37 AM, Austin Zheng via swift-evolution
>>  wrote:
>> > Hello swift-evolution,
>> >
>> > I've been thinking about a standard library 'Data' type for a while,
>> > analogous to NSData in the same way Swift's Arrays and Dictionaries are
>> > analogous to NSArrays and NSDictionaries. A first-class container for 
>> > binary
>> > data that is available to every Swift user, conforms to Swift semantics, 
>> > and
>> > is safer and easier to work with than UnsafeBufferPointer seems like a
>> > natural fit for the standard library.
>> 
>> Hi Austin,
>> 
>> This is an interesting territory!
>> 
>> One thing that I would like to suggest for us to consider is
>> justifying why Data needs to be a separate type from Array and
>> Array.  We can add conditional extensions to Array of Int8 and
>> UInt8 if we find that existing NSData/dispatch_data_t usecases need a
>> few special APIs that won't make sense on arrays in general.
>> 
>> For example, something that I would imagine people want to do with
>> "data buffer" types is being able to make an unaligned or type punned
>> load or store.  For example, in Java, this is one of the primary
>> usecases for a type similar in spirit, java.nio.ByteBuffer
>> (https://docs.oracle.com/javase/7/docs/api/java/nio/ByteBuffer.html).
>> 
>> Another usecase that is a crossover between Array and Data, allow
>> Array to (unsafely) adopt ownership of an existing initialized unsafe
>> buffer pointer.  We had quite a few requests for this.  Do you think
>> this is an interesting usecase?  Does it overlap with this discussion?
>> 
>> Dmitri
>> 
>> --
>> main(i,j){for(i=2;;i++){for(j=2;j> (j){printf("%d\n",i);}}} /*Dmitri Gribenko */
>> 
> 
> ___
> 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] [Proposal] More lenient subscript methods over Collections

[Vladimir.S via swift-evolution]

If there is a method with such name in Range(with equal meaning) - then it 
seems like `clamping` will be the best solution here.
(as non-native speaker I don't feel this word is often used especially in 
software development, but.. it seems like anyone who is writing in Swift 
must be strong native English speaker/writer :-P I also mean all these 
naming conversions, verb/noun, -ing/-ed/-able etc ;-) )


On 12.05.2016 12:56, Luis Henrique B. Sousa wrote:

Yes, it would really be more consistent. "within" sounds great to me as
well, but I don't know if there is a naming convention for it.
I am okay to change our proposal to have those labels as two verbs -
instead of a preposition and a verb - as suggested by @Brent.

More opinions?

- Luis

On Thu, May 12, 2016 at 7:25 AM, Brent Royal-Gordon > wrote:

> It sounds good, thanks for you suggestions @Vladimir, @Patrick and @Brent.
>
> I've just updated the proposal:
> 
https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/-more-lenient-collections-subscripts.md#detailed-design
>
> - Luis

Hmm. If you're going with `checking` for one of them, perhaps the other
should be `clamping` (for the analogous method on `Range`, which you
might want to use in the implementation of that subscript). That would
create a nicely matched pair:

array[checking: 0..<10]
array[clamping: 0..<10]

--
Brent Royal-Gordon
Architechies



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

Re: [swift-evolution] Standard library 'Data' type pre-proposal

[Austin Zheng via swift-evolution]

Hello developers,

After considering everyone's feedback, I decided to completely rewrite my trial 
balloon proposal 
(https://github.com/austinzheng/swift-evolution/blob/d2/proposals/-stdlib-data.md
 
).

In short, much of the API interface has been extracted into a `Data` protocol; 
two concrete implementations (one exploiting Swift 3's conditional protocol 
conformances) can be used for different purposes. The API should properly model 
data objects using both contiguous and non-contiguous backing stores.

Further thoughts, opinions, criticism, or just ideas as to what a great `Data` 
type would be capable of doing are much appreciated. Thanks again!

Best,
Austin


> On May 11, 2016, at 11:29 AM, Austin Zheng  wrote:
> 
> Hi Dmitri,
> 
> Thanks for the feedback! I'm glad that we could start a conversation on the 
> lists, and happy to see people offering their unvarnished opinions.
> 
> I think conditional conformances upon Array is definitely an avenue 
> worth exploring. I'm not sure what the performance implications are - Zach 
> brought up use cases in which the ability for a data type to be backed by 
> non-contiguous storage was important. More generally, I wanted to open up 
> discussion as to what people wanted from a native Data type.
> 
> It seems like a DataProtocol-like protocol may be a good idea. Array 
> could conform through conditional conformances to provide an implementation 
> for people wanting a simple contiguous buffer that could be punned to an 
> array or other linear collection, while a more robust dispatch_data_t-like 
> conforming Swift stdlib type could be provided for more demanding use cases. 
> This actually seems to be a good fit - if you only care about a data buffer 
> as an arbitrary collection of bytes, the abstract protocol interface gives 
> you flexibility, while if you have requirements that require a specific 
> representation of data in memory you should use a concrete type.
> 
> Best,
> Austin
> 
> 
> 
> On Wed, May 11, 2016 at 11:01 AM, Dmitri Gribenko  > wrote:
> On Wed, May 11, 2016 at 2:37 AM, Austin Zheng via swift-evolution
> > wrote:
> > Hello swift-evolution,
> >
> > I've been thinking about a standard library 'Data' type for a while,
> > analogous to NSData in the same way Swift's Arrays and Dictionaries are
> > analogous to NSArrays and NSDictionaries. A first-class container for binary
> > data that is available to every Swift user, conforms to Swift semantics, and
> > is safer and easier to work with than UnsafeBufferPointer seems like a
> > natural fit for the standard library.
> 
> Hi Austin,
> 
> This is an interesting territory!
> 
> One thing that I would like to suggest for us to consider is
> justifying why Data needs to be a separate type from Array and
> Array.  We can add conditional extensions to Array of Int8 and
> UInt8 if we find that existing NSData/dispatch_data_t usecases need a
> few special APIs that won't make sense on arrays in general.
> 
> For example, something that I would imagine people want to do with
> "data buffer" types is being able to make an unaligned or type punned
> load or store.  For example, in Java, this is one of the primary
> usecases for a type similar in spirit, java.nio.ByteBuffer
> (https://docs.oracle.com/javase/7/docs/api/java/nio/ByteBuffer.html 
> ).
> 
> Another usecase that is a crossover between Array and Data, allow
> Array to (unsafely) adopt ownership of an existing initialized unsafe
> buffer pointer.  We had quite a few requests for this.  Do you think
> this is an interesting usecase?  Does it overlap with this discussion?
> 
> Dmitri
> 
> --
> main(i,j){for(i=2;;i++){for(j=2;j (j){printf("%d\n",i);}}} /*Dmitri Gribenko  >*/
> 

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

Re: [swift-evolution] [proposal] extra if syntax

[Krzysztof Siejkowski via swift-evolution]

And what is with ‘a’ if this situation:

if b == x {
a = 5
}

Nothing :)
Well, it’s not nothing, it has the same value that it had before.

However, as pointed by Leonardo Pessoa, there is a problem with expression:

let a = 5 if b == x

It is equivalent to:

if b == x {

    let a = 5 

} 

but doesn’t communicate clearly that in the next line `a` is already out of 
scope and that you cannot write:

let a = 5 if b == x

let c = a // a is not defined here

but you can write:

let a = 1 if b == x 

let a = 2 if b == x // other a from other scope

let a = 3 if b == x // another a from another scope

without error concerning immutability.

Austin Zheng has also rightly pointed that this “postfix” syntax looks as if 
the if-statement is now an expression, which will further confuse people coming 
from languages that use if-expressions.

Also, I find:

{

    // … a lot of code 

} if b == x

way less readable, simply because I read top to bottom. This syntax makes me 
search for the scope delimiter, understand the condition and only after lets me 
read the logic.



All the best,

Krzysztof



___
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-0084: Allow trailing commas in parameter lists and tuples

[Vladimir.S via swift-evolution]

Inline

On 11.05.2016 22:58, Joe Groff wrote:



On May 11, 2016, at 10:14 AM, Vladimir.S  wrote:

In this case (if this is a such good feature) IMO we should think
about making the trailing commas *required*. In this way we will be
consistent in either do we have trailing commas in Swift or don't.
Otherwise we'll have a zoo in our sources/projects.

I don't think we need to have the same rules for commas "everywhere we
have comma-delimited syntax".


We've generally shied away from legislating style; see our rationale
behind not requiring `self.` for an example:

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160104/005478.html


Got it. I expect you(the core team) will not be against new line as item 
separator in list(in addition to comma) just for the same reason. Also just 
for the same reason IMO you should not be against type inference for 
default parameters in funcs. etc
I find this rationale very 'wide' so we can end up with JavaScript(in worst 
meaning) instead of Swift at the end.




 In languages where trailing commas are pervasively allowed, such as
Perl, Python, Ruby, and modern Javascript, I haven't seen any indication
that this is a major problem. Less blood has definitely been shed over
it than over bracing style and other style wars.



For me this does not rationale why we need to introduce this 'feature' in 
Swift. There is a lot of 'cool'(or ugly, from someone's point of view) 
'features' in these languages.
And we *have* trailing comma for arrays/dicts - IMO this is a golden middle 
between both words.



-Joe.


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

Re: [swift-evolution] [Rejected] SE-0073: Marking closures as executing exactly once

[Gwendal Roué via swift-evolution]

Many thanks to the review team for their interest in the proposal!

Gwendal Roué

> Le 12 mai 2016 à 00:44, Chris Lattner via swift-evolution 
>  a écrit :
> 
> Proposal link: 
> https://github.com/apple/swift-evolution/blob/master/proposals/0073-noescape-once.md
> 
> Hello Swift Community,
> 
> The review of SE-0073: "Marking closures as executing exactly once" ran from 
> May 3…9, 2016. The proposal is *rejected* for Swift 3.  
> 
> The feedback on the proposal was generally positive both from the community 
> and core team.  That said, it is being rejected for Swift 3 two reasons:
> 
> 1) The surface level syntax of @noescape needs to be reconsidered.  At the 
> minimum, we need to rename @noescape to @nonescaping for consistency with our 
> previously agreed attribute naming scheme.  However, it is also work 
> discussing whether @nonescaping should be the default: if so, the attribute 
> should actually become @escaping, and the functionality proposed in SE-0073 
> would be named @once.
> 
> 2) Separate from the surface level issues, the implementation underlying this 
> work has some significant challenges that are doable but would require major 
> engineering work.  Specifically, the definite initialization pass needs to 
> “codegen” booleans in some cases for conditional initialization/overwrite 
> cases, and these state values would have to be added to closure capture 
> lists.  This would require enough engineering work that it seems unlikely 
> that it would happen in the Swift 3 timeframe, and beyond that this could 
> theoretically be subsumed into a more general system that allowed 
> control-flow-like functions to have closures that break/continue/throw/return 
> out of their enclosing function, or a general macro system.
> 
> Overall, everyone desires the ability to produce more control-flow like 
> functions, but Swift 3 isn’t in a place where it can make sense to tackle 
> this work.
> 
> Many thanks to Félix Cloutier and Gwendal Roué for driving this discussion 
> and writing a great proposal.  I hope that this topic comes back up for 
> discussion in a future release.
> 
> -Chris Lattner
> Review Manager
> 
> 
> ___
> 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-0081: Move where clause to end of declaration

[Krzysztof Siejkowski via swift-evolution]

* What is your evaluation of the proposal?
+1

More readable.

* Is the problem being addressed significant enough to warrant a change to 
Swift?
Yes. Current form of defining requirements makes deciphering the signatures 
with high number of requirements a logical riddle.



* Does this proposal fit well with the feel and direction of Swift?
I do think so. It’ll further encourage the use of generics, which I see as one 
of the cornerstones of Swift.



* If you have used other languages or libraries with a similar feature, how do 
you feel that this proposal compares to those?
Not that I can think of, but now I’d like to see similar change in Scala :)



* How much effort did you put into your review? A glance, a quick reading, or 
an in-depth study?
I’ve read proposal and corresponding discussion.



All the best,

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

Re: [swift-evolution] [Proposal] More lenient subscript methods over Collections

[Luis Henrique B. Sousa via swift-evolution]

Yes, it would really be more consistent. "within" sounds great to me as
well, but I don't know if there is a naming convention for it.
I am okay to change our proposal to have those labels as two verbs -
instead of a preposition and a verb - as suggested by @Brent.

More opinions?

- Luis

On Thu, May 12, 2016 at 7:25 AM, Brent Royal-Gordon 
wrote:

> > It sounds good, thanks for you suggestions @Vladimir, @Patrick and
> @Brent.
> >
> > I've just updated the proposal:
> >
> https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/-more-lenient-collections-subscripts.md#detailed-design
> >
> > - Luis
>
> Hmm. If you're going with `checking` for one of them, perhaps the other
> should be `clamping` (for the analogous method on `Range`, which you might
> want to use in the implementation of that subscript). That would create a
> nicely matched pair:
>
> array[checking: 0..<10]
> array[clamping: 0..<10]
>
> --
> Brent Royal-Gordon
> Architechies
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0084: Allow trailing commas in parameter lists and tuples

[Krzysztof Siejkowski via swift-evolution]

* What is your evaluation of the proposal?
-1

While I appreciate the ease of reordering and commenting out that the proposal 
brings, I think it hurts readability. Also, it seems to me that keeping the 
commas in check is a job of a IDE, not language syntax feature. 

The analogy for me is the Lisp parentheses problem. It’s often even more 
difficult to manage parens while editing and commenting code. Instead of 
providing a language syntax feature that makes the number of trailing parents 
flexible, it was better solved with IDE feature called Parinfer.



* Is the problem being addressed significant enough to warrant a change to 
Swift?
I do not think so. It’s a minor issue with minor consequences.



* Does this proposal fit well with the feel and direction of Swift?
The only part of Swift “feel and direction” that I think can be of relevance is 
its focus on educational cases. I do not have any data concerning whether 
trailing commas will be easier or harder to grasp by the students. However, 
it’s one more think to explain.



* If you have used other languages or libraries with a similar feature, how do 
you feel that this proposal compares to those?
I’ve used a little Python and JavaScript. I didn’t use this feature in those 
languages, but it was just me. I think it fits better with their scripting 
style, where by “scripting” I mean very forgiving, very flexible (multiple ways 
to achieve the same effect) and hardly ever preventing you from making 
mistakes. I think Swift was always trying to drive away from this attitude and 
replace it with “scripting syntax for safe language” one.



* How much effort did you put into your review? A glance, a quick reading, or 
an in-depth study?
I’ve read the proposal and related discussion.



All the best,

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

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

[Dan Appel via swift-evolution]

> 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
>
>
>

Ok, I have mixed feeling about this proposal.

First, this is a huge breaking change, and it doesn’t really have to be
one. The current SPM convention is to prefix C libraries with Lib.
Following this convention, Dispatch (the C version) would be renamed to
LibDispatch, and this new wrapper library would be called just Dispatch.
With this setup, the old C api would still be there (under the module
LibDispatch), which makes migration much easier. In the proposal, this
issue is not addressed at all and it even says that all code using
libdispatch would have to be rewritten. That is not ok.

Another issues is the proposal to 'automagically' translate the C api into
Swift. There are many libraries right now that wrap the current libdispatch
functions and provide a similar api, and I don’t think there’s any reason
why this shouldn’t be done the same way. I would also argue that doing this
links the Swift language to libdispatch in a way that isn’t necessary. For
example, there is a library called Venice
 which provides CSP (go-style
concurrency) for Swift by wrapping a fork of the C library libmill, and it
doesn’t do any of the proposed magic importing of any sort. I don’t see a
reason why libdispatch shouldn’t take the same approach.

Overall, I think the idea is good but some of the details are really
lacking. As it stands, I would vote to reject this proposal and request
revision, or reject it outright and suggest to use third-party wrappers
around libdispatch (which is what the community is currently doing).

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

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

[Dan Appel via swift-evolution]

> 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
> 
> 
> 


Ok, I have mixed feeling about this proposal.

First, this is a huge breaking change, and it doesn’t really have to be one. 
The current SPM convention is to prefix C libraries with Lib. Following this 
convention, Dispatch (which is the C version) would be renamed to LibDispatch, 
and this new wrapper library would be called just Dispatch. With this setup, 
the old C api would still be there (under the module LibDispatch), which makes 
migration much easier. In the proposal, this issue is not addressed at all and 
it even says that all code using libdispatch would be affected. As it stands, 
that is not ok.

On a different issue in this proposal: I think that translating the C api into 
Swift ‘automagically’ is the wrong approach. There are many libraries right now 
that wrap the current libdispatch functions and provide a similar api, and I 
don’t think there’s any reason why this shouldn’t be done the same way. I would 
also argue that doing this links the Swift language to libdispatch in a way 
that isn’t necessary. For example, there is a library called Venice 
 which provides CSP (go-style concurrency) 
for Swift by wrapping a fork of the C library libmill, and it doesn’t do any 
magic importing of any sort. I don’t see a reason why libdispatch shouldn’t 
take the same approach.

Overall, I think the idea is good but some of the details are really lacking. 
As it stands, I would vote to reject this proposal and request revision, or 
reject it outright and suggest to use third-party wrappers around libdispatch 
(like the community is already doing).

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0086: Drop NS Prefix in Swift Foundation

[Patrick Smith via swift-evolution]

I second Matthew’s points. I believe dropping NS- is more harmful than helpful, 
especially for the future. People have been using Foundation with the prefix 
for decades, so I don’t think there’s a longing need that will make using it in 
Swift unbearable. It has an older Objective-C flavoured approach, relying 
heavily on classes, run loops, key value observing (e.g. NSOperation), 
exceptions, and notifications. I think its philosophy will stand out more than 
its NS- prefix. Even if many classes become value types, it feels more like a 
port.

I think for something to be so central as the recommended ‘foundational’ 
library for Swift, it carries too much baggage, which is unfortunate in the 
light of Swift’s radical eagerness to reject unnecessary legacy.

Many Foundation classes expect NSObject subclasses for delegates and for key 
value coding & observing. Key value observing requires on-the-fly subclassing 
at run time, something which goes strongly against Swift’s philosophy AFAIK.

Foundation is in some cases a wrapper around underlying technologies such as 
GCD, because years ago an Objective-C wrapper was seen as a more friendly, more 
safe, and a more familiar object-oriented approach. With Swift we have the 
power to make those technologies themselves more friendly, safe, and familiar 
with modernisations such as the current proposal for libdispatch. Extensions 
allow us to add properties and methods directly to the native types.

NSURL has methods such as .getResourceValue(_:forKey:) that involve mutable 
state.

I think removing the prefixes will take valuable real estate for types such as 
‘URL’ and ‘Data’, which instead can have new replacements made, focused on the 
use-cases of only Swift. I think DispatchData could be a fine choice for 
‘Data’, and has the strong benefit that it bridges to NSData on Darwin.

I fully support the idea of improving Foundation, and of there being a 
Linux-compatible version. I don’t support it being as first class as the 
standard library or libdispatch, and don’t support removing the NS prefixes.

Patrick


> On 11 May 2016, at 1:36 AM, Matthew Johnson via swift-evolution 
>  wrote:
> 
>> What is your evaluation of the proposal?
> I very much support hoisting types, updating enumerations, and updating the 
> NSStringEncoding constants.  
> 
> I do not support dropping NS on type level names.  Dropping the 2 character 
> prefix is a very small benefit and it comes with very real costs.  I believe 
> unprefixed top level names should not be taken without a manual review of the 
> API design.  
> 
> Types which will be value types in the future are obvious candidates for 
> redesign but are not the only types whose API would benefit by human 
> consideration and Swiftification.  Keeping the NS prefix until this happens 
> recognizes that the Swiftification of Foundation is a work in progress.  It 
> will give us more options in the future that don’t involve breaking changes.  
> 
> It will also serve as a signal to developers about what kinds of APIs should 
> be considered idiomatic in Swift.  If we want developers to learn how to 
> distinguish idiomatic Swift, our API guidelines, etc from Objective-C 
> mappings we need to provide some cues.  I believe name prefixes are a good 
> way to do this.
> 
> I hope that we will move forward with most of this proposal while keeping the 
> NS prefix for top-level names.
> 
>> Is the problem being addressed significant enough to warrant a change to 
>> Swift?
> Yes, but we need to do this carefully, deliberately and in a way that we 
> won’t regret in the future.  I believe several parts of the proposal are 
> warranted, but the namesake “drop NS prefix” portion should deferred until 
> each type receives manual consideration and possibly redesign.
> 
>> Does this proposal fit well with the feel and direction of Swift?
> Mostly yes.  However, taking top-level unprefixed names without a process of 
> Swiftification does not.
> 
>> If you have used other languages or libraries with a similar feature, how do 
>> you feel that this proposal compares to those?
> I think this question is N/A for this proposal.
> 
> I hesitate in saying this, but I think the best comparison to consider is the 
> origin of Foundation and Cocoa themselves.  They are fantastic Objective-C 
> APIs.  If they had originated by wrapping pre-existing APIs written in a 
> different language with different idioms and then incrementally enhanced I 
> wonder if they may have been less fantastic.  
> 
> I believe reserving unprefixed top-level names for manually designed, 
> idiomatic types is the path for Swift that avoids this risk altogether and 
> gives us the best chance possible at an incredible, idiomatic set of 
> libraries.
> 
>> How much effort did you put into your review? A glance, a quick reading, or 
>> an in-depth study?
> I participated in the discussion, read the proposal, and carefully considered 
> the 

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 
>> > 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 

 is implemented.

>> 
>> - 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

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

Re: [swift-evolution] [Review] SE-0084: Allow trailing commas in parameter lists and tuples

[Vladimir.S via swift-evolution]

Fully support your opinion.

> PS: can they actually be removed EVERYWHERE instead?!

Yes, I believe it will be much better to propose feature to allow line 
break instead of comma, so we can have:


let x = [10
20
30]

let y = [1 : "one"
2 : "two"]

(from proposal):

func padStringToLength(
sourceString: String
destinationCount: Int
paddingStyle: StringPaddingStyle = .Left
paddingCharacter: Character = " "
) -> String {
/* ... */
}

padStringToLength(
sourceString: "source"
destinationCount: 4
paddingStyle: .Right
paddingCharacter: ""
)

let tuple: (
string: String
number: Int
) = (
   string: "string"
   number: 0
)

...  ...

This solves all the problems with diffs, makes code much clean and nice, no 
additional noise. Why we need these commas instead of this solution? IMO 
this will be real step forward.


Is there such a proposal? (Or probably was discussed already?)

On 12.05.2016 7:46, L Mihalkovic via swift-evolution wrote:


-1 - for ever



On May 11, 2016, at 6:47 PM, Joe Groff via swift-evolution
> wrote:



On May 10, 2016, at 11:53 AM, Chris Lattner via swift-evolution
> wrote:

Hello Swift community,

The review of "SE-0084: Allow trailing commas in parameter lists and
tuples" begins now and runs through May 16. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0084-trailing-commas.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


+1 from me. We should be consistent in either accepting or rejecting
trailing commas everywhere we have comma-delimited syntax. I'm in favor
of accepting it, since it's popular in languages where it's supported to
enable a minimal-diff style, so that changes to code don't impact
neighboring lines for purely syntactic reasons. If you add an argument to
a function, without trailing comma support, a comma has to be added to
dirty the previous line:

--- a.swift
+++ a.swift
 foo(
   x: 0,
-  y: 1
+  y: 1,
+  z: 2
 )

Trailing commas avoid this:

--- a.swift
+++ a.swift
 foo(
   x: 0,
   y: 1,
+  z: 2,
 )


In languages that don't support trailing commas, many users resort to the
abomination of leading-comma style, strangely popular in Haskell and
related languages:


I am not sure I understand where the “abomination” lies in using
leading-comma style… but I will try to see it.


--- a.swift
+++ a.swift
 foo( x: 0
, y: 1
+   , z: 2
)

I think the trailing-comma syntax jives much better with Swift style.



If commas are to be construed as elegantly but meaninglessly dropped little
crumbs, then one can see why it might not matter where they go, or how many
there are, which as well as begging the question of allowing them at the
end, should equally prompt the question of completely removing them
altogether. And if having extras is just /great anticipation on future
needs/, should we think about considering the following lines as all equivalent

let v0 = (1,
  2,
  3)
let v1 = (1,
  2,
  3,
 )
let v2 = (,// just in case I want to add something at the front later?!
  1,
  2,
  3,)
let v3 = (1,
  2,
  ,
  3,
 ) // just in case I want to add something in the middle or
front later
let v4 = (1,,
  2,,
  3,,)   // lets be really good programmer, in case it doubles in
length


Aside from the good-anticipation interpretation of trailing commas, there
is also the /thinking-interuptus/  line of interpretation:

this and
that and

standing for: now hold your breath, I am not done.. or maybe I lost my
train of thoughts so I am actually done… who knows.. read the next line to
figure that out.


As I recall there is an ongoing debate about long string 

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

[Pierre Habouzit via swift-evolution]

> On May 11, 2016, at 9:02 AM, Dennis Weissmann via swift-evolution 
>  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).

> 
> - 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

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0084: Allow trailing commas in parameter lists and tuples

[Vladimir.S via swift-evolution]

On 12.05.2016 5:28, Ricardo Parada via swift-evolution wrote:

I would support the trailing comma so that the language is consistent but I
don't think I would personally use it.


IMO language will be consistent (regarding trailing comma) if we extend the 
proposal to *any comma-separated list* in Swift.. like list of generic 
types .
So, I'd understand if Swift will allow(or better - *require*) trailing 
comma in *any* such list. Or just for array/dict. But not for some piece of 
code(func params, tuples), but not for other(list of generics or other)


And I don't accept the problem with diffs - yes, diff will show you not 
just new element is added, but also that element that was last is not last 
anymore.

Also, often closed `)` is placed on the same line with last parameter:
func myFunc(a: Int,
b: String,
c: Int,) {
}
so after we add `d` parameter:
func myFunc(a: Int,
b: String,
c: Int,
d: String) {
}

the diff will show not only new `d` declaration, but also changes to `c` 
line even with trailing comma.


IMO when I write function(code), I usually don't expect it will have more 
arguments. When I write array/dict initialization(data), I usually expect 
to add more items to it.


So I'm strongly -1 on this proposal in any case. At least we should extend 
it to allow trailing comma in any list. And I then (if this is so pretty 
feature) prefer Swift to require that trailing comma in list. This will be 
consistent and strict.

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

Re: [swift-evolution] [Review] SE-0084: Allow trailing commas in parameter lists and tuples

[Brent Royal-Gordon via swift-evolution]

>   * What is your evaluation of the proposal?

I was skeptical of this until a week or two ago, when I had some code where I 
ended up commenting out certain parameters. Removing the now-trailing commas 
was an inconvenience. So, +1 from me.

>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?

It's a minor issue, but it's a minor fix too.

>   * Does this proposal fit well with the feel and direction of Swift?

Yes; this brings function call syntax in line with other comma-separated lists.

>   * If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?

I've used a number of languages like this and it does come in handy 
occasionally.

>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

Quick reading, plus participation in previous discussion (where I took the 
other side).

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [Proposal] More lenient subscript methods over Collections

[Brent Royal-Gordon via swift-evolution]

> It sounds good, thanks for you suggestions @Vladimir, @Patrick and @Brent.
> 
> I've just updated the proposal: 
> https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/-more-lenient-collections-subscripts.md#detailed-design
> 
> - Luis

Hmm. If you're going with `checking` for one of them, perhaps the other should 
be `clamping` (for the analogous method on `Range`, which you might want to use 
in the implementation of that subscript). That would create a nicely matched 
pair:

array[checking: 0..<10]
array[clamping: 0..<10]

-- 
Brent Royal-Gordon
Architechies

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