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

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

[Ray Fix via swift-evolution]

>   * What is your evaluation of the proposal?

-1 for me.  This proposal inspired me to start participating again. :]

The perceived benefits aren’t worth the visual noise to me.  (It looks 
half-baked to my eyes.)  I *really* want to avoid having to and a custom 
linting step in all my projects.  I further fear if this did become possible, I 
would somehow end up on a project where having extra commas *everywhere* was 
part of some coding standard.  Noo! :]

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

Not from my vantage point.  If anything, I would remove the capability for 
collections. I was blissfully unaware of the functionality before reading this 
proposal.

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

I don’t believe so.  BTW, what about enum case statements?  enum Few { case 
one, two, three, } Or generic argument lists (I think as someone already 
mentioned.)  Shouldn’t those support extra commas too?  (No please! Haha.  :)

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

Similar to Swift, C++ ignores trailing commas in some situations, but not for 
param lists.  I actually did use this feature in a few instances where the 
lists where frequently changed as it helped with merges.  I put up with it 
because it was in a few limited contexts and not everywhere.  This proposal 
would make it *everywhere* I fear.

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

Reading through the proposal and skimming the threads.

Best Wishes,
Ray
___
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

[Thorsten Seitz via swift-evolution]

> Am 11.05.2016 um 19:23 schrieb Joe Groff :
> 
> 
>>> 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.

Ah, I see. But wouldn't this already be a problem with the current syntax as 
well, because the `where` might come after a constraining type which might be 
an existential?

As an alternative to `where` we could use `with` for existentials.

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

Re: [swift-evolution] [swift-evolution-announce] [Accepted with Revision] SE-0080: Failable Numeric Conversion Initializers

[Chris Lattner via swift-evolution]

On May 11, 2016, at 4:18 PM, Matthew Johnson via swift-evolution 
 wrote:
> 
>> Thank you to Matthew Johnson for driving this discussion.  I filed SR-1491 
>> to track this work, it would be a great starter bug.
> 
> Thanks Chris.  Is there a mechanism for the community to propose extensions 
> to Foundation types?  I was under the impression that swift-evolution was the 
> mechanism for proposing changes to any public Swift API including corelibs.

At the moment, there isn’t other than filing a radar on bugreporter.apple.com.  
This is a bit of a procedural issue, because corelibs foundation is currently 
scoped to a direct reimplementation of the existing Foundation APIs.  This may 
improve in the future, but right now everyone is pretty occupied with high 
priority stuff.

That said, the Foundation team is aware of this proposal 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

[L Mihalkovic via swift-evolution]

-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 
>> mailto:swift-evolution@swift.org>> 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 literal… Perhaps this 
line of thinking can help there too?!!  Swift would become very unique and 
progressive with something like:

let var = this is a long string literal”  // notice my continuation quote at 
the end 
 which I am continuing to the”// notice how I am letting people 
know that, like my parameter list,
 next line and perhaps even”  // my string may not be quite 
finished yet
 to the next one and even”// … 

Like in the convenient case of a trailing comma in a parameter list, I added a 
last quote character so that I can add 

Re: [swift-evolution] multi-line string literals.

[Eduardo Mourey Lopez Ne via swift-evolution]

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

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

[Muse M via swift-evolution]

I would prefer a space before Dispatch() and this could allows developer to
extend new and custom features like fastasync, multithread, benchmark,
fifo, etc.Just an opinion.

sync Dispatch()
async Dispatch()

On Thu, May 12, 2016 at 11:02 AM, Ricardo Parada via swift-evolution <
swift-evolution@swift.org> wrote:

>
>
> For synchronously and asynchronously how about the adverbs before the verb:
>
> syncDispatch()
> asyncDispatch()
>
> ?
>
> 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
>
>
___
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

[Ricardo Parada via swift-evolution]

For synchronously and asynchronously how about the adverbs before the verb:

syncDispatch()
asyncDispatch()

?

> 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] multi-line string literals.

[Ricardo Parada via swift-evolution]

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

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

[Ricardo Parada via swift-evolution]

My apologies... I did not know that trailing commas were already legal. Thanks 
for pointing that out. Nevertheless I don't think I would have supported that. 

I also understand that the trailing comma may help a "git diff" look better and 
simpler. 

The trailing comma still bothers me though because it looks like somebody 
forgot to add something or as if something got deleted by mistake. 

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

> On May 11, 2016, at 11:09 AM, Erica Sadun  wrote:
> 
> 
>>> On May 11, 2016, at 8:01 AM, Ricardo Parada via swift-evolution 
>>>  wrote:
>>> On May 10, 2016, at 2:53 PM, Chris Lattner  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
>> 
>>> * What is your evaluation of the proposal?
>> 
>> -1
>> 
>> I don’t like the proposal.  I understand the flexibility it gives to 
>> rearranging elements but to someone reading the code it looks like an 
>> element was removed by mistake.
> 
> 
> This objection is coming up quite often and I don't really see the difference 
> between trailing commas in collections (legal in Swift)
> 
> let listenerKeys: NSDictionary = [
> AVFormatIDKey: NSNumber(unsignedInt: kAudioFormatAppleLossless),
> AVSampleRateKey: 44100.0,
> AVNumberOfChannelsKey: 1,
> AVEncoderAudioQualityKey: NSNumber(int: 
> Int32(AVAudioQuality.Max.rawValue)),
> ]
> 
> And trailing commas in parameter lists (not yet allowed in Swift):
> 
> public convenience init(
> _ w: CGFloat,
> _ h: CGFloat,
> position: CGPoint = .zero,
> backgroundColor: UIColor = UIColor.whiteColor(),
> translucency alpha: CGFloat = 1.0,
> borderWidth: CGFloat = 0.0,
> borderColor: UIColor = UIColor.blackColor(),
> cornerRadius: CGFloat = 0.0, // this is currently illegal
> ){
> ...
> }
> 
> Neither example reads to me as if an element was removed by mistake. Both 
> greatly enhance programming flexibility. Both allow the final comma to be 
> omitted and/or the elements to be re-ordered.
> 
> To summarize the complaints to date:
> 
> * It make code read like errors
> * Arrays and dictionaries are different "things" than parameters and tuples; 
> They are structurally different
> * Parameter lists should always be of fixed size at deployment time; Once a 
> signature is fixed and consumed, it's difficult to change
> 
> To which I reply:
> 
> * Well structured code needn't read like an error. The examples above show an 
> in-house style that allows final commas. Your in-house style may differ and a 
> linter can catch these issues.
> * Both collections and signatures are syntactically similar in layout even if 
> they are semantically different in use. In Swift, complex method signatures 
> with defaulted arguments like the example shown are not uncommon. Do not 
> limit your thinking to single line lists of (x: T, y: U, z: V) signatures.
> * Parameter lists and function signatures, like collections, can evolve, 
> especially when using defaulted parameters, even when they are consumed at 
> multiple points.
> 
> -- E
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Brent Royal-Gordon via swift-evolution]

>   * What is your evaluation of the proposal?

I'm overall in favor.

I agree with the others who say that `synchronously` and `asynchronously` are 
poor name choices. If we're going to deviate from the API guidelines, we should 
at least choose names which have other desirable properties, like brevity or 
matching existing terms of art. These names don't. I would prefer `sync` and 
`async`, or if necessary, `dispatchSync` and `dispatchAsync`.

I'm very impressed by the way the "specific" APIs have been translated to 
Swift, but I think the method names are wrong, particularly the `get` method. 
Ideally these would be a subscript, but we don't have generic subscripts yet. 
Failing that, I suggest using `specificValue(for key:)` and `setSpecificValue(_ 
value: for key:)`. I'm also worried about how this will interoperate with 
Objective-C: Will there be some way to smuggle one of the arbitrary Objective-C 
pointers for this API into Swift as a DispatchSpecificKey, or vice versa?

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

Yes. libdispatch is pretty awkward even in Objective-C, let alone in Swift.

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

N/A.

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

Quick reading.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [swift-evolution-announce] [Accepted with Revision] SE-0080: Failable Numeric Conversion Initializers

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On May 11, 2016, at 6:01 PM, Chris Lattner  wrote:
> 
> Proposal link: 
> https://github.com/apple/swift-evolution/blob/master/proposals/0080-failable-numeric-initializers.md
> 
> Hello Swift Community,
> 
> The review of SE-0080: "Failable Numeric Conversion Initializers" ran from 
> May 3…9, 2016. The proposal is *Accepted with Revision* for Swift 3.  
> 
> The feedback on the proposal from the community and the core team was 
> universally positive, and the new initializers on the primitive integer and 
> floating point types have been approved.  However, swift-evolution isn’t the 
> right mechanism to propose extensions to Foundation types, so the extensions 
> that adds conversions from NSNumber and to Foundation types should be subset 
> out of the proposal.
> 
> Thank you to Matthew Johnson for driving this discussion.  I filed SR-1491 to 
> track this work, it would be a great starter bug.

Thanks Chris.  Is there a mechanism for the community to propose extensions to 
Foundation types?  I was under the impression that swift-evolution was the 
mechanism for proposing changes to any public Swift API including corelibs.

-Matthew

> 
> -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] [Accepted with Revision] SE-0080: Failable Numeric Conversion Initializers

[Chris Lattner via swift-evolution]

Proposal link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0080-failable-numeric-initializers.md

Hello Swift Community,

The review of SE-0080: "Failable Numeric Conversion Initializers" ran from May 
3…9, 2016. The proposal is *Accepted with Revision* for Swift 3.  

The feedback on the proposal from the community and the core team was 
universally positive, and the new initializers on the primitive integer and 
floating point types have been approved.  However, swift-evolution isn’t the 
right mechanism to propose extensions to Foundation types, so the extensions 
that adds conversions from NSNumber and to Foundation types should be subset 
out of the proposal.

Thank you to Matthew Johnson for driving this discussion.  I filed SR-1491 to 
track this work, it would be a great starter bug.

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

[swift-evolution] [Accepted with Revision] SE-0076: Add overrides taking an UnsafePointer source to non-destructive copying methods on UnsafeMutablePointer

[Chris Lattner via swift-evolution]

Proposal link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0076-copying-to-unsafe-mutable-pointer-with-unsafe-pointer-source.md

Hello Swift Community,

The review of SE-0076: "Add overrides taking an UnsafePointer source to 
non-destructive copying methods on UnsafeMutablePointer" ran from May 3…9, 
2016. The proposal is *Accepted with Revision* for Swift 3.  

The feedback on the proposal from the community and the core team universally 
agreed that there is a problem that needs to be solved here.  However, instead 
of adding overloads of the methods as proposed, it would be better to change 
the existing methods to take UnsafePointer<> instead of UnsafeMutablePointer<>. 
 Given the existing promotion rules that exist in the compiler, it will achieve 
the same effect.  As part of this, other similar functions in the standard 
library should be audited and fixed as well.

Thank you to Janosch Hildebrand for driving this discussion.  I filed SR-1490 
to track this work, it would be a great starter bug.

-Chris Lattner
Review Manager

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

[swift-evolution] [Rejected] SE-0074: Implementation of Binary Search functions

[Chris Lattner via swift-evolution]

Proposal link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0074-binary-search.md

Hello Swift Community,

The review of SE-0074: "Implementation of Binary Search functions" ran from May 
3…9, 2016. The proposal is *rejected* for Swift 3.  

The feedback on the proposal was generally positive about the concept of adding 
binary search functionality, but  negative about the proposal as written, with 
feedback that it was adding too much complexity to the API.

Thank you to Lorenzo Racca, Jeff Hajewski, Nate Cook for driving this 
discussion.

-Chris Lattner
Review Manager

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

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

[Chris Lattner via swift-evolution]

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] [Accepted] SE-0060: Enforcing order of defaulted parameters

[Chris Lattner via swift-evolution]

Proposal link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0060-defaulted-parameter-order.md

Hello Swift Community,

The review of SE-0060: "Enforcing order of defaulted parameters" ran from May 
3…9, 2016. The proposal is *accepted* for Swift 3.  

The feedback on the proposal was generally positive (several people remarked 
that they didn’t know this was allowed).  Some people pointed out that removal 
of this capability penalizes API design in cases where there is no inherent 
order to parameters, but this is also true of non-defaulted parameters.  The 
core team prefers to encourage consistency at call sites.

Thank you to Joe Groff for proposing this, I filed SR-1489 to track this, it is 
a great starter bug.

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

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

[Russ Bishop via swift-evolution]

You do make some good points; we have a variety of important areas that are 
completely unimplemented across any platforms, besides the feature parity 
across platforms.

I also wonder why this can’t be provided as a new library on top of (rather 
than as a replacement for) the existing libDispatch C interface. I have my own 
DispatchQueue class that does a lot of what this proposal suggests but it 
doesn’t replace the dispatch_* calls so it doesn’t break anything.

We are starting to accumulate a massive number of breaking changes. Yes there 
are fix-its but you still have problems with branches and coordinating the 
upgrade.

I’m also sympathetic to the fact that any changes we want to make will only get 
more difficult with time and the longer we wait to refactor APIs, rename 
things, etc the less likely it will even be possible. I think part of the rush 
for these kinds of changes is the fact that Swift 3 wants to focus on ABI 
stability and a lot of people are interpreting that as “this is our last chance 
to fix everything we don’t like!”, though ABI stability != API stability. Might 
just be me though.


Russ


> On May 10, 2016, at 11:30 PM, Drew Crawford via swift-evolution 
>  wrote:
> 
> I'm one of the largest dispatch-on-linux users right now.  In fact, I'm 
> reasonably sure I'm THE largest.  I have an application in production that 
> uses some 400 dispatch calls.  
> 
> On Linux, I'm running Swift 3 in production, essentially because 
> Dispatch/Linux in 2.2 does not even exist.  On OSX/iOS, I compile the same 
> codebase with Swift 2.2, because that's the version that's released, and 
> using released software is a sane thing to do.
> 
> This proposal places me in the uncomfortable situation of trying to somehow 
> smooth out a truly MASSIVE API delta with #if.  And that's not going to 
> happen.  Realistically, what I will do is create some kind of FrankenSwift 
> that either backports the new API to Swift 3 or the old API to Swift 2.  And 
> that is a ton of work, really stupid work, and I would infinitely prefer to 
> spend that time doing something actually useful to the world.  To be clear, I 
> don't fear migration; what I fear is the heisenmigration, where one of my 
> platforms must migrate, and the other ones can't.
> 
> More broadly, I am concerned about the direction the language is going where 
> we do not even have working libraries yet and already we are doing sweeping 
> API changes to them.  I suspect this is motivated by a fundamentally 
> incorrect premise–the premise that because it's not released yet, we can get 
> away with it.  When actually that's backwards: we can get away with breaking 
> changes later, but if we do them now we will ruin everything.  Let me explain.
> 
> Right now, Linux Swift programmers exist. And they need to be able to solve 
> ordinary problems, like writing a string to a file, or spinning up a 
> background thread.  And I do mean: sometime before Late 2016.  No amount of 
> telling them "don't do that, it's not released" is going to stop this.  The 
> only question is whether upstream is going to be the repo that solves their 
> problem, or whether they go to solve the problem somewhere else.  Because 
> when they go somewhere else, they invest there.
> 
> Increasingly, because upstream is not interested in the problem, I am seeing 
> Linux folk go solve the problem somewhere else.  Just counting the projects 
> I'm personally aware of, there are 3 foundation alternatives and 1 package 
> manager alternative.  All because upstream has no sane path to e.g. reading a 
> file on disk in the kind of timeframe working programmers actually need to do 
> it in.
> 
> What we *should* be doing is creating libraries that *work*, *releasing 
> them*, and then we can do as much API Disneyland as we want without harassing 
> the working programmer.
> 
> 1.  If we're out of bugs to fix, why not release?  Then folks like me can get 
> off the snapshot treadmill and we won't be annoyed by massive API delta until 
> we can do it all at once, which is (relatively) easy.
> 2.  If we're not out of bugs to fix, why not work on them, and then release, 
> and then come back to this?
> 3.  Since Swift 3 will have a stable ABI, why not ship both libdispatch2 and 
> libdispatch3 and let the programmer plan her own migration?  I'm not even 
> sure the stable ABI part is relevant, since Dispatch is almost entirely C.
> 
> All of these are saner alternatives to the proposal, and all of them achieve 
> the stated goal (e.g. we still end up with happy modern APIs).
> 
> I don't mean to pick on this proposal specifically, I agree with the need to 
> modernize the API surface area.  But if we continue to do breaking changes 
> first and releases later I'm concerned about where the early adopters will 
> get pushed to.
> 
> Drew
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinf

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

[David Hart via swift-evolution]

I’d find this very confusing because it would make declarations look the the 
declarations of the generic types comes after their uses.

> On 11 May 2016, at 22:56, Hooman Mehr via swift-evolution 
>  wrote:
> 
> How about a more radical change that eliminates this entire concern and keeps 
> the whole generics declarations in one place: 
> 
> Move the entire generic declaration with its brackets somewhere other than 
> between function name and its parameters.
> 
> I know this breaks the “norm”, but what do you think?
> 
>> On May 11, 2016, at 10:23 AM, Joe Groff via swift-evolution 
>> mailto:swift-evolution@swift.org>> 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 
 mailto:swift-evolution@swift.org>>:
 
 
>> On May 10, 2016, at 4:19 PM, Douglas Gregor via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> 
>> On May 10, 2016, at 3:46 PM, Jordan Rose via swift-evolution 
>> mailto:swift-evolution@swift.org>> 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.
>> 
>> -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

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

Re: [swift-evolution] [proposal] Allow "let" for computed properties which only reference immutable data

[Haravikk via swift-evolution]

> On 11 May 2016, at 21:04, Chris Lattner  wrote:
> 
> On May 11, 2016, at 11:31 AM, Joe Groff via swift-evolution 
>  wrote:
>>>   var combined:[Int64] { return a + b }
>>> }
>>> 
>>> Each of these arrays is 512kb, so storing a fixed value for the combined 
>>> property would require another megabyte of space per instance of Test, but 
>>> if the combined property is only infrequently called on some instances of 
>>> Test, then it would be a waste of memory to precompute it, especially if 
>>> you’re dealing with thousands of instances, with only a fraction of them 
>>> calling the computed property. If you want to accelerate usage of the 
>>> computed property then that’s what lazy variables are for, as you can delay 
>>> the expensive combination until you actually need it.
>> 
>> Being constant doesn't need to imply "precomputed". I would expect a 
>> computed 'let' to still be computed on-demand. 'let' is more important as an 
>> API contract; you're guaranteeing to the user that an API won't produce 
>> different values if called on the same object at different times.
> 
> Right.  “let” means “always has the same value”, a get-only property means 
> “can not be set” (which is less restrictive).  Computed or not isn’t the 
> issue here.

Ah, thanks both of you, I misunderstood then.

Hmm, in that case though, other than the simple case given in the original 
message, it seems like this might be non-trivial to check, as you’d need to 
trace every method that could be used within the computed property to ensure 
that no vars are ever accessed.

I proposed a while ago the idea of having the compiler determine whether a 
method is mutating automatically, as this could do various useful things like 
issue a warning if a mutating method that doesn’t change anything and similar 
cases, but it was dismissed at the time due to the complexity of adding such 
checking. This seems like it might be similar in principle; it seems very 
reasonable in a self-contained method that doesn’t rely on any others, but the 
rest of the time it’s hard to check.

I suppose it could be done for these kinds of self-contained computed 
properties initially though?
___
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

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

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

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

[Austin Zheng via swift-evolution]

Another idea: what about a comma separating the return type from the where
clause?

func myFunc(arg1: A, arg2: B) -> Bool, where A :
CustomStringConvertible { ... }

Best,
Austin

On Wed, May 11, 2016 at 1:56 PM, Hooman Mehr via swift-evolution <
swift-evolution@swift.org> wrote:

> How about a more radical change that eliminates this entire concern and
> keeps the whole generics declarations in one place:
>
> Move the entire generic declaration with its brackets somewhere other than
> between function name and its parameters.
>
> I know this breaks the “norm”, but what do you think?
>
>
> On May 11, 2016, at 10:23 AM, Joe Groff via swift-evolution <
> swift-evolution@swift.org> 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 <
> swift-evolution@swift.org>:
>
>
> On May 10, 2016, at 4:19 PM, Douglas Gregor via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On May 10, 2016, at 3:46 PM, Jordan Rose via swift-evolution <
> swift-evolution@swift.org> 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.
>
> -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
>
>
___
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

[Hooman Mehr via swift-evolution]

How about a more radical change that eliminates this entire concern and keeps 
the whole generics declarations in one place: 

Move the entire generic declaration with its brackets somewhere other than 
between function name and its parameters.

I know this breaks the “norm”, but what do you think?

> 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.
> 
> -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] [swift-evolution-announce] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions

[David P Grove via swift-evolution]

My personal opinions, as someone who is relatively new to Swift and
libdispatch, but has spent some time playing with them recently ;)

>* What is your evaluation of the proposal?

Overall, I like the direction of the proposal.  I think moving away from
the legacy C APIs will make libdispatch in Swift more accessible and
pleasant to use.

I would like to see more details on how the overlay will be implemented on
platforms without Objective-C.  Specifically, since libdispatch is mostly a
C library, it seems to me that this would be a good opportunity to purge
Objective-C from the libdispatch implementation entirely and have a simpler
and more portable Swift + C implementation.  That is what we have to do for
Linux, so let's eliminate some of the platform differences and do it
everywhere.  However, that may be at odds with the "without adding runtime
overhead" objective of the proposal.  I made an attempt earlier this spring
to get libdispatch's C structs to masquerade as Swift classes (instead of
Objective-C classes as they currently do when Objective-C is available).  I
gave up because some of the implementation tricks used in libdispatch's
queues made it a fairly invasive change.  However, others more skilled in
Swift+libdispatch might be able to pull it off.  Is the implementation plan
to write a fairly thick Swift layer that wraps primitive C types, or is it
something else?

Echoing others, I would keep sync/async as names in the APIs. These are
well known terms that are used in many similar tasking libraries in other
languages; they are also familiar to current libdispatch users.

I would like to see a statically checkable distinction in the API between
Darwin-specific functionality and the APIs that are truly cross platform.
This mainly shows up in the DispatchSources portion of the API.  Tag
methods of DispatchSource with availability macros or similar?

It seems overly verbose to prefix all the types with Dispatchis this
really necessary?


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

From a Linux perspective, the existing Swift libdispatch API is badly
incomplete. The lack of Objective-C on Linux results in a poor quality
import of the dispatch headers.  Something needs to be done in the Swift 3
time frame to fix this.  We could get by with a less sweeping change than
this proposal, but something does need to be done.

Ideally, the new overlay would also be back-ported to Swift 2.2 to address
Drew's valid concerns about maintaining cross-platform code that uses
libdispatch during the transition from Swift 2.2 to Swift 3.

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

Yes (but I am newish to Swift...).

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

It should get libdispatch in Swift to be roughly on par with the
integrated experience one gets from using tasking libraries in other modern
object-oriented languages with closures.

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

Read proposal carefully.  Have thought about the issues quite a bit
recently.

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

Re: [swift-evolution] [proposal] Allow "let" for computed properties which only reference immutable data

[Chris Lattner via swift-evolution]

On May 11, 2016, at 11:31 AM, Joe Groff via swift-evolution 
 wrote:
>>var combined:[Int64] { return a + b }
>> }
>> 
>> Each of these arrays is 512kb, so storing a fixed value for the combined 
>> property would require another megabyte of space per instance of Test, but 
>> if the combined property is only infrequently called on some instances of 
>> Test, then it would be a waste of memory to precompute it, especially if 
>> you’re dealing with thousands of instances, with only a fraction of them 
>> calling the computed property. If you want to accelerate usage of the 
>> computed property then that’s what lazy variables are for, as you can delay 
>> the expensive combination until you actually need it.
> 
> Being constant doesn't need to imply "precomputed". I would expect a computed 
> 'let' to still be computed on-demand. 'let' is more important as an API 
> contract; you're guaranteeing to the user that an API won't produce different 
> values if called on the same object at different times.

Right.  “let” means “always has the same value”, a get-only property means “can 
not be set” (which is less restrictive).  Computed or not isn’t the issue here.

-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

[Joe Groff via swift-evolution]

> 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

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.

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

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

[MobileSoft (Piotr) via swift-evolution]

> In your example:
> a = 5 if b == x
> 
> What value is assigned to 'a' if 'b' and 'x' are not equal?

And what is with ‘a’ if this situation:

if b == x {
a = 5
}

Nothing :)

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

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

[William Shipley via swift-evolution]

All for it!

—

I believe that the “Recv” on the right is a typo here:

DISPATCH_SOURCE_TYPE_MACH_RECV  DispatchSourceMachRecv
since it’s spelled out in other places:

class func machReceive(port: mach_port_t, queue: DispatchQueue? = nil) -> 
DispatchSourceMachReceive

(If I’m wrong then I object to this one abbreviation. :)

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

[swift-evolution] [Pitch] Align @objc inference with the semantic model

[Douglas Gregor via swift-evolution]

Hi all,

Right now, Swift infers @objc (meaning that you don’t have to write it 
explicitly) in a number of places:

1) When overriding an @objc declaration
2) When implementing a requirement of an @objc protocol (note: this behavior 
was recently enabled in the Swift compiler)
3) When the declaration is‘@IBOutlet’, or ‘@NSManaged’
4) When the declaration is ‘dynamic’
5) When the declaration is non-private and occurs within a subclass of NSObject 
or an extension thereof, so long as it *can* be expressed in Objective-C

There are different motivations behind the various rules, some of which bear 
re-examination. Before going into the individual rules, here’s why I’m bringing 
this up now:

a) There is no easy way to articulate the rules we have. They mostly came from 
a desire to avoid making Swift programmers write ‘@objc’, but that’s not very 
principled.

b) When Swift code follows the Swift API design guidelines, the Objective-C 
names provided by the Swift compiler by default aren’t good names in 
Objective-C, a topic I brought up a few months ago 
. The upshot is 
that, for entities that are intended to be used in Objective-C, inferring 
‘@objc’ doesn’t help when you’re going to explicit write out the Objective-C 
selector anyway (‘@objc(objectAtIndex:)’). The Grand Renaming is forcing this 
on Swift programmers already, so it’s a reasonable time to make a change in the 
area of @objc inference.

c) The “thunks” generated for the compiler to provide Objective-C entry points 
have a non-trivial cost. I measured the code size of a handful of Swift 
projects (all Cocoa[Touch] apps, most Swift-only, some mixed 
Swift/Objective-C), and 6-8% of code size was in these @objc thunks. We have 
some ideas to reduce the code size of @objc thunks in general. However,  I 
suspect that most of these @objc thunks are completely unused, although I 
haven’t done the legwork to prove it, and there is no automatic way to remove 
them.

d) Removing @objc inference for a particular case can silently break working 
code, because something invisible to the Swift compiler (e.g., in Objective-C 
in a mixed-source project, in a system framework, etc.) might be depending on 
that Objective-C entry point. We can probably tolerate such breakage in Swift 3 
where we’re breaking lots of things, but our ability to make sure changes here 
will be diminish rapidly over time. Hence, we’re talking about this now, and we 
need to live with our decisions for a long time.

In general, I’d like to remove @objc inference from places where it isn’t 
needed for the “semantic model”, loosely construed. Let’s go case-by-case with 
the places we do inference now:

(1) and (2) are geared toward consistency of the semantic model. For example, 
you need @objc inference for overrides of @objc declarations because otherwise 
Objective-C code won’t see the override and you’ll get divergent behavior. 
Similarly when you are implementing a requirement of an @objc protocol: 
Objective-C callers need to be able to have something to call. I consider it 
critical that we maintain @objc inference for these cases because maintaining a 
consistent semantic model across Swift and Objective-C code is fundamental to 
interoperability. No proposed change here, aside from noting that the ability 
to infer @objc (including the selector names) when implementing requirements of 
an @objc protocol was very recently introduced in the Swift compiler.

(3) is about interoperability with certain frameworks and tools. @objc 
inference helps eliminate some boilerplate today, because these features depend 
on the Objective-C runtime. Will these features, with their current spelling in 
Swift, *always* depend on the Objective-C runtime? If so, we can keep the @objc 
inference. Or is there some probable future where the same features could get 
implementations that don’t rely on the Objective-C runtime? If so, we might 
want to eliminate @objc inference for them: today, that means having to write 
‘@objc’ explicitly on such declarations, and if that future comes to pass the 
requirement to add ‘@objc’ will go away (no existing code will break unless a 
user manually deletes an ‘@objc’ from that code). With ‘@NSManaged’, I feel 
like the underlying feature would look *very* different if implemented without 
a backing Objective-C runtime, so I’m inclined to leave @objc inference in 
place. With ‘@IBOutlet’ it’s a whole lot more murky, and the confusion is 
magnified by the fact that ‘@IBAction’ doesn’t currently have @objc inference. 
We should align IBOutlet and IBAction in this regard (so some change is 
needed), but I don’t have a strong sense of which way to go.

(4) ‘dynamic’ infers ‘@objc’ because the Swift runtime doesn’t have support for 
replacing a method at runtime. There are two possible futures here: Swift’s 
runtime gets support for ‘dynamic’ on pure Swift methods (in which case the 
‘@objc’ inference woul

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

[David Hart via swift-evolution]

+1 I’d also vote for dispatchAsync and dispatchSync. For reference, c# is also 
a language with fairly verbose conventions like Swift and it has adopted the 
Async convention for their “async” methods.

> On 11 May 2016, at 20:08, Darren Mo via swift-evolution 
>  wrote:
> 
> Great, this is the libdispatch API that I’ve been dreaming about! I think it 
> meshes well with the rest of Swift.
> 
> I am concerned about one thing though: the naming of the DispatchGroup 
> methods synchronously/asynchronously.
> 
> They are hard to type correctly and ugly to look at.
> sync/async are already well-established abbreviations in the tech industry.
> They are adjectives without verbs, which goes against the API Design 
> Guidelines.
> 
> I suggest sticking with the naming from the C API. For example:
> 
> let queue = …
> queue.dispatchAsync {
>   …
> }
> 
> Cheers,
> Darren
> 
> > 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] [RFC] #Self

[Matthew Johnson via swift-evolution]

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.

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 declaration.  We already have a covariant 
construct (Self) and the proposal is to introduce an invariant construct (#Self 
or Type).  The invariant semantic should be consistent regardless of whether it 
is used in a protocol requirement or a type declaration.

IMO BaseSelf is a poor choice of name for something that is supposed to be 
valid syntax in value types as well as classes.

> 
>> On 11.05.2016 18:58, Matthew Johnson wrote:
>> 'f' would return E for E, F and G.  Because the conformance is declared
>> by E the requirement to return #Self is fixed as an invariant
>> requirement to return E for all potential subclasses.
>> 
 
 Probably you(we) need another proposal, like BaseSelf (or SuperSelf)
 that means "this class or any its base class", then I understand how
 such a `f()->BaseSelf` protocol requirement can be applied to E
 class and also be true for F&G classes (as f() inherited from base
 class will return instance of E which is base for both).
>> This is exactly what #Self (or Type) does.  The behavior you have been
>> describing is the behavior of Self which already exists.
>> 

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

Re: [swift-evolution] [proposal] Allow "let" for computed properties which only reference immutable data

[Joe Groff via swift-evolution]

> On May 11, 2016, at 11:02 AM, Haravikk  wrote:
> 
> 
>> On 11 May 2016, at 18:00, Joe Groff via swift-evolution 
>>  wrote:
>>> On May 11, 2016, at 8:34 AM, Matthew Johnson via swift-evolution 
>>>  wrote:
 On May 11, 2016, at 10:26 AM, Sean Heber via swift-evolution 
  wrote:
 
 I kind of agree with the logic of that, but imagine the following:
 
 class Test {
 let hello = “hello”
 var subject = “world”
 var phrase: String { return hello + “, “ + subject }
 }
 
 In this scenario, “subject” can be changed.. and that changes the result 
 of “phrase”. Things like this are why computed properties are “var”.
>>> 
>>> This example would still be required to be var because it accesses a var in 
>>> its implementation.
>>> 
>>> I like the idea of allowing this feature, but only in cases where the 
>>> compiler can verify immutable semantics.  Having it may help drive other 
>>> features that could expand the cases the compiler can verify.  That would 
>>> be great as this is a direction I would like to see Swift take in the 
>>> future.
>> 
>> Yeah, this is why we don't currently allow computed "let" properties. We'd 
>> only want to do so once we have the language facilities to ensure a computed 
>> 'let' property is immutable and has no observable side effects.
> 
> Even if a “computed” property were immutable, do we really want to implicitly 
> make it a constant as well? Take for example:
> 
> class Test {
> let a:[Int64]
> let b:[Int64]
> 
> init(_ value:Int64) {
> self.a = Array(count: 65536, repeatedValue: Int64(value))
> self.b = Array(count: 65536, repeatedValue: Int64(value &+ 1))
> }
> 
> var combined:[Int64] { return a + b }
> }
> 
> Each of these arrays is 512kb, so storing a fixed value for the combined 
> property would require another megabyte of space per instance of Test, but if 
> the combined property is only infrequently called on some instances of Test, 
> then it would be a waste of memory to precompute it, especially if you’re 
> dealing with thousands of instances, with only a fraction of them calling the 
> computed property. If you want to accelerate usage of the computed property 
> then that’s what lazy variables are for, as you can delay the expensive 
> combination until you actually need it.

Being constant doesn't need to imply "precomputed". I would expect a computed 
'let' to still be computed on-demand. 'let' is more important as an API 
contract; you're guaranteeing to the user that an API won't produce different 
values if called on the same object at different times.

-Joe

> 
> The problem really is that the compiler can only do limited analysis about 
> whether a computer property is used a lot, and in most cases it doesn’t care 
> (it only really cares whether something is unused, as it can try to optimise 
> it away), to make a good decision it would need to run the program with a 
> realistic test-case an analysis memory overhead and performance impact of 
> each method.
> 
> So yeah, I’m not really sure of the advantage of this, unless the intention 
> is purely to restrict what can be used within your computed property’s 
> implementation, but I don’t think the compiler can realistically do much in 
> the way of optimising stuff away as precomputed values need to be stored 
> somewhere, which could mean making your type bigger, which begs the question 
> of why you specified a computed value in the first place.
> 
> I guess I’m just confused as to what the problem being solved would really be.

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

Re: [swift-evolution] multi-line string literals.

[Vladimir.S via swift-evolution]

Inline

On 11.05.2016 21:04, Ricardo Parada wrote:



On May 11, 2016, at 12:55 PM, Vladimir.S mailto:sva...@gmail.com>> wrote:


On 11.05.2016 19:38, Ricardo Parada wrote:

I did not suggest the single quote because it is commonly found in the
English language and we would have to escape it.


Wel.. in your document you have a number of variants of multi-line
'feature' implementations with different pros/cons for each.


I don’t have a document.  I’ve seen different proposals.
I have just been commenting on the proposals in this thread.


Oh, sorry :-) Will check the initial sender more carefully the next time.




Could you clarify, why this proposal with single quote can not be inside
your document as just another variant with its own pros/cons ?
Especially, as you can see, if "We'd rather save single quoted literals
for a greater purpose (e.g. non-escaped string literals)” ?


I cannot speak for them, but I think that if we want to get a feel about
which alternatives get the most traction, I think all alternatives should
be considered, including yours and mine.  :-)


Got it :-)





That is why I suggested a rare combination using the @" and "@ as the
delimiters. Unless your text is Obj-C code it would be rare to find it.



I don’t think we need to worry about the opening quote occurring in the
text because we just need the closing delimiter to find out where it ends.
 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 ?






And what do you suggest to do if we *have* `"@` inside the text we want
to use ?





On May 11, 2016, at 10:50 AM, Vladimir.S via swift-evolution
mailto:swift-evolution@swift.org>> wrote:

Did I miss the proposal for single quote?

Just found on
https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md





-<

Single-quotes '' for Character literals: Swift takes the approach of
highly valuing Unicode. However, there are multiple concepts of a
character that could make sense in Unicode, and none is so much more
commonly used than the others that it makes sense to privilege them.
We'd rather save single quoted literals for a greater purpose (e.g.
non-escaped string literals).

-<


So, what about using of single quote as "special" strings?

For example, I'd propose to use single quote quotation to say "this
string should be used as-is, no escapes processing"

'some 1\total\\2\\\3 "sdfsdf" \(-: """ helllooo'

the only 'disallowed' symbol could be the single quote itself, but I
propose the solution used in other languages - duplicate it if we need
it in string:

'this '' is a single quote in string, and this is another'''

and also in multiline strings:

assert( xml == ' ' ' '\(author) // note '' here in
string 'XML Developer''s Guide '
Computer '44.95 '
2000-10-01 'An
in-depth look at XML. ' '')

(also needs to duplicate single quote if in text. the compromise,
yes.)


On 10.05.2016 9:53, John Holdsworth via swift-evolution wrote: I’ve
assembled a gist to summarise the main proposals of this thread.

https://gist.github.com/johnno1962/5c325a16838ad3c73e0f109a514298bf

At the moment there seem to be four proposals for multi-line
strings:

1) Bent’s proposal for continuation quotes where if a conventional
string does not close, if the first non-whitespace character of the
next line is “ (or perhaps |) the string is continued. This gives
you precise control over exactly what is in the string.

2) Tyler's original proposal involving strings that can contain
newlines delimited “””like this“”” as they are in python or, _”like
this“_. This works well in external editors and on github.
Indentation is catered for by stripping any whitespace before the
closing quote from all lines in the string.

3) HEREDOC syntax <<“TAG” or <<‘TAG’ taken from languages like Perl
subject to the same indentation removal rules as “””strings”””
above. This has the advantage that the literal is clearly separated
from your code.

4) Heck it all, why not all three syntaxes or some combination.

(There is a separate feature that all string literals can be
prefixed by e as in e”\w\d+” to turn of all escape processing for
another day)

While the Swift Lexer could easily accommodate all these syntaxes
there was talk early on that Swift has more of a "one way, maximally
elegant” ethos and indeed I find it difficult imagine the Swift Book
breathlessly describing all three formats so I’m wondering if push
came to shove which format people would chose?

My vote having undergone a "road to damascus" moment now we know it
is available sooner rather than later is.. HEREDOC! It’s well
understood and while 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0041: Updating Protocol Naming Conventions for Conversions

[Erica Sadun via swift-evolution]

> On May 11, 2016, at 7:29 AM, Matthew Johnson  wrote:
>> 
>> We'd be happy to bikeshed again.
>> 
>> I think fundamentally our take on this is:
>> 
>> * We want there to be a standard that expresses the three 
>> conversion/initialization styles.
>> * We feel the system is currently broken. And we want to have a coherent and 
>> settled vision in place for 3, even imperfect.
>> * We're flexible about the naming but it should be (1) Swifty and (2) well 
>> grounded in meaning.
>> 
>> Let me turn the floor over to Matthew here.
> 
> I agree with Erica here.  
> 
> There was a significant round of bike shedding that went into this proposal a 
> few months ago, but there is no harm in continuing that exercise now that a 
> broader audience is engaged.  As many reviewers have agreed, the important 
> thing is to settle on *something*.
> 
> Several reviewers have mentioned Creatable as not feeling Swifty.  FWIW, the 
> history behind the name is that we wanted something that will work regardless 
> of the mechanism.  It should be a sensible name whether the requirement is an 
> initializer or a factory method.
> 
> I'm hoping we can reach a convention that most of us are happy with by the 
> end of the review period.  

If anyone wants to look back at the original discussion, you can find it here:

http://thread.gmane.org/gmane.comp.lang.swift.evolution/10883 


-- E

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

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] Change `repeat` to loop indefinitely if no while clause is present

[Nicholas Maccharoli via swift-evolution]

Yeah after going though this thread again modifying the repeat keyword
seems like overkill.

while true { } isn't broken but I really like Ruby's loop { ... } keyword.

but adding a new loop type to swift just for replacing a special case of
the while loop also seems like a little too much.

If there isn't a strong argument for adding a loop keyword then I guess
this thread is at it's end for now.

Thanks for the feedback!

- Nick


2016年5月12日木曜日、Chris Lattner via swift-evolutionさんは書きました:

>
> > On May 10, 2016, at 6:11 PM, Tyler Cloutier  > wrote:
> >
> >
> >> On May 10, 2016, at 5:56 PM, Chris Lattner  > wrote:
> >>
> >>
> >>> On May 10, 2016, at 4:13 PM, Cole Campbell via swift-evolution <
> swift-evolution@swift.org > wrote:
> >>>
> >>> I agree that repeat { } is ambiguous because you have to look to the
> end for a while clause to determine if it's infinite or not.
> >>
> >> Right, this is the downside that I see with “repeat {}”.
> >
> >
> > Not to beat a dead horse, but isn’t this also true of
> >
> > repeat { ...
>
> > while true { …
>
> No, because today you always know that repeat has a condition, and that
> while does not.  That’s the point.
>
>
> >> Another option is to make it a statement modifier, which wouldn’t
> require taking it as a keyword (but also doesn’t read as well):
> >>
> >> forever repeat { }
> >>
> >>
> >> Personally, I don’t see this as a big enough improvement over “while
> true” to be worth introducing complexity for.
> >>
> >
> > If you are referring to “forever", I also don’t think that adding a new
> keyword is an improvement over “while true”.
>
> I agree.  Even if it didn’t take a keyword, Idon’t think that “repeat
> forever” is worth adding over “while true”.
>
> -Chris
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution
>


-- 

All the best,

Nicholas

Linked in:
http://lnkd.in/328U22
___
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]

(By the way, I re-read the quoted part of your message, and I realized the
question I posed sounded like a rhetorical question. That wasn't my intent.
I'm sorry about that, and I appreciate you explaining why non-contiguous
data buffers have been important for certain use cases.)

Austin

On Wed, May 11, 2016 at 10:47 AM, Austin Zheng 
wrote:

> This is good to know, thanks! I will look into dispatch_data_t's
> implementation more closely; I didn't know it was bridged to NSData.
>
> I completely agree that if there are no requirements for a contiguous
> buffer, then there should be no requirement to implement a Data object as a
> contiguous buffer. There is nothing about the Collection abstraction that
> requires a contiguous buffer, anyways.
>
> Austin
>
> On Wed, May 11, 2016 at 10:33 AM, Zach Waldowski via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> On Wed, May 11, 2016, at 11:38 AM, Austin Zheng via swift-evolution wrote:
>>
>> One question that this brings up is whether supporting non-contiguous
>> data regions in a native Swift data type is worth the complexity costs.
>> There are good reasons for dispatch_data_t to be implemented the way it is,
>> but NSData has always assumed that it is modeling a contiguous area in
>> memory, and it provides users with raw access to the underlying buffer. A
>> cursory examination of a few other languages (Java, Python, Haskell) show
>> that these languages all model binary data as some sort of contiguous
>> array-like construct containing bytes.
>>
>>
>> I do not find this convincing.
>>
>> NSData has not "always assumed" this; that it is transparently bridged
>> with dispatch_data_t on Darwin contradicts that directly.
>>
>> It would be prohibitive on efficiency to have to use the
>> lowest-common-denominator of contiguous bytes to be useful in Swift. XPC
>> and NSURLSession, among others, both use dispatch_data_t via NSData to
>> efficiently push large buffers across process boundaries.
>>
>> That there are complexities involved should not be reason to not address
>> them. It's 2016 and we don't always deal with buffers of a conveniently
>> small size, just like we don't deal with Strings that are conveniently
>> UTF-8. If sufficiently small buffers are the only thing being addressed for
>> ease, then I don't find the described API that much more valuable than
>> [UInt8] and UnsafeBufferPointer.
>>
>> Another language having represented it a certain way does not make it
>> foregone how Swift must do it. Other languages also lack value types,
>> Unicode-correct strings, or memory safety. Swift is living proof that doing
>> things the way C or Java did is not the automatic solution.
>>
>> Zachary Waldowski
>> z...@waldowski.me
>>
>>
>> ___
>> 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) Add last(where:) and lastIndex(where:) methods

[Nate Cook via swift-evolution]

> On May 11, 2016, at 12:32 PM, Hooman Mehr via swift-evolution 
>  wrote:
> 
> Thank you for your comments. 
> 
> I think additional index manipulation and collection scanning API is needed, 
> and your proposal cover an important part of it.
> 
> I also have some clarifications and comments inline:
> 
>>> On May 10, 2016, at 4:52 PM, Nate Cook  wrote:
>>> Thanks Hooman! Those do look like useful extensions. I think the proposal 
>>> should stay focused on the APIs it includes already.
>>> On May 10, 2016, at 4:18 PM, Hooman Mehr  wrote:
>>> public func offset(of index: Index) -> IndexDistance
>>> public func index(atOffset offset: IndexDistance) -> Index
>> 
>> I like these, but I doubt they would get much traction, since they're 
>> essentially substituting startIndex into existing methods. I have thought it 
>> would be nice to have startIndex as the default parameter to those methods, 
>> though, so you could write either of these:
>> 
>>  let i = c.index(c.startIndex, offsetBy: 5)  // current
>>  let i = c.index(offsetBy: 5)// nice addition
> 
> That is right. The main function is `offset` that I use a lot and for the 
> reverse, your suggestion seems better. I am using `offset` quite a bit but I 
> don’t know if it is generally as useful for other people as it is for me.

'distance(from:to:)' is the corresponding method to your 'offset(of:)', 
although it might need a different name if the first parameter were optional. I 
don't find it onerous to provide c.startIndex when using that one.

>>> public func index(of element: Iterator.Element, from firstIndex: Index) -> 
>>> Index?
>>> public func index(from firstIndex: Index, where predicate: @noescape 
>>> (Iterator.Element) throws -> Bool) rethrows -> Index?
>> 
>> I have the same reaction to these. Because indices are shared between 
>> collections and slices, instead of using a starting index, Swift's 
>> collection operations can just work on a slice. So instead of calling
>> 
>>  let i = c.index(of: "A", from: firstIndex)
>> 
>> you can call
>> 
>>  let i = c.suffix(from: firstIndex).index(of: "A”)
> 
> The point is: The `i` above is an index into the (discarded) slice returned 
> by `suffix()`, not the collection `c`. In general, it does not work correctly 
> on the original collection. The behavior of slice indexes have changed a 
> couple of times and is not totally consistent or guaranteed for different 
> concrete collections. That is the reason I am proposing the above function to 
> provide a sure way to have this functionality working properly and I find it 
> extremely useful. Again I don’t know about others.
> 
> It seems that the subject of the interaction between slice indexes and the 
> parent collections need further clarifications and specification from the 
> core Swift team.

Indices from slices absolutely should reference the same element(s) in the 
original collection―the collections system is based in part on that 
interoperability. If you see any behavior that deviates from this, please file 
a bug!

>>> public func index(of elementSequence: C) -> Index?
>>> public func index(of elementSequence: C, from 
>>> firstIndex: Index) -> Index?
>> 
>> These methods we don't have at all currently, and could really use! I would 
>> definitely support a proposal for finding a subsequence of a collection. 
>> There are several algorithms beyond the naive approach, so it would be 
>> interesting to see if / how a proposal could use those in a generic context.
> 
> I updated the gist. Besides some corrections and removing a couple of 
> extension constraints, I merged the two functions above into:
> 
> public func index(of elementSequence: C, from 
> firstIndex: Index? = nil) -> Index?
> 
> I think the basic implementation in the gist is good enough for many cases 
> and we can specialize for array. As long as the collection and the 
> sub-collection are not huge, performance should be fine.
> 
> On the other hand, I am too busy to seriously propose and pursue its 
> addition. If enough people find it worthy of general inclusion into the 
> standard library, somebody will pick it up, but not me.
> 
> I didn’t intend to hijack your proposal, but I thought some comments would 
> help clarify things.
> 
> Thank you again,
> Hooman

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

Re: [swift-evolution] [proposal] Allow "let" for computed properties which only reference immutable data

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On May 11, 2016, at 1:02 PM, Haravikk  wrote:
> 
> 
>>> On 11 May 2016, at 18:00, Joe Groff via swift-evolution 
>>>  wrote:
 On May 11, 2016, at 8:34 AM, Matthew Johnson via swift-evolution 
  wrote:
 On May 11, 2016, at 10:26 AM, Sean Heber via swift-evolution 
  wrote:
 
 I kind of agree with the logic of that, but imagine the following:
 
 class Test {
 let hello = “hello”
 var subject = “world”
 var phrase: String { return hello + “, “ + subject }
 }
 
 In this scenario, “subject” can be changed.. and that changes the result 
 of “phrase”. Things like this are why computed properties are “var”.
>>> 
>>> This example would still be required to be var because it accesses a var in 
>>> its implementation.
>>> 
>>> I like the idea of allowing this feature, but only in cases where the 
>>> compiler can verify immutable semantics.  Having it may help drive other 
>>> features that could expand the cases the compiler can verify.  That would 
>>> be great as this is a direction I would like to see Swift take in the 
>>> future.
>> 
>> Yeah, this is why we don't currently allow computed "let" properties. We'd 
>> only want to do so once we have the language facilities to ensure a computed 
>> 'let' property is immutable and has no observable side effects.
> 
> 
> Even if a “computed” property were immutable, do we really want to implicitly 
> make it a constant as well? Take for example:
> 
> class Test {
> let a:[Int64]
> let b:[Int64]
> 
> init(_ value:Int64) {
> self.a = Array(count: 65536, repeatedValue: Int64(value))
> self.b = Array(count: 65536, repeatedValue: Int64(value &+ 1))
> }
> 
> var combined:[Int64] { return a + b }
> }
> 
> Each of these arrays is 512kb, so storing a fixed value for the combined 
> property would require another megabyte of space per instance of Test, but if 
> the combined property is only infrequently called on some instances of Test, 
> then it would be a waste of memory to precompute it, especially if you’re 
> dealing with thousands of instances, with only a fraction of them calling the 
> computed property. If you want to accelerate usage of the computed property 
> then that’s what lazy variables are for, as you can delay the expensive 
> combination until you actually need it.
> 
> The problem really is that the compiler can only do limited analysis about 
> whether a computer property is used a lot, and in most cases it doesn’t care 
> (it only really cares whether something is unused, as it can try to optimise 
> it away), to make a good decision it would need to run the program with a 
> realistic test-case an analysis memory overhead and performance impact of 
> each method.
> 
> So yeah, I’m not really sure of the advantage of this, unless the intention 
> is purely to restrict what can be used within your computed property’s 
> implementation, but I don’t think the compiler can realistically do much in 
> the way of optimising stuff away as precomputed values need to be stored 
> somewhere, which could mean making your type bigger, which begs the question 
> of why you specified a computed value in the first place.
> 
> I guess I’m just confused as to what the problem being solved would really be.

It provides semantic clarity in the API contract.  If you look at the property 
now and then look at it again at some point in the future you will get the same 
value back.  'var { get }' does not allow for that.  I imagine we would be able 
to specify 'let' protocol requirements as well which could be implement with 
either stored or computed 'let' properties.___
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

[Darren Mo via swift-evolution]

Great, this is the libdispatch API that I’ve been dreaming about! I think it 
meshes well with the rest of Swift.

I am concerned about one thing though: the naming of the DispatchGroup methods 
synchronously/asynchronously.

They are hard to type correctly and ugly to look at.
sync/async are already well-established abbreviations in the tech industry.
They are adjectives without verbs, which goes against the API Design Guidelines.

I suggest sticking with the naming from the C API. For example:

let queue = …
queue.dispatchAsync {
  …
}

Cheers,
Darren

> 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

Re: [swift-evolution] [Pitch] merge types and protocols back together with type

[Adrian Zubarev via swift-evolution]

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

Re: [swift-evolution] multi-line string literals.

[Ricardo Parada via swift-evolution]

> On May 11, 2016, at 12:55 PM, Vladimir.S  wrote:
> 
> 
> On 11.05.2016 19:38, Ricardo Parada wrote:
>> I did not suggest the single quote because it is commonly found in the
>> English language and we would have to escape it.
> 
> Wel.. in your document you have a number of variants of multi-line 'feature' 
> implementations with different pros/cons for each.

I don’t have a document.  I’ve seen different proposals.  
I have just been commenting on the proposals in this thread.

> Could you clarify, why this proposal with single quote can not be inside your 
> document as just another variant with its own pros/cons ? Especially, as you 
> can see, if "We'd rather save single quoted literals for a greater purpose 
> (e.g. non-escaped string literals)” ?

I cannot speak for them, but I think that if we want to get a feel about which 
alternatives get the most traction, I think all alternatives should be 
considered, including yours and mine.  :-)

>> 
>> That is why I suggested a rare combination using the @" and "@ as the
>> delimiters. Unless your text is Obj-C code it would be rare to find it.
>> 

I don’t think we need to worry about the opening quote occurring in the text 
because we just need the closing delimiter to find out where it ends.  For 
example:


let sourceCode = @“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,


> 
> And what do you suggest to do if we *have* `"@` inside the text we want to 
> use ?
> 
>> 
>> 
>>> On May 11, 2016, at 10:50 AM, Vladimir.S via swift-evolution
>>>  wrote:
>>> 
>>> Did I miss the proposal for single quote?
>>> 
>>> Just found on
>>> https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md
 
>>> 
> -<
>>> Single-quotes '' for Character literals: Swift takes the approach of
>>> highly valuing Unicode. However, there are multiple concepts of a
>>> character that could make sense in Unicode, and none is so much more
>>> commonly used than the others that it makes sense to privilege them.
>>> We'd rather save single quoted literals for a greater purpose (e.g.
>>> non-escaped string literals).
 -<
>>> 
>>> So, what about using of single quote as "special" strings?
>>> 
>>> For example, I'd propose to use single quote quotation to say "this
>>> string should be used as-is, no escapes processing"
>>> 
>>> 'some 1\total\\2\\\3 "sdfsdf" \(-: """ helllooo'
>>> 
>>> the only 'disallowed' symbol could be the single quote itself, but I
>>> propose the solution used in other languages - duplicate it if we need
>>> it in string:
>>> 
>>> 'this '' is a single quote in string, and this is another'''
>>> 
>>> and also in multiline strings:
>>> 
>>> assert( xml == ' ' '>> empty=""> '\(author) // note '' here in
>>> string 'XML Developer''s Guide '
>>> Computer '44.95 '
>>> 2000-10-01 'An
>>> in-depth look at XML. ' '')
>>> 
>>> (also needs to duplicate single quote if in text. the compromise,
>>> yes.)
>>> 
 On 10.05.2016 9:53, John Holdsworth via swift-evolution wrote: I’ve
 assembled a gist to summarise the main proposals of this thread.
 
 https://gist.github.com/johnno1962/5c325a16838ad3c73e0f109a514298bf
 
 At the moment there seem to be four proposals for multi-line
 strings:
 
 1) Bent’s proposal for continuation quotes where if a conventional
 string does not close, if the first non-whitespace character of the
 next line is “ (or perhaps |) the string is continued. This gives
 you precise control over exactly what is in the string.
 
 2) Tyler's original proposal involving strings that can contain
 newlines delimited “””like this“”” as they are in python or, _”like
 this“_. This works well in external editors and on github.
 Indentation is catered for by stripping any whitespace before the
 closing quote from all lines in the string.
 
 3) HEREDOC syntax <<“TAG” or <<‘TAG’ taken from languages like Perl
 subject to the same indentation removal rules as “””strings”””
 above. This has the advantage that the literal is clearly separated
 from your code.
 
 4) Heck it all, why not all three syntaxes or some combination.
 
 (There is a separate feature that all string literals can be
 prefixed by e as in e”\w\d+” to turn of all escape processing for
 another day)
 
 While the Swift Lexer could easily accommodate all these syntaxes
 there was talk early on that Swift has more of a "one way, maximally
 elegant” ethos and indeed I find it difficult imagine the Swift Book
 breathlessly describing all three formats so I’m wondering if push
 came to shove which format people would chose?
 
 My vote having undergone a "road to damascu

Re: [swift-evolution] [proposal] Allow function argument type to be omitted when passing a default value from which it can be inferred

[Chris Lattner via swift-evolution]

> On May 11, 2016, at 5:49 AM, Vladimir.S via swift-evolution 
>  wrote:
> 
> Inline
> 
> On 11.05.2016 15:09, Thorsten Seitz via swift-evolution wrote:
>> Am 11. Mai 2016 um 05:33 schrieb Chris Lattner via swift-evolution
>> :
>> 
>>> On May 10, 2016, at 3:02 AM, Sam Dods via swift-evolution
>>>  wrote:
 I propose that function argument types could be omitted in the same way
 as variable and property argument types are omitted when they are set at
 point of definition.
 [...]
>>> 
>>> We have a pretty strict rule here: types are allowed to be inferred in
>>> implementations, but not interfaces. This is important for efficient
>>> compilation, encourages people to think about their API interfaces, and
>>> somewhat reduces the damage when they don’t.
>> 
>> +1
> 
> Sorry, but this("We have a pretty strict rule") seems just like not true. The 
> rule is broken as you can see (so not such a 'strict') :

Yes, I’m aware of that, that’s why I used the waffly word “pretty” :-)

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

Re: [swift-evolution] [proposal] Allow "let" for computed properties which only reference immutable data

[Haravikk via swift-evolution]

> On 11 May 2016, at 18:00, Joe Groff via swift-evolution 
>  wrote:
>> On May 11, 2016, at 8:34 AM, Matthew Johnson via swift-evolution 
>>  wrote:
>>> On May 11, 2016, at 10:26 AM, Sean Heber via swift-evolution 
>>>  wrote:
>>> 
>>> I kind of agree with the logic of that, but imagine the following:
>>> 
>>> class Test {
>>> let hello = “hello”
>>> var subject = “world”
>>> var phrase: String { return hello + “, “ + subject }
>>> }
>>> 
>>> In this scenario, “subject” can be changed.. and that changes the result of 
>>> “phrase”. Things like this are why computed properties are “var”.
>> 
>> This example would still be required to be var because it accesses a var in 
>> its implementation.
>> 
>> I like the idea of allowing this feature, but only in cases where the 
>> compiler can verify immutable semantics.  Having it may help drive other 
>> features that could expand the cases the compiler can verify.  That would be 
>> great as this is a direction I would like to see Swift take in the future.
> 
> Yeah, this is why we don't currently allow computed "let" properties. We'd 
> only want to do so once we have the language facilities to ensure a computed 
> 'let' property is immutable and has no observable side effects.


Even if a “computed” property were immutable, do we really want to implicitly 
make it a constant as well? Take for example:

class Test {
let a:[Int64]
let b:[Int64]

init(_ value:Int64) {
self.a = Array(count: 65536, repeatedValue: Int64(value))
self.b = Array(count: 65536, repeatedValue: Int64(value &+ 1))
}

var combined:[Int64] { return a + b }
}

Each of these arrays is 512kb, so storing a fixed value for the combined 
property would require another megabyte of space per instance of Test, but if 
the combined property is only infrequently called on some instances of Test, 
then it would be a waste of memory to precompute it, especially if you’re 
dealing with thousands of instances, with only a fraction of them calling the 
computed property. If you want to accelerate usage of the computed property 
then that’s what lazy variables are for, as you can delay the expensive 
combination until you actually need it.

The problem really is that the compiler can only do limited analysis about 
whether a computer property is used a lot, and in most cases it doesn’t care 
(it only really cares whether something is unused, as it can try to optimise it 
away), to make a good decision it would need to run the program with a 
realistic test-case an analysis memory overhead and performance impact of each 
method.

So yeah, I’m not really sure of the advantage of this, unless the intention is 
purely to restrict what can be used within your computed property’s 
implementation, but I don’t think the compiler can realistically do much in the 
way of optimising stuff away as precomputed values need to be stored somewhere, 
which could mean making your type bigger, which begs the question of why you 
specified a computed value in the first place.

I guess I’m just confused as to what the problem being solved would really be.___
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

[Dmitri Gribenko via swift-evolution]

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

Re: [swift-evolution] [Pitch] Constrains for numeric types: Int<1...10> Double<0.0...1.0>

[Adrian Zubarev via swift-evolution]

Okay I’m fine with that for now. If you’d have to decide on some syntax for 
such a future, how would it look like? I’m just curious.

I tend to square brackets Double[0.0 … 1.0], because otherwise it might look 
like a generic type, but I’m not sure if this type refinement could be applied 
to other types as well so we actually would stick to the generic type syntax 
here Float<-1.0 … 1.0>.

-- 
Adrian Zubarev
Sent with Airmail

Am 11. Mai 2016 bei 19:54:09, Matthew Johnson (matt...@anandabits.com) schrieb:

This is called a refinement type.  It would be cool to explore that direction 
in the future but it is definitely well out of scope for Swift 3.

Sent from my iPad

On May 11, 2016, at 12:45 PM, Adrian Zubarev via swift-evolution 
 wrote:

Hello Swift community. I'd like to discuss with you if we need something like 
this in Swift 3 or any future Swift version.

As you may know there is no way to constrain a numeric type expect for some 
scope internal assertion or precodintions which may produce a runtime error if 
the input value is out of the defined bound.

func foo(value: Int) {
assert(value > 0 && value <= 10)

// passed
}

How would it be if Swift would allow us to constraint numeric typs with 
ranges/intervals?

func newFoo(value: Int<1...10>) {
// no need for an assertion any more
}

We could go even further and add more then one range/interval:

func someFoo(value: Int<0...20, 40...60>) { /* do some work */ }

Not only integers should have this ability but also floating point types like 
Double and Float. 

Alternative form might look like this:

Double[1.0...10.0]
Float[0.0...1.0, 10.0...100.0]

One downside of half opened ranges/intervals is the left side of its set. How 
do we exclude the left element?

1...10 means 1..<11 equals [1, 11)

But how can we create something like (0.0, 1.0), do we need a strange looking 
binary operator 0.0>..<1.0?

What do you think? I'd love to hear any feedback to this.

-- 
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] Change `repeat` to loop indefinitely if no while clause is present

[Chris Lattner via swift-evolution]

> On May 10, 2016, at 6:11 PM, Tyler Cloutier  wrote:
> 
> 
>> On May 10, 2016, at 5:56 PM, Chris Lattner  wrote:
>> 
>> 
>>> On May 10, 2016, at 4:13 PM, Cole Campbell via swift-evolution 
>>>  wrote:
>>> 
>>> I agree that repeat { } is ambiguous because you have to look to the end 
>>> for a while clause to determine if it's infinite or not.
>> 
>> Right, this is the downside that I see with “repeat {}”.
> 
> 
> Not to beat a dead horse, but isn’t this also true of 
> 
> repeat { ...

> while true { …

No, because today you always know that repeat has a condition, and that while 
does not.  That’s the point.


>> Another option is to make it a statement modifier, which wouldn’t require 
>> taking it as a keyword (but also doesn’t read as well):
>> 
>> forever repeat { }
>> 
>> 
>> Personally, I don’t see this as a big enough improvement over “while true” 
>> to be worth introducing complexity for. 
>> 
> 
> If you are referring to “forever", I also don’t think that adding a new 
> keyword is an improvement over “while true”.

I agree.  Even if it didn’t take a keyword, Idon’t think that “repeat forever” 
is worth adding over “while true”.

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

[Guillaume Lessard via swift-evolution]

> * What is your evaluation of the proposal?

I like it; with the fixes already mentioned by Matt, I have some extra comments 
and questions:

- It would be nicer to use the Dispatch namespace, rather than prefix 
everything.
- It seems unfortunate to have 11 DispatchSourceSUBTYPE protocols at top level.

- DispatchQueue initialization is only implied; its initializer(s) should be 
described

- dispatch_queue_get_qos_class and dispatch_set_target_queue are not mentioned.
- dispatch_after and dispatch_apply aren’t mentioned either.

- dispatch_suspend and dispatch_resume; would these be available on 
DispatchObject or just some of its subclasses?

- dispatch_set_context, dispatch_get_context, and dispatch_set_finalizer; do 
those stay or disappear?

- please describe the api related to dispatch_io_t


Other comments:

- Queue.{synchronously,asynchronously} are odd names for Swift. Since the 
labels include a verb, I feel they’re fine, though.
The suggestion of `dispatchSynchronously` is too long; `dispatchSync` is not 
better than the adverb; just `sync` is unclear (the verb would be synchronize, 
which is wrong.)


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

Yes. Using libdispatch with the old api is okay, but weird.

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

Mostly; I’m sure it will after the feedback.

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

I’ve been a libdispatch user in Swift since the beginning: I’ve formed 
opinions. I read the proposal carefully.

Guillaume Lessard

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

This is good to know, thanks! I will look into dispatch_data_t's
implementation more closely; I didn't know it was bridged to NSData.

I completely agree that if there are no requirements for a contiguous
buffer, then there should be no requirement to implement a Data object as a
contiguous buffer. There is nothing about the Collection abstraction that
requires a contiguous buffer, anyways.

Austin

On Wed, May 11, 2016 at 10:33 AM, Zach Waldowski via swift-evolution <
swift-evolution@swift.org> wrote:

> On Wed, May 11, 2016, at 11:38 AM, Austin Zheng via swift-evolution wrote:
>
> One question that this brings up is whether supporting non-contiguous data
> regions in a native Swift data type is worth the complexity costs. There
> are good reasons for dispatch_data_t to be implemented the way it is, but
> NSData has always assumed that it is modeling a contiguous area in memory,
> and it provides users with raw access to the underlying buffer. A cursory
> examination of a few other languages (Java, Python, Haskell) show that
> these languages all model binary data as some sort of contiguous array-like
> construct containing bytes.
>
>
> I do not find this convincing.
>
> NSData has not "always assumed" this; that it is transparently bridged
> with dispatch_data_t on Darwin contradicts that directly.
>
> It would be prohibitive on efficiency to have to use the
> lowest-common-denominator of contiguous bytes to be useful in Swift. XPC
> and NSURLSession, among others, both use dispatch_data_t via NSData to
> efficiently push large buffers across process boundaries.
>
> That there are complexities involved should not be reason to not address
> them. It's 2016 and we don't always deal with buffers of a conveniently
> small size, just like we don't deal with Strings that are conveniently
> UTF-8. If sufficiently small buffers are the only thing being addressed for
> ease, then I don't find the described API that much more valuable than
> [UInt8] and UnsafeBufferPointer.
>
> Another language having represented it a certain way does not make it
> foregone how Swift must do it. Other languages also lack value types,
> Unicode-correct strings, or memory safety. Swift is living proof that doing
> things the way C or Java did is not the automatic solution.
>
> Zachary Waldowski
> z...@waldowski.me
>
>
> ___
> 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] [Pitch] Constrains for numeric types: Int<1...10> Double<0.0...1.0>

[Adrian Zubarev via swift-evolution]

Hello Swift community. I'd like to discuss with you if we need something like 
this in Swift 3 or any future Swift version.

As you may know there is no way to constrain a numeric type expect for some 
scope internal assertion or precodintions which may produce a runtime error if 
the input value is out of the defined bound.

func foo(value: Int) {

assert(value > 0 && value <= 10)

// passed
}

How would it be if Swift would allow us to constraint numeric typs with 
ranges/intervals?

func newFoo(value: Int<1...10>) {

// no need for an assertion any more
}

We could go even further and add more then one range/interval:

func someFoo(value: Int<0...20, 40...60>) { /* do some work */ }

Not only integers should have this ability but also floating point types like 
Double and Float. 

Alternative form might look like this:

Double[1.0...10.0]
Float[0.0...1.0, 10.0...100.0]

One downside of half opened ranges/intervals is the left side of its set. How 
do we exclude the left element?

1...10 means 1..<11 equals [1, 11)

But how can we create something like (0.0, 1.0), do we need a strange looking 
binary operator 0.0>..<1.0?

What do you think? I'd love to hear any feedback to this.

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

[swift-evolution] Why can't protocols define constants or subtypes?

[Charles Srstka via swift-evolution]

With a class or a struct, I can nest constants and subtypes within the type, 
like so:

class MyWidget {
static let SomeConstant = “This string is useful to subclasses of 
MyWidget somehow"

enum Type {
case Cog
case Sprocket
}

enum Error {
case SomethingWentWrong
case SomethingElseWentWrong
}

var type: Self.Type // This doesn’t work yet, but it should after 
SE-0068 is implemented

func doSomething() throws // might throw one of the errors above
}

This is nice for namespacing, and it makes the code clear and organized.

However, if I convert this to a protocol-based approach, I have to do this the 
old Objective-C way:

static let MyWidgetSomeConstant = “This string is useful to implementers of 
MyWidget somehow"

enum MyWidgetType {
case Cog
case Sprocket
}

enum MyWidgetError {
case SomethingWentWrong
case SomethingElseWentWrong
}

protocol MyWidget {
var type: MyWidgetType

func doSomething() throws // might throw one of the errors above
}

This is ugly, and pollutes the global namespace with things that are only 
interesting to users and implementers of MyWidget. Is there a reason behind 
this? It seems that it could be useful to define constants and subtypes that 
could be useful for implementers of a protocol.

Charles

___
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

[Zach Waldowski via swift-evolution]

On Wed, May 11, 2016, at 11:38 AM, Austin Zheng via swift-evolution wrote:
> One question that this brings up is whether supporting non-contiguous
> data regions in a native Swift data type is worth the complexity
> costs. There are good reasons for dispatch_data_t to be implemented
> the way it is, but NSData has always assumed that it is modeling a
> contiguous area in memory, and it provides users with raw access to
> the underlying buffer. A cursory examination of a few other languages
> (Java, Python, Haskell) show that these languages all model binary
> data as some sort of contiguous array-like construct containing bytes.
 
I do not find this convincing.
 
NSData has not "always assumed" this; that it is transparently bridged
with dispatch_data_t on Darwin contradicts that directly.
 
It would be prohibitive on efficiency to have to use the lowest-common-
denominator of contiguous bytes to be useful in Swift. XPC and
NSURLSession, among others, both use dispatch_data_t via NSData to
efficiently push large buffers across process boundaries.
 
That there are complexities involved should not be reason to not address
them. It's 2016 and we don't always deal with buffers of a conveniently
small size, just like we don't deal with Strings that are conveniently
UTF-8. If sufficiently small buffers are the only thing being addressed
for ease, then I don't find the described API that much more valuable
than [UInt8] and UnsafeBufferPointer.
 
Another language having represented it a certain way does not make it
foregone how Swift must do it. Other languages also lack value types,
Unicode-correct strings, or memory safety. Swift is living proof that
doing things the way C or Java did is not the automatic solution.
 
Zachary Waldowski
z...@waldowski.me
 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] (Draft) Add last(where:) and lastIndex(where:) methods

[Hooman Mehr via swift-evolution]

Thank you for your comments. 

I think additional index manipulation and collection scanning API is needed, 
and your proposal cover an important part of it.

I also have some clarifications and comments inline:

> On May 10, 2016, at 4:52 PM, Nate Cook  wrote:
> Thanks Hooman! Those do look like useful extensions. I think the proposal 
> should stay focused on the APIs it includes already.
>> On May 10, 2016, at 4:18 PM, Hooman Mehr > > wrote:
>> public func offset(of index: Index) -> IndexDistance
>> public func index(atOffset offset: IndexDistance) -> Index
> 
> I like these, but I doubt they would get much traction, since they're 
> essentially substituting startIndex into existing methods. I have thought it 
> would be nice to have startIndex as the default parameter to those methods, 
> though, so you could write either of these:
> 
>   let i = c.index(c.startIndex, offsetBy: 5)  // current
>   let i = c.index(offsetBy: 5)// nice addition

That is right. The main function is `offset` that I use a lot and for the 
reverse, your suggestion seems better. I am using `offset` quite a bit but I 
don’t know if it is generally as useful for other people as it is for me.

> 
>> public func index(of element: Iterator.Element, from firstIndex: Index) -> 
>> Index?
>> public func index(from firstIndex: Index, where predicate: @noescape 
>> (Iterator.Element) throws -> Bool) rethrows -> Index?
> 
> I have the same reaction to these. Because indices are shared between 
> collections and slices, instead of using a starting index, Swift's collection 
> operations can just work on a slice. So instead of calling
> 
>   let i = c.index(of: "A", from: firstIndex)
> 
> you can call
> 
>   let i = c.suffix(from: firstIndex).index(of: "A”)

The point is: The `i` above is an index into the (discarded) slice returned by 
`suffix()`, not the collection `c`. In general, it does not work correctly on 
the original collection. The behavior of slice indexes have changed a couple of 
times and is not totally consistent or guaranteed for different concrete 
collections. That is the reason I am proposing the above function to provide a 
sure way to have this functionality working properly and I find it extremely 
useful. Again I don’t know about others.

It seems that the subject of the interaction between slice indexes and the 
parent collections need further clarifications and specification from the core 
Swift team.

> 
>> public func index(of elementSequence: C) -> Index?
>> public func index(of elementSequence: C, from 
>> firstIndex: Index) -> Index?
> 
> These methods we don't have at all currently, and could really use! I would 
> definitely support a proposal for finding a subsequence of a collection. 
> There are several algorithms beyond the naive approach, so it would be 
> interesting to see if / how a proposal could use those in a generic context.
> 

I updated the gist 
. Besides some 
corrections and removing a couple of extension constraints, I merged the two 
functions above into:

public func index(of elementSequence: C, from 
firstIndex: Index? = nil) -> Index?

I think the basic implementation in the gist is good enough for many cases and 
we can specialize for array. As long as the collection and the sub-collection 
are not huge, performance should be fine.

On the other hand, I am too busy to seriously propose and pursue its addition. 
If enough people find it worthy of general inclusion into the standard library, 
somebody will pick it up, but not me.

I didn’t intend to hijack your proposal, but I thought some comments would help 
clarify things.

Thank you again,
Hooman


> Thanks again!
> Nate
> 
>> Look at the comments for the example usage. For `offset` function, see the 
>> source code for usage.
>> 
>> Hooman
>> 
>>> On May 10, 2016, at 11:54 AM, Nate Cook via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> I've needed these in the past and used them in other languages—any feedback 
>>> on this  idea?
>>> 
>>> Add last(where:) and lastIndex(where:) Methods to Bidirectional Collections
>>> The standard library should include methods for finding the last element of 
>>> a bidirectional collection that matches a predicate, along with the index 
>>> of that element.
>>> 
>>> Motivation
>>> The standard library currently has (or will soon have) methods that perform 
>>> a linear search from the beginning of a collection to find an element that 
>>> matches a predicate:
>>> 
>>> let a = [20, 30, 10, 40, 20, 30, 10, 40, 20]
>>> a.first(where: { $0 > 25 }) // 30
>>> a.index(of: 10) // 2
>>> a.index(where: { $0 > 25 }) // 1
>>> Unfortunately, there is no such method that searches from the end of a 
>>> bidirectional collection. Finding the last of particular kind of element 
>>> has multiple applications, parti

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

[Ricardo Parada via swift-evolution]

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

Re: [swift-evolution] NSRange and Range

[Zach Waldowski via swift-evolution]

That makes sense. However, wouldn't this still be workable in terms
of bridging? If UTF16Index had an alternate representation for Swift-
side UTF-8 storage, that wouldn't ever come up for roundtripping
across the bridge. The offsets that come back from Foundation would
always be "UTF-16 indices how NSString understands it", which Swift
would necessarily understand because it implements -characterAtIndex:
for the bridge wrapper.
 
Zach
 
On Wed, May 11, 2016, at 01:19 PM, Jordan Rose wrote:
> I’m not sure we’re going to stick to that in the future. It’s possible
> we’ll want String to support UTF-8 buffers as well.
>
> Jordan
>
>
>> On May 11, 2016, at 10:15, Zach Waldowski  wrote:
>>
>> Conceptually, yes, but is that not exactly how it is implemented?
>> https://github.com/apple/swift/blob/master/stdlib/public/core/StringUTF16.swift#L24
>>
>> Sincerely,
>> Zachary Waldowski
>> z...@waldowski.me
>>
>>
>> On Wed, May 11, 2016, at 01:13 PM, Jordan Rose wrote:
>>> That’s correct, but how would you *make* the String.UTF16Index
>>> values without the reference String? They’re not (guaranteed to be)
>>> integers.
>>>
>>> Jordan
>>>
>>>
 On May 10, 2016, at 16:04, Zach Waldowski 
 wrote:

 Right, I 100% get it. :) This is a difficult problem space, and I'm
 sure you folks are aware that that difficulty is also reflected in
 how brutal it is to use all of these derivative string-range-based
 things in Swift right now. In this case, having no answer to this
 problem is worse than not having the API at all — check Stack
 Overflow or GitHub for how often a "just paste this in"
 String.Index.init(_: Int) comes up.

 As far as NSTextCheckingResult goes, its ranges are always in the
 "indices" always in the space of the original string… do I have
 that right? So it would be programmer error to use those ranges in
 the wrong string just like it is with any Range
 today.

 Zach Waldowski


 On Tue, May 10, 2016, at 06:51 PM, Jordan Rose wrote:
> By the way, this doesn’t mean it can’t be done, or that we can’t
> decide on some kind of partial solution! It just means that it
> needs to be carefully considered and explicitly addressed.
>
> Jordan
>
>
>> On May 10, 2016, at 15:49, Jordan Rose 
>> wrote:
>>
>> We thought about that too. The problem is that it’s not always
>> obvious what NSString or NSAttributedString the indexes refer to.
>> For example, most of the NSRegularExpression APIs produce matches
>> in the form of NSTextCheckingResult, which then doesn’t have a
>> reference to the original string.
>>
>> Jordan
>>
>>
>>> On May 10, 2016, at 13:43, Zach Waldowski via swift-evolution
>>>  wrote:
>>>
>>> Would it be feasible to annotate those and have them
>>> appropriately converted to Range upon
>>> crossing the bridge? Thinking in particular of TextKit and
>>> friends — it'd away with quite a lot of the pain of, e.g., not
>>> having a native struct-y AttributedString.
>>>
>>> Cheers!
>>> Zachary Waldowski
>>> z...@waldowski.me
>>>
>>>
>>> On Tue, May 10, 2016, at 12:37 PM, Jordan Rose via swift-
>>> evolution wrote:
 One particular concern we've had is that many NSRanges aren’t
 Range; they’re Range. I suppose things
 wouldn’t get any *worse* there, though.

 Jordan


> On May 10, 2016, at 00:14, David Hart via swift-evolution  evolut...@swift.org> wrote:
>
> But it’s reasonably implementable? I guess the answer is yes
> if you have already faced the same bridging concerns with
> NSArray/Array. I’de really like this going forward, but I
> don’t know how confident I am in writing a proposal.
>
>> On 10 May 2016, at 08:29, Douglas Gregor 
>> wrote:
>>
>>
>>> On May 9, 2016, at 11:23 PM, David Hart 
>>> wrote:
>>>
>>> Why wouldn't it completely eliminate NSRange?
>>
>> Because NSRange has a different representation than
>> Range (start+length vs. start/end), a pointer-to-NSRange
>> has to come in as Unsafe(Mutable)Pointer rather than
>> Unsafe(Mutable)Pointer>. It’s the same reason that
>> (e.g.), an NSArray** parameter comes in as
>> UnsafeMutablePointer rather than
>> UnsafeMutablePointer<[AnyObject]>.
>>
>>> Are you thinking of NSNotFound? Could we migrate those APIs
>>> to return an Optional Range?
>>
>> If you had annotations on the APIs to say that they use
>> NSNotFound as a sentinel, yes.
>>
>> - Doug
>>
>>>
 On 10 May 2016, at 05:49, Douglas Gregor
  wrote:


> On May 8, 2016, at 2:10 PM, David Hart via swift-e

Re: [swift-evolution] [proposal] Allow function argument type to be omitted when passing a default value from which it can be inferred

[Jordan Rose via swift-evolution]

> On May 11, 2016, at 08:19, Haravikk via swift-evolution 
>  wrote:
> 
> It might be different if for example we could omit type when it can inferred 
> by other means as well, for example:
> 
>   protocol FooType {
>   func someMethod(value:String) -> Void
>   }
> 
>   struct Foo : FooType {
>   func someMethod(value) -> Void { … } // value is a String
>   }
> 
> But I’m not sure if I’d want to do that or not. Generally I like things that 
> shorten function signatures, but on its own I’d prefer consistency over 
> inference in this case I think.

Without commenting on the rest of it, there’s a difference to me between 
something that can be inferred based on local information and something that I 
have to look elsewhere to figure out. In the protocol case, I’d have to notice 
that this method satisfies a protocol requirement and know enough about the 
protocol to know what the type of the parameter is. In the default argument 
case, I only have to know about the type of the expression, which is very often 
a literal. (And even when it’s not, we generally assume the return type of most 
functions is inferrable from the name and arguments, or we’d be requiring types 
for locals too.)

(By the way, that’s also the history of inference for properties and globals: 
we knew we wanted it for locals and implemented it, and then it was immediately 
a little weird to have to write types elsewhere.)

Jordan

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

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

Re: [swift-evolution] NSRange and Range

[Jordan Rose via swift-evolution]

I’m not sure we’re going to stick to that in the future. It’s possible we’ll 
want String to support UTF-8 buffers as well.

Jordan


> On May 11, 2016, at 10:15, Zach Waldowski  wrote:
> 
> Conceptually, yes, but is that not exactly how it is implemented? 
> https://github.com/apple/swift/blob/master/stdlib/public/core/StringUTF16.swift#L24
>  
> 
>  
> Sincerely,
>   Zachary Waldowski
>   z...@waldowski.me 
>  
>  
> On Wed, May 11, 2016, at 01:13 PM, Jordan Rose wrote:
>> That’s correct, but how would you make the String.UTF16Index values without 
>> the reference String? They’re not (guaranteed to be) integers.
>>  
>> Jordan
>>  
>>  
>>> On May 10, 2016, at 16:04, Zach Waldowski >> > wrote:
>>>  
>>> Right, I 100% get it. :) This is a difficult problem space, and I'm sure 
>>> you folks are aware that that difficulty is also reflected in how brutal it 
>>> is to use all of these derivative string-range-based things in Swift right 
>>> now. In this case, having no answer to this problem is worse than not 
>>> having the API at all — check Stack Overflow or GitHub for how often a 
>>> "just paste this in" String.Index.init(_: Int) comes up.
>>>  
>>> As far as NSTextCheckingResult goes, its ranges are always in the "indices" 
>>> always in the space of the original string… do I have that right? So it 
>>> would be programmer error to use those ranges in the wrong string just like 
>>> it is with any Range today.
>>>  
>>> Zach Waldowski
>>>  
>>>  
>>> On Tue, May 10, 2016, at 06:51 PM, Jordan Rose wrote:
 By the way, this doesn’t mean it can’t be done, or that we can’t decide on 
 some kind of partial solution! It just means that it needs to be carefully 
 considered and explicitly addressed.
  
 Jordan
  
  
> On May 10, 2016, at 15:49, Jordan Rose  > wrote:
>  
> We thought about that too. The problem is that it’s not always obvious 
> what NSString or NSAttributedString the indexes refer to. For example, 
> most of the NSRegularExpression APIs produce matches in the form of 
> NSTextCheckingResult, which then doesn’t have a reference to the original 
> string.
>  
> Jordan
>  
>  
>> On May 10, 2016, at 13:43, Zach Waldowski via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>>  
>> Would it be feasible to annotate those and have them appropriately 
>> converted to Range upon crossing the bridge? Thinking 
>> in particular of TextKit and friends — it'd away with quite a lot of the 
>> pain of, e.g., not having a native struct-y AttributedString.
>>  
>> Cheers!
>>   Zachary Waldowski
>>   z...@waldowski.me 
>>  
>>  
>> On Tue, May 10, 2016, at 12:37 PM, Jordan Rose via swift-evolution wrote:
>>> One particular concern we've had is that many NSRanges aren’t 
>>> Range; they’re Range. I suppose things wouldn’t 
>>> get any worse there, though.
>>>  
>>> Jordan
>>>  
>>>  
 On May 10, 2016, at 00:14, David Hart via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
  
 But it’s reasonably implementable? I guess the answer is yes if you 
 have already faced the same bridging concerns with NSArray/Array. I’de 
 really like this going forward, but I don’t know how confident I am in 
 writing a proposal.
  
> On 10 May 2016, at 08:29, Douglas Gregor  > wrote:
>  
>  
>> On May 9, 2016, at 11:23 PM, David Hart > > wrote:
>>  
>> Why wouldn't it completely eliminate NSRange?
>  
> Because NSRange has a different representation than Range 
> (start+length vs. start/end), a pointer-to-NSRange has to come in as 
> Unsafe(Mutable)Pointer rather than 
> Unsafe(Mutable)Pointer>. It’s the same reason that (e.g.), 
> an NSArray** parameter comes in as UnsafeMutablePointer 
> rather than UnsafeMutablePointer<[AnyObject]>.
>  
>> Are you thinking of NSNotFound? Could we migrate those APIs to 
>> return an Optional Range?
>  
> If you had annotations on the APIs to say that they use NSNotFound as 
> a sentinel, yes.
>  
> - Doug
>  
>>  
>>> On 10 May 2016, at 05:49, Douglas Gregor >> > wrote:
>>>  
>>>  
 On May 8, 2016, at 2:10 PM, David Hart via swift-evolution 
 mailto:swift-evolution@swift.org>> 
 wrote:
  
 Hello Swift-Evolution,
  
 I spent some time coding on Linux with Swift 3 (latest 
>>>

Re: [swift-evolution] [proposal] Allow "let" for computed properties which only reference immutable data

[Alexander Momchilov via swift-evolution]

Yeah, there will need to be a facility to annotating function purity

On Wed, May 11, 2016 at 1:00 PM, Joe Groff  wrote:

>
> > On May 11, 2016, at 8:34 AM, Matthew Johnson via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> >
> >
> > Sent from my iPad
> >
> >> On May 11, 2016, at 10:26 AM, Sean Heber via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>
> >> I kind of agree with the logic of that, but imagine the following:
> >>
> >> class Test {
> >> let hello = “hello”
> >> var subject = “world”
> >> var phrase: String { return hello + “, “ + subject }
> >> }
> >>
> >> In this scenario, “subject” can be changed.. and that changes the
> result of “phrase”. Things like this are why computed properties are “var”.
> >
> > This example would still be required to be var because it accesses a var
> in its implementation.
> >
> > I like the idea of allowing this feature, but only in cases where the
> compiler can verify immutable semantics.  Having it may help drive other
> features that could expand the cases the compiler can verify.  That would
> be great as this is a direction I would like to see Swift take in the
> future.
>
> Yeah, this is why we don't currently allow computed "let" properties. We'd
> only want to do so once we have the language facilities to ensure a
> computed 'let' property is immutable and has no observable side effects.
>
> -Joe
>
> >>
> >> l8r
> >> Sean
> >>
> >>
> >>> On May 11, 2016, at 8:25 AM, Alexander Momchilov via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>>
> >>> I came an interesting SO question which pointed out a strange quirk: a
> computed property must always use the "var" keyword, even if it's
> read-only, and only referencing other immutable data.
> >>>
> >>> class Test {
> >>>
> >>>
> >>> let hello = "hello"
> >>>
> >>>
> >>> let world = "world"
> >>>
> >>>
> >>> var phrase: String { //why must this be 'var'?
> >>>
> >>>
> >>> return self.hello + self.
> >>> world
> >>>
> >>> }
> >>> }
> >>> It would be more appropriate for such a read-only, immutable property,
> to use the "let" syntax, so that its immutability is correctly expressed.
> >>>
> >>> Thoughts?
> >>> ___
> >>> 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
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] NSRange and Range

[Zach Waldowski via swift-evolution]

Conceptually, yes, but is that not exactly how it is implemented?
https://github.com/apple/swift/blob/master/stdlib/public/core/StringUTF16.swift#L24
 
Sincerely,
Zachary Waldowski
z...@waldowski.me
 
 
On Wed, May 11, 2016, at 01:13 PM, Jordan Rose wrote:
> That’s correct, but how would you *make* the String.UTF16Index values
> without the reference String? They’re not (guaranteed to be) integers.
>
> Jordan
>
>
>> On May 10, 2016, at 16:04, Zach Waldowski  wrote:
>>
>> Right, I 100% get it. :) This is a difficult problem space, and I'm
>> sure you folks are aware that that difficulty is also reflected in
>> how brutal it is to use all of these derivative string-range-based
>> things in Swift right now. In this case, having no answer to this
>> problem is worse than not having the API at all — check Stack
>> Overflow or GitHub for how often a "just paste this in"
>> String.Index.init(_: Int) comes up.
>>
>> As far as NSTextCheckingResult goes, its ranges are always in the
>> "indices" always in the space of the original string… do I have that
>> right? So it would be programmer error to use those ranges in the
>> wrong string just like it is with any Range today.
>>
>> Zach Waldowski
>>
>>
>> On Tue, May 10, 2016, at 06:51 PM, Jordan Rose wrote:
>>> By the way, this doesn’t mean it can’t be done, or that we can’t
>>> decide on some kind of partial solution! It just means that it needs
>>> to be carefully considered and explicitly addressed.
>>>
>>> Jordan
>>>
>>>
 On May 10, 2016, at 15:49, Jordan Rose 
 wrote:

 We thought about that too. The problem is that it’s not always
 obvious what NSString or NSAttributedString the indexes refer to.
 For example, most of the NSRegularExpression APIs produce matches
 in the form of NSTextCheckingResult, which then doesn’t have a
 reference to the original string.

 Jordan


> On May 10, 2016, at 13:43, Zach Waldowski via swift-evolution  evolut...@swift.org> wrote:
>
> Would it be feasible to annotate those and have them appropriately
> converted to Range upon crossing the bridge?
> Thinking in particular of TextKit and friends — it'd away with
> quite a lot of the pain of, e.g., not having a native struct-y
> AttributedString.
>
> Cheers!
> Zachary Waldowski
> z...@waldowski.me
>
>
> On Tue, May 10, 2016, at 12:37 PM, Jordan Rose via swift-evolution
> wrote:
>> One particular concern we've had is that many NSRanges aren’t
>> Range; they’re Range. I suppose things
>> wouldn’t get any *worse* there, though.
>>
>> Jordan
>>
>>
>>> On May 10, 2016, at 00:14, David Hart via swift-evolution >> evolut...@swift.org> wrote:
>>>
>>> But it’s reasonably implementable? I guess the answer is yes if
>>> you have already faced the same bridging concerns with
>>> NSArray/Array. I’de really like this going forward, but I don’t
>>> know how confident I am in writing a proposal.
>>>
 On 10 May 2016, at 08:29, Douglas Gregor 
 wrote:


> On May 9, 2016, at 11:23 PM, David Hart 
> wrote:
>
> Why wouldn't it completely eliminate NSRange?

 Because NSRange has a different representation than Range
 (start+length vs. start/end), a pointer-to-NSRange has to come
 in as Unsafe(Mutable)Pointer rather than
 Unsafe(Mutable)Pointer>. It’s the same reason that
 (e.g.), an NSArray** parameter comes in as
 UnsafeMutablePointer rather than
 UnsafeMutablePointer<[AnyObject]>.

> Are you thinking of NSNotFound? Could we migrate those APIs to
> return an Optional Range?

 If you had annotations on the APIs to say that they use
 NSNotFound as a sentinel, yes.

 - Doug

>
>> On 10 May 2016, at 05:49, Douglas Gregor 
>> wrote:
>>
>>
>>> On May 8, 2016, at 2:10 PM, David Hart via swift-evolution
>>>  wrote:
>>>
>>> Hello Swift-Evolution,
>>>
>>> I spent some time coding on Linux with Swift 3 (latest
>>> developement snapshot) and corelibs-foundation and I’ve hit
>>> one major hurdle: passing and converting NSRange and Range
>>> around between the different stdlib and Foundation APIs -
>>> specifically in regards to String.
>>>
>>> Is there a plan to simplify those pain points by converting
>>> all corelibs-foundation APIs to accept/return Range on
>>> String instead of NSRange? In that case, can’t we get rid of
>>> NSRange completely?
>>
>>
>> One idea that had come up before was to bridge NSRange to
>> Range, although it wouldn’t completely eliminate NSRange
>> because the two types are not representationally identical.
>>
>> 

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

[Vladimir.S via swift-evolution]

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


On 11.05.2016 19:47, Joe Groff via swift-evolution 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:

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

Re: [swift-evolution] NSRange and Range

[Jordan Rose via swift-evolution]

That’s correct, but how would you make the String.UTF16Index values without the 
reference String? They’re not (guaranteed to be) integers.

Jordan


> On May 10, 2016, at 16:04, Zach Waldowski  wrote:
> 
> Right, I 100% get it. :) This is a difficult problem space, and I'm sure you 
> folks are aware that that difficulty is also reflected in how brutal it is to 
> use all of these derivative string-range-based things in Swift right now. In 
> this case, having no answer to this problem is worse than not having the API 
> at all — check Stack Overflow or GitHub for how often a "just paste this in" 
> String.Index.init(_: Int) comes up.
>  
> As far as NSTextCheckingResult goes, its ranges are always in the "indices" 
> always in the space of the original string… do I have that right? So it would 
> be programmer error to use those ranges in the wrong string just like it is 
> with any Range today.
>  
> Zach Waldowski
>  
>  
> On Tue, May 10, 2016, at 06:51 PM, Jordan Rose wrote:
>> By the way, this doesn’t mean it can’t be done, or that we can’t decide on 
>> some kind of partial solution! It just means that it needs to be carefully 
>> considered and explicitly addressed.
>>  
>> Jordan
>>  
>>  
>>> On May 10, 2016, at 15:49, Jordan Rose >> > wrote:
>>>  
>>> We thought about that too. The problem is that it’s not always obvious what 
>>> NSString or NSAttributedString the indexes refer to. For example, most of 
>>> the NSRegularExpression APIs produce matches in the form of 
>>> NSTextCheckingResult, which then doesn’t have a reference to the original 
>>> string.
>>>  
>>> Jordan
>>>  
>>>  
 On May 10, 2016, at 13:43, Zach Waldowski via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
  
 Would it be feasible to annotate those and have them appropriately 
 converted to Range upon crossing the bridge? Thinking 
 in particular of TextKit and friends — it'd away with quite a lot of the 
 pain of, e.g., not having a native struct-y AttributedString.
  
 Cheers!
   Zachary Waldowski
   z...@waldowski.me 
  
  
 On Tue, May 10, 2016, at 12:37 PM, Jordan Rose via swift-evolution wrote:
> One particular concern we've had is that many NSRanges aren’t Range; 
> they’re Range. I suppose things wouldn’t get any worse 
> there, though.
>  
> Jordan
>  
>  
>> On May 10, 2016, at 00:14, David Hart via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>>  
>> But it’s reasonably implementable? I guess the answer is yes if you have 
>> already faced the same bridging concerns with NSArray/Array. I’de really 
>> like this going forward, but I don’t know how confident I am in writing 
>> a proposal.
>>  
>>> On 10 May 2016, at 08:29, Douglas Gregor >> > wrote:
>>>  
>>>  
 On May 9, 2016, at 11:23 PM, David Hart >>> > wrote:
  
 Why wouldn't it completely eliminate NSRange?
>>>  
>>> Because NSRange has a different representation than Range 
>>> (start+length vs. start/end), a pointer-to-NSRange has to come in as 
>>> Unsafe(Mutable)Pointer rather than 
>>> Unsafe(Mutable)Pointer>. It’s the same reason that (e.g.), 
>>> an NSArray** parameter comes in as UnsafeMutablePointer rather 
>>> than UnsafeMutablePointer<[AnyObject]>.
>>>  
 Are you thinking of NSNotFound? Could we migrate those APIs to return 
 an Optional Range?
>>>  
>>> If you had annotations on the APIs to say that they use NSNotFound as a 
>>> sentinel, yes.
>>>  
>>> - Doug
>>>  
  
> On 10 May 2016, at 05:49, Douglas Gregor  > wrote:
>  
>  
>> On May 8, 2016, at 2:10 PM, David Hart via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>>  
>> Hello Swift-Evolution,
>>  
>> I spent some time coding on Linux with Swift 3 (latest developement 
>> snapshot) and corelibs-foundation and I’ve hit one major hurdle: 
>> passing and converting NSRange and Range around between the 
>> different stdlib and Foundation APIs - specifically in regards to 
>> String.
>>  
>> Is there a plan to simplify those pain points by converting all 
>> corelibs-foundation APIs to accept/return Range on String instead of 
>> NSRange? In that case, can’t we get rid of NSRange completely?
>  
>  
> One idea that had come up before was to bridge NSRange to Range, 
> although it wouldn’t completely eliminate NSRange because the two 
> types are not representationally identical.
>  
> - Doug
>  
  
>>>  
>>  
>> ___

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

[Zach Waldowski via swift-evolution]

I don't recall seeing this proposal being pitched, and will also include
feedback of that stripe. Other responses inline.

On Wed, May 11, 2016, at 12:39 AM, Chris Lattner via swift-evolution
wrote:
>   * What is your evaluation of the proposal?

Strong +1 in concept. I'm thrilled that this might happen.

+0 in current implementation. The proposal as written does not fully
conform to Swift API standards and does not fully address the current
surface area of the Dispatch API. I am concerned about losing features
and performance in our haste to make something "more Swifty."

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

GCD's lack of integration with Swift — in part from the contusions the
API performs to be compatible with multiple languages at the API level

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

See other feedback below. Making changes in general is very much a good
idea. The APIs described do not always fit with Swift.

Separate from the APIs described herein, I am curious as to how much of
what needs to be done can or should be accomplished with apinotes and
the auditing facilities from SE-0044; it seems like 

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

With additions, the resulting API would be a nice improvement and go a
long way to making Swift feel like it has high-level multithreading
support.

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

In-depth study. I am an aggressive user of GCD in Swift.

---

## Type Naming and Structures

The namespace of GCD is already "Dispatch". The existing types in the
proposal are translating from snake-case to camel-case; this isn't
wholly necessary to me as Swift doesn't suffer from C's global
namespace.

dispatch_object_t is obviously a problem in this respect, but its use is
already fuzzy in current GCD (incl. in other languages; its use in C is
equally sketchy). I almost feel like the features of dispatch_object_t
should be encapsulated in protocols. (resume, cancel, etc.)

## Missing API

- Group, IO, and Semaphore are missing in their entirety.
- Data needs init() to match the dispatch_data_empty constant.
- There's no equivalent to dispatch_data_copy_region(3), which can be
used to step through the contiguous buffers (among other things).
- The shared functionality of dispatch_get_context(1),
dispatch_set_context(2), and dispatch_set_finalizer_f(2) are not
modeled.
- The shared functionality of dispatch_suspend(2) and dispatch_resume(2)
are not modeled.
- Queue has no getters for its label and QoS class.
- Queues do not have any modeling for their target queue.
- Custom queues cannot be created.
- dispatch_barrier_sync(2) is not represented. (Neither is
dispatch_barrier_async(2), but this is modeled by
DispatchWorkItemFlags.)
- No equivalents for dispatch_apply(3), dispatch_main(),
dispatch_after(3).

## API comments

- WorkItem
   * DispatchQueue.asynchronously(_:qos:flags:work:) should have a
   variant that takes a DispatchWorkItem. With the API as written, you
   could not enqueue a work item then cancel it.
   * Flags should be a nested type.

- Source
   * The details section needs examples of at least one of the
   DispatchSource protocols (i.e., DispatchSourceFileSystemObject). The
   current approach would seem to lose API inherited from DispatchSource
   and DispatchObject unless those are modeled in some other way.
   * None of Source's APIs for assigning handlers, configuring timers,
   getting or merging the user-defined data, or cancelling are exposed.

- Data
   * Overall, the API does not encapsulate dispatch_data_t's status as a
   tree of discontiguous buffers. I'd expect at least to have API to
   have a view of the contiguous buffers, for instance.
   * The alternate forms of append(_:) don't address management of the
   appended buffer's memory. Do they copy?
   * What are the COW semantics? In-place mutation is not thread-safe,
   whereas dispatch_data_t's current concatenation mechanisms are.
   * enumerateBytes(_:) is unclear, as it is enumerating the underlying
   byte buffers.

- Queue
   * Queue.asynchronously(group:qos:flags:work:) and
   Queue.synchronously(_:) does not conform to the API guidelines.
   * Queue.synchronously(_:) should be @noescape. If possible,
   rethrowing and returning a  would be optimal.

Sincerely,
  Zachary Waldowski
  z...@waldowski.me
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [proposal] Allow "let" for computed properties which only reference immutable data

[Joe Groff via swift-evolution]

> On May 11, 2016, at 8:34 AM, Matthew Johnson via swift-evolution 
>  wrote:
> 
> 
> 
> Sent from my iPad
> 
>> On May 11, 2016, at 10:26 AM, Sean Heber via swift-evolution 
>>  wrote:
>> 
>> I kind of agree with the logic of that, but imagine the following:
>> 
>> class Test {
>> let hello = “hello”
>> var subject = “world”
>> var phrase: String { return hello + “, “ + subject }
>> }
>> 
>> In this scenario, “subject” can be changed.. and that changes the result of 
>> “phrase”. Things like this are why computed properties are “var”.
> 
> This example would still be required to be var because it accesses a var in 
> its implementation.
> 
> I like the idea of allowing this feature, but only in cases where the 
> compiler can verify immutable semantics.  Having it may help drive other 
> features that could expand the cases the compiler can verify.  That would be 
> great as this is a direction I would like to see Swift take in the future.

Yeah, this is why we don't currently allow computed "let" properties. We'd only 
want to do so once we have the language facilities to ensure a computed 'let' 
property is immutable and has no observable side effects.

-Joe

>> 
>> l8r
>> Sean
>> 
>> 
>>> On May 11, 2016, at 8:25 AM, Alexander Momchilov via swift-evolution 
>>>  wrote:
>>> 
>>> I came an interesting SO question which pointed out a strange quirk: a 
>>> computed property must always use the "var" keyword, even if it's 
>>> read-only, and only referencing other immutable data.
>>> 
>>> class Test {
>>> 
>>> 
>>> let hello = "hello"
>>> 
>>> 
>>> let world = "world"
>>> 
>>> 
>>> var phrase: String { //why must this be 'var'?
>>> 
>>> 
>>> return self.hello + self.
>>> world
>>> 
>>> }
>>> }
>>> It would be more appropriate for such a read-only, immutable property, to 
>>> use the "let" syntax, so that its immutability is correctly expressed.
>>> 
>>> Thoughts?
>>> ___
>>> 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

___
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

[Joshua Kopin via swift-evolution]

+1

On 11 May 2016, at 9:11, Erica Sadun via swift-evolution wrote:


On May 11, 2016, at 9:42 AM, Evan Maloney  wrote:

I’m going to propose the keyword #litter as an alias for , so I 
can throw garbage syntax into my code more effectively seven letters 
at time :P


;-)




:P

One of the most interesting things about this whole comma proposal is 
how Swifty ("keeping in the feel and direction of Swift") it is to use 
multiple lines for functions and methods both in definition and at 
call sites. Swift may be "succinct" but in terms of generics, 
defaults, and external labels, it's absolutely ridiculous to try to 
limit signatures to single lines. The only way to deal with common 
Swift complexity is to structure what in any other language would be a 
single line into multiple lines. Here are a couple of examples pulled 
from stdlib:


  public func split(
separator: Iterator.Element,
maxSplits: Int = Int.max,
omittingEmptySubsequences: Bool = true
  ) -> [SubSequence] { ... }

and

public func transcode<
  Input : IteratorProtocol,
  InputEncoding : UnicodeCodec,
  OutputEncoding : UnicodeCodec
  where InputEncoding.CodeUnit == Input.Element

(

  _ input: Input,
  from inputEncoding: InputEncoding.Type,
  to outputEncoding: OutputEncoding.Type,
  stoppingOnError stopOnError: Bool,
  sendingOutputTo processCodeUnit: @noescape (OutputEncoding.CodeUnit) 
-> Void

) -> Bool { ... }

My call for commas crosses into two other discussions that are 
happening right now on Swift Evolution: moving where clauses to the 
end of declarations (yes please) and whether to force defaulted 
parameters to appear in order at call sites (no thank you). Thinking 
about commas from this point of view can be  disconcerting because 
when you think "What is Swift", the phrase that pops to mind is always 
"clarity and concision" but real world Swift declarations are anything 
but.  Clear? They can be with carefully considered folding. Concise? 
Not especially.


I hope that anyone considering this proposal will think carefully 
about real world Swift like the examples I've pasted above and the 
others I've used in previous replies rather than some theoretical 
ideal where excess punctuation at the end of a declaration or call 
site is an actual silly eyesore:


func foo(a: T, b: U,) // not especially reflective of real world use

Because in the end this proposal should succeed or fail based on 
actual code enhancement and the gains that are to be accrued in real 
world use and not due to a simple taste factor.


-- 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] multi-line string literals.

[Vladimir.S via swift-evolution]

On 11.05.2016 19:38, Ricardo Parada wrote:

I did not suggest the single quote because it is commonly found in the
English language and we would have to escape it.


Wel.. in your document you have a number of variants of multi-line 
'feature' implementations with different pros/cons for each.


Could you clarify, why this proposal with single quote can not be inside 
your document as just another variant with its own pros/cons ? Especially, 
as you can see, if "We'd rather save single quoted literals for a greater 
purpose (e.g. non-escaped string literals)" ?




That is why I suggested a rare combination using the @" and "@ as the
delimiters. Unless your text is Obj-C code it would be rare to find it.



And what do you suggest to do if we *have* `"@` inside the text we want to 
use ?






On May 11, 2016, at 10:50 AM, Vladimir.S via swift-evolution
 wrote:

Did I miss the proposal for single quote?

Just found on
https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md





-<

Single-quotes '' for Character literals: Swift takes the approach of
highly valuing Unicode. However, there are multiple concepts of a
character that could make sense in Unicode, and none is so much more
commonly used than the others that it makes sense to privilege them.
We'd rather save single quoted literals for a greater purpose (e.g.
non-escaped string literals).

-<


So, what about using of single quote as "special" strings?

For example, I'd propose to use single quote quotation to say "this
string should be used as-is, no escapes processing"

'some 1\total\\2\\\3 "sdfsdf" \(-: """ helllooo'

the only 'disallowed' symbol could be the single quote itself, but I
propose the solution used in other languages - duplicate it if we need
it in string:

'this '' is a single quote in string, and this is another'''

and also in multiline strings:

assert( xml == ' ' ' '\(author) // note '' here in
string 'XML Developer''s Guide '
Computer '44.95 '
2000-10-01 'An
in-depth look at XML. ' '')

(also needs to duplicate single quote if in text. the compromise,
yes.)


On 10.05.2016 9:53, John Holdsworth via swift-evolution wrote: I’ve
assembled a gist to summarise the main proposals of this thread.

https://gist.github.com/johnno1962/5c325a16838ad3c73e0f109a514298bf

At the moment there seem to be four proposals for multi-line
strings:

1) Bent’s proposal for continuation quotes where if a conventional
string does not close, if the first non-whitespace character of the
next line is “ (or perhaps |) the string is continued. This gives
you precise control over exactly what is in the string.

2) Tyler's original proposal involving strings that can contain
newlines delimited “””like this“”” as they are in python or, _”like
this“_. This works well in external editors and on github.
Indentation is catered for by stripping any whitespace before the
closing quote from all lines in the string.

3) HEREDOC syntax <<“TAG” or <<‘TAG’ taken from languages like Perl
subject to the same indentation removal rules as “””strings”””
above. This has the advantage that the literal is clearly separated
from your code.

4) Heck it all, why not all three syntaxes or some combination.

(There is a separate feature that all string literals can be
prefixed by e as in e”\w\d+” to turn of all escape processing for
another day)

While the Swift Lexer could easily accommodate all these syntaxes
there was talk early on that Swift has more of a "one way, maximally
elegant” ethos and indeed I find it difficult imagine the Swift Book
breathlessly describing all three formats so I’m wondering if push
came to shove which format people would chose?

My vote having undergone a "road to damascus" moment now we know it
is available sooner rather than later is.. HEREDOC! It’s well
understood and while at first it would seem to not be a good fit for
Swift produces clear code.

Votes?

John


// Multi-line string proposals //
https://github.com/apple/swift/pull/2275

// swift-evolution thread: //
http://thread.gmane.org/gmane.comp.lang.swift.evolution/904/focus=15133




// These examples should load in the prototype toolchain available

here: //
http://johnholdsworth.com/swift-LOCAL-2016-05-09-a-osx.tar.gz

// The prototype currently parses three new forms of quoting //
These new types are still string literals for the grammar.

"the existing string literal format" _"a format that does not
require you to escape " characters"_ // possibly redundant """a
python-style syntax that will accept "'s and newlines in the
string""" <<"HEREDOC" A full heredoc implementation (will always end
in a newline) HEREDOC

// These strings can be modified by prefixing the string by letters
// There is currently only one, "e" to disable escape processing. //
This is primarily used when specifying regular expressions.

letstr = "print(\"Hello, world!\\n\")"

assert( e"print(\"Hello, world!\n\")"== str )

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

[Joe Groff via swift-evolution]

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

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

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

-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

[Joe Groff via swift-evolution]

> On May 11, 2016, at 9:47 AM, 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:
>   
>   --- a.swift
>   +++ a.swift
>foo( x: 0
>   , y: 1
>   +   , z: 2
>   )
> 
> I think the trailing-comma syntax jives much better with Swift style.

In response to observations that tuples and function arguments are somehow 
different from collection literals because they generally have fixed arity, 
I'll note that we have an very prominent variadic function in the standard 
library, "print", and that adding or removing values to a "print" is a very 
common and natural thing to do.

-Joe
___
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]

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.


On 11.05.2016 18:58, Matthew Johnson wrote:

'f' would return E for E, F and G.  Because the conformance is declared
by E the requirement to return #Self is fixed as an invariant
requirement to return E for all potential subclasses.



Probably you(we) need another proposal, like BaseSelf (or SuperSelf)
that means "this class or any its base class", then I understand how
such a `f()->BaseSelf` protocol requirement can be applied to E
class and also be true for F&G classes (as f() inherited from base
class will return instance of E which is base for both).

This is exactly what #Self (or Type) does.  The behavior you have been
describing is the behavior of Self which already exists.


___
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 did not suggest the single quote because it is commonly found in the English 
language and we would have to escape it.  

That is why I suggested a rare combination using the @" and "@ as the 
delimiters. Unless your text is Obj-C code it would be rare to find it. 


> On May 11, 2016, at 10:50 AM, Vladimir.S via swift-evolution 
>  wrote:
> 
> Did I miss the proposal for single quote?
> 
> Just found on 
> https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md
> >-<
> Single-quotes '' for Character literals: Swift takes the approach of highly 
> valuing Unicode. However, there are multiple concepts of a character that 
> could make sense in Unicode, and none is so much more commonly used than the 
> others that it makes sense to privilege them. We'd rather save single quoted 
> literals for a greater purpose (e.g. non-escaped string literals).
> >-<
> 
> So, what about using of single quote as "special" strings?
> 
> For example, I'd propose to use single quote quotation to say "this string 
> should be used as-is, no escapes processing"
> 
> 'some 1\total\\2\\\3 "sdfsdf" \(-: """ helllooo'
> 
> the only 'disallowed' symbol could be the single quote itself, but I propose 
> the solution used in other languages - duplicate it if we need it in string:
> 
> 'this '' is a single quote in string, and this is another'''
> 
> and also in multiline strings:
> 
> assert( xml == '
>'
>'
>'\(author)
>// note '' here in string
>'XML Developer''s Guide
>'Computer
>'44.95
>'2000-10-01
>'An in-depth look at XML.
>'
>'')
> 
> (also needs to duplicate single quote if in text. the compromise, yes.)
> 
>> On 10.05.2016 9:53, John Holdsworth via swift-evolution wrote:
>> I’ve assembled a gist to summarise the main proposals of this thread.
>> 
>> https://gist.github.com/johnno1962/5c325a16838ad3c73e0f109a514298bf
>> 
>> At the moment there seem to be four proposals for multi-line strings:
>> 
>> 1) Bent’s proposal for continuation quotes where if a conventional string
>> does not close, if the first non-whitespace character of the next line is “
>> (or perhaps |) the string is continued. This gives you precise control
>> over exactly what is in the string.
>> 
>> 2) Tyler's original proposal involving strings that can contain newlines
>> delimited “””like this“”” as they are in python or, _”like this“_. This works
>> well in external editors and on github. Indentation is catered for by
>> stripping
>> any whitespace before the closing quote from all lines in the string.
>> 
>> 3) HEREDOC syntax <<“TAG” or <<‘TAG’ taken from languages like Perl
>> subject to the same indentation removal rules as “””strings””” above. This
>> has the advantage that the literal is clearly separated from your code.
>> 
>> 4) Heck it all, why not all three syntaxes or some combination.
>> 
>> (There is a separate feature that all string literals can be prefixed by
>> e as in e”\w\d+” to turn of all escape processing for another day)
>> 
>> While the Swift Lexer could easily accommodate all these syntaxes there was
>> talk early on that Swift has more of a "one way, maximally elegant” ethos and
>> indeed I find it difficult imagine the Swift Book breathlessly describing
>> all three
>> formats so I’m wondering if push came to shove which format people would 
>> chose?
>> 
>> My vote having undergone a "road to damascus" moment now we know it is
>> available sooner rather than later is.. HEREDOC! It’s well understood and
>> while at first it would seem to not be a good fit for Swift produces clear
>> code.
>> 
>> Votes?
>> 
>> John
>> 
>> 
>>// Multi-line string proposals
>>// https://github.com/apple/swift/pull/2275
>> 
>>// swift-evolution thread:
>>//
>> http://thread.gmane.org/gmane.comp.lang.swift.evolution/904/focus=15133
>> 
>>// These examples should load in the prototype toolchain available
>> here:
>>// http://johnholdsworth.com/swift-LOCAL-2016-05-09-a-osx.tar.gz
>> 
>>// The prototype currently parses three new forms of quoting
>>// These new types are still string literals for the grammar.
>> 
>>"the existing string literal format"
>>_"a format that does not require you to escape " characters"_ //
>> possibly redundant
>>"""a python-style syntax that will accept "'s and newlines in the
>> string"""
>><<"HEREDOC"
>>A full heredoc implementation (will always end in a newline)
>>HEREDOC
>> 
>>// These strings can be modified by prefixing the string by letters
>>// There is currently only one, "e" to disable escape processing.
>>// This is primarily used when specifying regular expressions.
>> 
>>letstr = "print(\"Hello, world!\\n\")"
>> 
>>assert( e"print(\"Hello, world!\n\")"== str )
>>assert( e_"print("Hello, world!\n")"_ 

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

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On May 11, 2016, at 11:11 AM, Erica Sadun via swift-evolution 
>  wrote:
> 
> 
>>> On May 11, 2016, at 9:42 AM, Evan Maloney  wrote:
>>> 
>>> I’m going to propose the keyword #litter as an alias for , so I can throw 
>>> garbage syntax into my code more effectively seven letters at time :P
>> 
>> ;-)
> 
> :P
> 
> One of the most interesting things about this whole comma proposal is how 
> Swifty ("keeping in the feel and direction of Swift") it is to use multiple 
> lines for functions and methods both in definition and at call sites. Swift 
> may be "succinct" but in terms of generics, defaults, and external labels, 
> it's absolutely ridiculous to try to limit signatures to single lines. The 
> only way to deal with common Swift complexity is to structure what in any 
> other language would be a single line into multiple lines. Here are a couple 
> of examples pulled from stdlib:
> 
>   public func split(
> separator: Iterator.Element,
> maxSplits: Int = Int.max,
> omittingEmptySubsequences: Bool = true
>   ) -> [SubSequence] { ... }
> 
> and
> 
> public func transcode<
>   Input : IteratorProtocol,
>   InputEncoding : UnicodeCodec,
>   OutputEncoding : UnicodeCodec
>   where InputEncoding.CodeUnit == Input.Element
> >(
>   _ input: Input,
>   from inputEncoding: InputEncoding.Type,
>   to outputEncoding: OutputEncoding.Type,
>   stoppingOnError stopOnError: Bool,
>   sendingOutputTo processCodeUnit: @noescape (OutputEncoding.CodeUnit) -> Void
> ) -> Bool { ... }
> 
> My call for commas crosses into two other discussions that are happening 
> right now on Swift Evolution: moving where clauses to the end of declarations 
> (yes please) and whether to force defaulted parameters to appear in order at 
> call sites (no thank you). Thinking about commas from this point of view can 
> be  disconcerting because when you think "What is Swift", the phrase that 
> pops to mind is always "clarity and concision" but real world Swift 
> declarations are anything but.  Clear? They can be with carefully considered 
> folding. Concise? Not especially.
> 
> I hope that anyone considering this proposal will think carefully about real 
> world Swift like the examples I've pasted above and the others I've used in 
> previous replies rather than some theoretical ideal where excess punctuation 
> at the end of a declaration or call site is an actual silly eyesore:
> 
> func foo(a: T, b: U,) // not especially reflective of real world use
> 
> Because in the end this proposal should succeed or fail based on actual code 
> enhancement and the gains that are to be accrued in real world use and not 
> due to a simple taste factor.

+1

> 
> -- 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] [swift-evolution-announce] [Review] SE-0084: Allow trailing commas in parameter lists and tuples

[Vladimir.S via swift-evolution]

On 11.05.2016 18:09, Erica Sadun via swift-evolution wrote:

To which I reply:

* Well structured code needn't read like an error. The examples above show
an in-house style that allows final commas. Your in-house style may differ
and a linter can catch these issues.


Will not discuss about taste. Someone likes commas, someone not. Not important.


* Both collections and signatures are syntactically similar in layout even
if they are semantically different in use. In Swift, complex method
signatures with defaulted arguments like the example shown are not
uncommon. Do not limit your thinking to single line lists of (x: T, y: U,
z: V) signatures.
* Parameter lists and function signatures, like collections, can evolve,
especially when using defaulted parameters, even when they are consumed at
multiple points.


Can't agree. For me the main point is *they are semantically different in 
use*, this is why I like trailing commas in array/dict and don't like in 
signatures. For me array/dict - is "data", parameter list - is "code".


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

but I don't know if I'd support the same for parameter list/tuples, 
probably will not support.

___
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 11, 2016, at 9:42 AM, Evan Maloney  wrote:
> 
>> I’m going to propose the keyword #litter as an alias for , so I can throw 
>> garbage syntax into my code more effectively seven letters at time :P
> 
> ;-)
> 
> 

:P

One of the most interesting things about this whole comma proposal is how 
Swifty ("keeping in the feel and direction of Swift") it is to use multiple 
lines for functions and methods both in definition and at call sites. Swift may 
be "succinct" but in terms of generics, defaults, and external labels, it's 
absolutely ridiculous to try to limit signatures to single lines. The only way 
to deal with common Swift complexity is to structure what in any other language 
would be a single line into multiple lines. Here are a couple of examples 
pulled from stdlib:

  public func split(
separator: Iterator.Element,
maxSplits: Int = Int.max,
omittingEmptySubsequences: Bool = true
  ) -> [SubSequence] { ... }

and

public func transcode<
  Input : IteratorProtocol,
  InputEncoding : UnicodeCodec,
  OutputEncoding : UnicodeCodec
  where InputEncoding.CodeUnit == Input.Element
>(
  _ input: Input,
  from inputEncoding: InputEncoding.Type,
  to outputEncoding: OutputEncoding.Type,
  stoppingOnError stopOnError: Bool,
  sendingOutputTo processCodeUnit: @noescape (OutputEncoding.CodeUnit) -> Void
) -> Bool { ... }

My call for commas crosses into two other discussions that are happening right 
now on Swift Evolution: moving where clauses to the end of declarations (yes 
please) and whether to force defaulted parameters to appear in order at call 
sites (no thank you). Thinking about commas from this point of view can be  
disconcerting because when you think "What is Swift", the phrase that pops to 
mind is always "clarity and concision" but real world Swift declarations are 
anything but.  Clear? They can be with carefully considered folding. Concise? 
Not especially.

I hope that anyone considering this proposal will think carefully about real 
world Swift like the examples I've pasted above and the others I've used in 
previous replies rather than some theoretical ideal where excess punctuation at 
the end of a declaration or call site is an actual silly eyesore:

func foo(a: T, b: U,) // not especially reflective of real world use

Because in the end this proposal should succeed or fail based on actual code 
enhancement and the gains that are to be accrued in real world use and not due 
to a simple taste factor.

-- E



___
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

[Tony Allevato via swift-evolution]

On Wed, May 11, 2016 at 8:09 AM Erica Sadun via swift-evolution <
swift-evolution@swift.org> wrote:

>
> To summarize the complaints to date:
>
> * It make code read like errors
> * Arrays and dictionaries are different "things" than parameters and
> tuples; They are structurally different
> * Parameter lists should always be of fixed size at deployment time; Once
> a signature is fixed and consumed, it's difficult to change
>
> To which I reply:
>
> * Well structured code needn't read like an error. The examples above show
> an in-house style that allows final commas. Your in-house style may differ
> and a linter can catch these issues.
> * Both collections and signatures are syntactically similar in layout even
> if they are semantically different in use. In Swift, complex method
> signatures with defaulted arguments like the example shown are not
> uncommon. Do not limit your thinking to single line lists of (x: T, y: U,
> z: V) signatures.
> * Parameter lists and function signatures, like collections, can evolve,
> especially when using defaulted parameters, even when they are consumed at
> multiple points.
>

To me, this reads like a solution in search of a problem, and the arbitrary
syntactical freedom—and IMO, ugliness—that would be allowed by it outweighs
the benefit of not having to type a comma occasionally. We shouldn't just
loosen the syntax of a language arbitrarily because tools can produce
linter warnings or auto-correct them; if we use that as our determining
factor, where do we draw the line?

Once a function signature evolves, you typically have to change all of the
call sites (excepting arguments with default values), which will be a
bigger task than inserting a comma anyway. And if you only have to change
the function definition (if it's a default argument), is the extra comma
you have to add that big of a problem? How often in the process of writing
code is someone going to re-order default arguments that this would be a
significant benefit?

Since you alluded to teaching earlier as a scenario to consider, in my
(anecdotal, of course) experience teaching CS, I've never run into a time
where a student was confused by the inability to put a trailing comma in an
argument list or where it was more than a trivial inconvenience to have to
add one later, but I *can* recall times where they stumbled over trailing
commas when they were present ("does it have a different meaning?" "is
there an empty item in this list?", etc.). That harkens back to concerns
that trailing commas make code look like there's something "missing" or
"left out."

Of course, the argument could be made that I personally would be mostly
unaffected by this change—I don't use trailing commas now and this proposal
wouldn't force me to start. So why do I care? I feel that changes that
would loosen the language syntax should have to meet an extremely high bar
other than allowing for personal style preference or convenience.
Consistency is a good goal, but if that was the argument being made, I'd
argue the opposite direction—commas should be uniformly treated as
separators, not terminators, and should not be allowed in a terminating
position in collection literals either, even despite the fact that I think
there is more of a case to be made to allow them there vs. here.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Dennis Weissmann via swift-evolution]

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

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

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

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

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

A little nitpick:

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

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

- Dennis

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

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

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

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On May 11, 2016, at 10:43 AM, Vladimir.S  wrote:
> 
> 
>> On 11.05.2016 17:42, Matthew Johnson wrote:
>> You are describing the behavior of Self, not #Self.
> 
> Well.. Yes :-) I.e. I wanted to show that `->#Self` requirement in 
> protocol(from my point of view) will produce issues just like `->Self`
> 
> 
>> 
>>>   #Self expands to the static type of the code it is declared
>>> within. In value types, this is always the same as Self. In reference
>>> types, it refers to the *declaring* type.
>> 
>> For implementations of protocol requirements the declaring type is the type
>> that declares conformance.
>> 
>> Self is covariant, #Self (or Type) is invariant.  That is the difference.
> 
> There is some misunderstanding between us.
> Most likely this is because of my terrible English. (Btw, sorry for this)
> 
> I just can't understand, how do you understand the `A` protocol conformance 
> for F & G classes in my examples?
> 
> In your word, with implemented #Self, F & G `is A` ? If so, how exactly they 
> conform to protocol that says F & G *must* have `f` that returns #Self. What 
> is #Self for F & G classes that should be returned in f()?
> Right now I think that your idea just can not be implemented at all based on 
> *initial* #Self proposal.

'f' would return E for E, F and G.  Because the conformance is declared by E 
the requirement to return #Self is fixed as an invariant requirement to return 
E for all potential subclasses.

> 
> Probably you(we) need another proposal, like BaseSelf (or SuperSelf) that 
> means "this class or any its base class", then I understand how such a 
> `f()->BaseSelf` protocol requirement can be applied to E class and also be 
> true for F&G classes (as f() inherited from base class will return instance 
> of E which is base for both).

This is exactly what #Self (or Type) does.  The behavior you have been 
describing is the behavior of Self which already exists.
___
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

[Cole Campbell via swift-evolution]

Sorry, I realized after seeing Darren's message that I made a mistake. The 
abbreviation doesn't end with 'h'. It should be:

dispatchAsync()
dispatchSync()

> On May 11, 2016, at 10:10 AM, Cole Campbell via swift-evolution 
>  wrote:
> 
>> My main piece of feedback is that the method names synchronously() and 
>> asynchronously() don’t conform to Swift 3 naming conventions for functions 
>> and methods:
> 
> I agree.
> 
>> dispatchAsynch()
>> dispatchSynch()
> 
> I prefer something like this. It feels more Swifty. As it is, they aren't any 
> longer than asynchronously(), if name length is a concern.
> ___
> 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

[Jacob Bandes-Storch via swift-evolution]

On Wed, May 11, 2016 at 7:50 AM, James Dempsey via swift-evolution <
swift-evolution@swift.org> 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.
>

This is a nice idea, but unfortunately it would defeat the ability to use
@noescape/rethrows/generic-return-type for the sync version.


> James
>
>
>
> On May 11, 2016, at 7:14 AM, Ricardo Parada  wrote:
>
> Jacob Bandes-Storch suggested:
>
> synchronously(execute work: …)
>
>
This wasn't meant to be a suggestion for the name, just pointing out what
might have been a typo/inconsistency in the proposal.

Jacob

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

On 11.05.2016 17:42, Matthew Johnson wrote:

You are describing the behavior of Self, not #Self.


Well.. Yes :-) I.e. I wanted to show that `->#Self` requirement in 
protocol(from my point of view) will produce issues just like `->Self`






   #Self expands to the static type of the code it is declared
within. In value types, this is always the same as Self. In reference
types, it refers to the *declaring* type.


For implementations of protocol requirements the declaring type is the type
that declares conformance.

Self is covariant, #Self (or Type) is invariant.  That is the difference.


There is some misunderstanding between us.
Most likely this is because of my terrible English. (Btw, sorry for this)

I just can't understand, how do you understand the `A` protocol conformance 
for F & G classes in my examples?


In your word, with implemented #Self, F & G `is A` ? If so, how exactly 
they conform to protocol that says F & G *must* have `f` that returns 
#Self. What is #Self for F & G classes that should be returned in f()?
Right now I think that your idea just can not be implemented at all based 
on *initial* #Self proposal.


Probably you(we) need another proposal, like BaseSelf (or SuperSelf) that 
means "this class or any its base class", then I understand how such a 
`f()->BaseSelf` protocol requirement can be applied to E class and also be 
true for F&G classes (as f() inherited from base class will return instance 
of E which is base for both).

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

I think hex encoded string conversion is a important use case. Another idea - 
instead of making the Data type itself generic, there can be a generic 
Data.View into the data, or the Data type can come with a 
number of Views for each of the fixed-width integer types.

Austin


> On May 11, 2016, at 7:09 AM, Jeremy Pereira  
> wrote:
> 
> 
>> On 11 May 2016, at 10:37, Austin Zheng via swift-evolution 
>>  wrote:
>> 
>> Hello swift-evolution,
>> 
>> 
> 
> ...
> 
>> Some thoughts:
>> 
>> - It's not clear if the methods to convert to and from base-64 encoded data 
>> are necessary. The state flag that tries to mark whether or not a Data 
>> represents base-64-encoded string stored as a data may be unnecessary as 
>> well.
>> 
> 
> I would definitely vote for having the base64 conversions in. The state flag 
> would have less utility IMO. 
> 
> I would also ask that you consider conversions to and from hex encoded 
> strings. If nothing else, it would make it easier to convert git commit 
> hashes to a readable form in my forthcoming git client vapourware.
> 

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

[swift-evolution] [proposal] Allow "let" for computed properties which only reference immutable data

[Alexander Momchilov via swift-evolution]

I came an interesting SO question
 which pointed out a strange
quirk: a computed property must always use the "var" keyword, even if it's
read-only, and only referencing other immutable data.

class Test {
  let hello = "hello"
  let world = "world"
  var phrase: String { //why must this be 'var'?
 return self.hello + self.world
  }}

It would be more appropriate for such a read-only, immutable property, to
use the "let" syntax, so that its immutability is correctly expressed.

Thoughts?
___
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

[Sean Heber via swift-evolution]

I think that, to me, the ability to allow trailing commas is linked with the 
ability to arbitrarily reorder defaulted parameters. If we retain arbitrary 
reordering of defaults (which I like and have taken advantage of), then we 
should allow trailing commas as well. Both of these features together help make 
quick playground prototyping and experimentation easy and painless.

l8r
Sean


> On May 11, 2016, at 10:09 AM, Erica Sadun via swift-evolution 
>  wrote:
> 
>> 
>> On May 11, 2016, at 8:01 AM, Ricardo Parada via swift-evolution 
>>  wrote:
>>> On May 10, 2016, at 2:53 PM, Chris Lattner  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
>> 
>>> * What is your evaluation of the proposal?
>> 
>> -1
>> 
>> I don’t like the proposal.  I understand the flexibility it gives to 
>> rearranging elements but to someone reading the code it looks like an 
>> element was removed by mistake.
> 
> 
> This objection is coming up quite often and I don't really see the difference 
> between trailing commas in collections (legal in Swift)
> 
> let listenerKeys: NSDictionary = [
> AVFormatIDKey: NSNumber(unsignedInt: kAudioFormatAppleLossless),
> AVSampleRateKey: 44100.0,
> AVNumberOfChannelsKey: 1,
> AVEncoderAudioQualityKey: NSNumber(int: 
> Int32(AVAudioQuality.Max.rawValue)),
> ]
> 
> And trailing commas in parameter lists (not yet allowed in Swift):
> 
> public convenience init(
> _ w: CGFloat,
> _ h: CGFloat,
> position: CGPoint = .zero,
> backgroundColor: UIColor = UIColor.whiteColor(),
> translucency alpha: CGFloat = 1.0,
> borderWidth: CGFloat = 0.0,
> borderColor: UIColor = UIColor.blackColor(),
> cornerRadius: CGFloat = 0.0, // this is currently illegal
> ){
> ...
> }
> 
> Neither example reads to me as if an element was removed by mistake. Both 
> greatly enhance programming flexibility. Both allow the final comma to be 
> omitted and/or the elements to be re-ordered.
> 
> To summarize the complaints to date:
> 
> * It make code read like errors
> * Arrays and dictionaries are different "things" than parameters and tuples; 
> They are structurally different
> * Parameter lists should always be of fixed size at deployment time; Once a 
> signature is fixed and consumed, it's difficult to change
> 
> To which I reply:
> 
> * Well structured code needn't read like an error. The examples above show an 
> in-house style that allows final commas. Your in-house style may differ and a 
> linter can catch these issues.
> * Both collections and signatures are syntactically similar in layout even if 
> they are semantically different in use. In Swift, complex method signatures 
> with defaulted arguments like the example shown are not uncommon. Do not 
> limit your thinking to single line lists of (x: T, y: U, z: V) signatures.
> * Parameter lists and function signatures, like collections, can evolve, 
> especially when using defaulted parameters, even when they are consumed at 
> multiple points.
> 
> -- 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] Standard library 'Data' type pre-proposal

[Austin Zheng via swift-evolution]

Hi Patrick,

Thanks for your feedback!

dispatch_data_t certainly is an intriguing alternative. I don't think it would 
be a good fit for a Swift standard library type verbatim, given that it's 
written in C and contains APIs that would not really be relevant within a Swift 
environment, but it should definitely be considered as a model.

One question that this brings up is whether supporting non-contiguous data 
regions in a native Swift data type is worth the complexity costs. There are 
good reasons for dispatch_data_t to be implemented the way it is, but NSData 
has always assumed that it is modeling a contiguous area in memory, and it 
provides users with raw access to the underlying buffer. A cursory examination 
of a few other languages (Java, Python, Haskell) show that these languages all 
model binary data as some sort of contiguous array-like construct containing 
bytes.

I do think, at the very least, overlays should exist to provide initializers 
that convert between dispatch_data_t in Swift's libdispatch, the native Data 
type, and NSData (if NSData is still to be a separate type after Data is 
implemented). If contiguity is not important (and there is no compelling reason 
for access to raw pointers to be exposed in a public interface), it makes a lot 
of sense to 'unify' the various data types under a DataProtocol protocol that 
inherits from RandomAccessCollection.

Another question is how a Data type's API will interact with however Swift 
eventually decides to handle native serialization/deserialization, but that's 
almost certainly a >= Swift 4 topic and I won't go into detail right now.

Austin


> On May 11, 2016, at 3:57 AM, Patrick Smith  wrote:
> 
> Hi Austin,
> 
> The proposal looks well fleshed out! Another alternative to consider is the 
> ‘DispatchData’ struct from libdispatch currently being reviewed? Some of 
> additions these could be added as an extension to that type? Or perhaps a 
> protocol could be made ‘DataProtocol’, that has a base set of required 
> methods and a further set of extensions using that base. Then NSData and 
> DispatchData can conform and implement those base methods and each get the 
> functionality. But personally I think it would be nice to make DispatchData 
> the native Swift data type, whether the libdispatch team would accept 
> extensions in the future like this I don’t know, but I think it would be 
> interesting.
> 
> Patrick
> 
> 
>> On 11 May 2016, at 7:37 PM, Austin Zheng via swift-evolution 
>> mailto:swift-evolution@swift.org>> 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.
>> 
>> As such, I've put together a very preliminary proposal, which can be found 
>> here: 
>> https://github.com/austinzheng/swift-evolution/blob/d2/proposals/-stdlib-data.md
>>  
>> .
>>  I present it not as a way to impose a vision of what such a Data type 
>> should look like, but rather as a way to catalyze discussion (including 
>> discussion as to whether or not a Data type is even a good idea in the first 
>> place).
>> 
>> Some thoughts:
>> 
>> - It's not clear if the methods to convert to and from base-64 encoded data 
>> are necessary. The state flag that tries to mark whether or not a Data 
>> represents base-64-encoded string stored as a data may be unnecessary as 
>> well.
>> 
>> - I didn't really go into how NSData should be bridged. Special 
>> consideration needs to be given to how any native Data type would interact 
>> with the overlays described in 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0069-swift-mutability-for-foundation.md
>>  
>> .
>>  It's possible (and only if a compelling technical reason exists) that the 
>> Foundation implementation of NSData can in the future be moved into 
>> Swift/supplanted by such a native data type, with API extensions to provide 
>> conformance to the Objective-C Foundation API. This proposal should not be 
>> seen as an attempt to usurp Foundation's job, though - there are plenty of 
>> to-be-value types in Foundation whose inclusion directly in the standard 
>> library makes little sense.
>> 
>> - Perhaps Data should be generic over various types of fixed-width integers 
>> (signed and unsigned, 8, 16, 32, 64, machine-width, etc). In that case it 
>> might also provide generic views (for example, to allow iteration over a 
>> Data as if it were a collection of UInt8 bytes). I'm not y

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

[Patrick Smith via swift-evolution]

I’m going to propose the keyword #litter as an alias for , so I can throw 
garbage syntax into my code more effectively seven letters at time :P

I think this is just a choice of taste, and this is offering an additional 
choice. You don’t have to agree with it, you don’t have to make use of it, you 
don’t even have to know it’s there.

We’ve all seen and written messy code, and it wasn’t due to the punctuation. 
There are much more powerful weapons at hand for that.


> On 12 May 2016, at 1:25 AM, Evan Maloney via swift-evolution 
>  wrote:
> 
> 
>>> It feels wrong to allow garbage syntax lying around in one's code simply 
>>> for the sake of occasional convenience.
>> 
>> Would you then recommend removing trailing comma support for collections on 
>> the same principle?
> 
> Yes.
> 
> ___
> 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] Allow "let" for computed properties which only reference immutable data

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On May 11, 2016, at 10:26 AM, Sean Heber via swift-evolution 
>  wrote:
> 
> I kind of agree with the logic of that, but imagine the following:
> 
> class Test {
>  let hello = “hello”
>  var subject = “world”
>  var phrase: String { return hello + “, “ + subject }
> }
> 
> In this scenario, “subject” can be changed.. and that changes the result of 
> “phrase”. Things like this are why computed properties are “var”.

This example would still be required to be var because it accesses a var in its 
implementation.

I like the idea of allowing this feature, but only in cases where the compiler 
can verify immutable semantics.  Having it may help drive other features that 
could expand the cases the compiler can verify.  That would be great as this is 
a direction I would like to see Swift take in the future.

> 
> l8r
> Sean
> 
> 
>> On May 11, 2016, at 8:25 AM, Alexander Momchilov via swift-evolution 
>>  wrote:
>> 
>> I came an interesting SO question which pointed out a strange quirk: a 
>> computed property must always use the "var" keyword, even if it's read-only, 
>> and only referencing other immutable data.
>> 
>> class Test {
>> 
>> 
>> let hello = "hello"
>> 
>> 
>> let world = "world"
>> 
>> 
>> var phrase: String { //why must this be 'var'?
>> 
>> 
>> return self.hello + self.
>> world
>> 
>> }
>> }
>> It would be more appropriate for such a read-only, immutable property, to 
>> use the "let" syntax, so that its immutability is correctly expressed.
>> 
>> Thoughts?
>> ___
>> 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] [proposal] Allow "let" for computed properties which only reference immutable data

[Rod Brown via swift-evolution]

I believe the reason behind this comes down to the fact that computed values 
generally won't be used in this way - thus the "computed".

var itself isn't a promise that a value is mutable, so much as 'let' is a 
promise of immutability. If we allowed this, then the compiler must check that 
each element of the return value is static and will not change, and in that 
case, why would you not just store the computer value in a true let to begin 
with, to avoid doing the work over again on each access?

It seems a somewhat rare and complicated case for the compiler, for little if 
any benefit.

-Rod

> On 11 May 2016, at 11:25 PM, Alexander Momchilov via swift-evolution 
>  wrote:
> 
> I came an interesting SO question which pointed out a strange quirk: a 
> computed property must always use the "var" keyword, even if it's read-only, 
> and only referencing other immutable data.
> 
> class Test {
>   let hello = "hello"
>   let world = "world"
>   var phrase: String { //why must this be 'var'?
>  return self.hello + self.world
>   }
> }
> It would be more appropriate for such a read-only, immutable property, to use 
> the "let" syntax, so that its immutability is correctly expressed.
> 
> Thoughts?
> ___
> 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] Allow "let" for computed properties which only reference immutable data

[Sean Heber via swift-evolution]

I kind of agree with the logic of that, but imagine the following:

class Test {
  let hello = “hello”
  var subject = “world”
  var phrase: String { return hello + “, “ + subject }
}

In this scenario, “subject” can be changed.. and that changes the result of 
“phrase”. Things like this are why computed properties are “var”.

l8r
Sean


> On May 11, 2016, at 8:25 AM, Alexander Momchilov via swift-evolution 
>  wrote:
> 
> I came an interesting SO question which pointed out a strange quirk: a 
> computed property must always use the "var" keyword, even if it's read-only, 
> and only referencing other immutable data.
> 
> class Test {
> 
>   
> let hello = "hello"
> 
>   
> let world = "world"
> 
>   
> var phrase: String { //why must this be 'var'?
> 
>  
> return self.hello + self.
> world
>   
> }
> }
> It would be more appropriate for such a read-only, immutable property, to use 
> the "let" syntax, so that its immutability is correctly expressed.
> 
> Thoughts?
> ___
> 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

[Evan Maloney via swift-evolution]

>> It feels wrong to allow garbage syntax lying around in one's code simply for 
>> the sake of occasional convenience.
> 
> Would you then recommend removing trailing comma support for collections on 
> the same principle?

Yes.

___
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 11, 2016, at 9:08 AM, Evan Maloney via swift-evolution 
>  wrote:
> 
> It feels wrong to allow garbage syntax lying around in one's code simply for 
> the sake of occasional convenience.

Would you then recommend removing trailing comma support for collections on the 
same principle?

-- E

___
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

[Anders Ha via swift-evolution]

1. What is your evaluation of the proposal?

+1 on the proposal’s objective - the swiftification of libdispatch is greatly 
appreciated. But I have reservation in the particulars of the proposal which 
are not in line with the API Design Guidelines.

For example, the `getSpecific(_:)` instance method in `DispatchQueue` is 
supposed to have no side effect like `NSObject.value(_:)` - just the retrieval 
of the value. But it somehow has a `get` suffix in the method name. Likewise, 
the class function `getSpecific(_:)` has a similar issue, but also not 
describing the behaviour precisely enough. Shouldn’t it be something 
like`specificForCurrentQueue(_:)`?

On the other hand, The adverbs used by `synchronously(_:)` and 
`asynchornously(_:)` in `DispatchQueue` fits nowhere in the guidelines, which 
(generally speaking) requires either imperative verb for functions having 
side-effects, or nouns for whatever else. Both functions clearly have a side 
effect on the queue, be it performing atomics or appending a block. IMO these 
should be verbs describing the behaviour, like `sync`, `synchronize`, 
`perform`, `performAndWait`, `schedule` or `run`.


queue.synchronously(block)   // Is this grammatical? :-[  


One may argue these adverbs are term of arts, but then why not simply use the 
short form (`async` and `sync`) from the C API, which is less verbose and could 
even possibly be implied as imperative verbs? Say `async` and `sync` as a 
shorthand of `asynchronize` * and `synchronise`.

* this doesn’t formally exist… yet.

2. Is the problem being addressed significant enough to warrant a change to 
Swift?
Yes. It should improve the experience of Swift developers, since libdispatch is 
heavily used in the Cocoa platforms. Autocompletion would have less noise, and 
the interface is cleaner to work with.

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

4. If you have used other languages or libraries with a similar feature, how do 
you feel that this proposal compares to those?
There are a few wrappers on GitHub that serves a similar purpose. But it is 
always great to have less dependency, especially for things that are essential 
like libdispatch.

5. How much effort did you put into your review? A glance, a quick reading, or 
an in-depth study?
A focused study on the `DispatchQueue` renaming, since it would be the thing 
affecting me the most.

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

[Darren Mo via swift-evolution]

Great, this is the libdispatch API that I’ve been dreaming about! I think it 
meshes well with the rest of Swift.

I am concerned about one thing though: the naming of the DispatchGroup methods 
synchronously/asynchronously.

1. They are hard to type correctly and ugly to look at.
2. sync/async are already well-established abbreviations in the tech industry.
3. They are adjectives without verbs, which goes against the API Design 
Guidelines.

I suggest sticking with the naming from the C API. For example:

let queue = …
queue.dispatchAsync {
   …
}
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

That explanation is succinct and cogent. I can see the need for this
proposed behavior. Having just played around with conforming classes to
protocols, I think #Self is rather clear, but Type would be a little
mystifying.

On Wed, May 11, 2016 at 08:43 Matthew Johnson via swift-evolution <
swift-evolution@swift.org> wrote:

>
>
> Sent from my iPad
>
> > On May 11, 2016, at 1:22 AM, Vladimir.S  wrote:
> >
> > > No, class would not need to be final to conform to a requirement
> returning #Self.  The difference is that with Self covaries and #Self does
> not.  This means you *do not need* to guarantee that all subclasses
> override a requirement that returns #Self, while you do need to guarantee
> that all subclasses override a requirement that returns Self.
> >
> > I'm probably slow these day, but I(and probably someone else) just can't
> understand this. Thank you for your patience in explaining this:
> > Just after you conforms *base* class to *any* protocol, any possible
> subclass *must* (you *have to* guarantee this) conform the same protocol.
> >
> > class A {..}
> > class B:A {..}
> > class C:A {..}
> > protocol D {..}
> > extension A: D {}
> > -> now B&C and any other existed and *possible* subclass *must* conforms
> to the same protocol D just because of inheritance. As soon as they are
> subclass of A, they *must* be `is D` and *must* have the methods that
> return #Self. No?
>
> Yes, they must and will conform.  The distinction is that if the protocol
> has requirements returning Self all subclasses must override those
> requirements and to return their type because the inherited implementation
> returns their supertype.  With #Self (or Type as we're now calling it) they
> would not need to override those requirements because the ancestor that
> initially declared conformance provides an inherited implementation that
> remains valid for all of its descendants.
>
> >
> >> On 10.05.2016 22:04, Matthew Johnson wrote:
> >>
> >>> On May 10, 2016, at 1:38 PM, Vladimir.S  wrote:
> >>>
> >>> On 10.05.2016 20:50, Matthew Johnson wrote:
>  No, the whole point is that D.f() returns C because C is the
> requirement
>  of 'f' is declared to return #Self which is C where the protocol
>  conformance is declared and implemented.  If you want a covariant
>  requirement you would use Self as the return type, not #Self.
> >>>
> >>> I just followed your example with NSURL.. Probably I don't understand
> the point, but you said you want to conform a non-final class to protocol
> with method -> #Self.
> >>>
>  -<
> >>> protocol A { static func createWithString(s: String) -> Self }
> >>> extension NSURL: A { // cannot conform because NSURL is non-final }
> >>>
> >>> If we could define a protocol requirement that didn't covary (using
> >>> #Self or whatever) we would be able to write the desired conformance.
>  -<
> >>>
> >>> And I don't understand how do you want to achieve the target, as even
> if we 'invent' #Self, this (as I understand) can't work as class is not
> final. Just like with 'simple' Self - class must be final to conform. Thank
> you for clarification.
> >>
> >> No, class would not need to be final to conform to a requirement
> returning #Self.  The difference is that with Self covaries and #Self does
> not.  This means you do not need to guarantee that all subclasses override
> a requirement that returns #Self, while you do need to guarantee that all
> subclasses override a requirement that returns Self.
> >>
> >> The requirement to guarantee that all subclasses provide this override
> is the reason you cannot declare conformance in the case of requirements
> returning Self.  Since this isn’t necessary for #Self (will probably have a
> different name) the class does not need to be final in order to conform.
> >>
> >> -Matthew
> >>
> >> .
> >>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Sean Heber via swift-evolution]

I don’t know if this is a problem per-say, but very likely the API would often 
be used in code looking more like this:

DispatchQueue.main.dispatchAsynch {
 // stuff
}

And maybe this is just me, but the double occurrence of the word “dispatch” in 
there rubs me the wrong way. :P

This is probably silly, but we’re dealing with a “queue” here, so in some ways, 
could’t we “add” work to the queues or something?

DispatchQueue.main.add(.asynchronously) {
 // async..
}

l8r
Sean


> On May 11, 2016, at 10:10 AM, Cole Campbell via swift-evolution 
>  wrote:
> 
>> My main piece of feedback is that the method names synchronously() and 
>> asynchronously() don’t conform to Swift 3 naming conventions for functions 
>> and methods:
> 
> I agree.
> 
>> dispatchAsynch()
>> dispatchSynch()
> 
> I prefer something like this. It feels more Swifty. As it is, they aren't any 
> longer than asynchronously(), if name length is a concern.
> ___
> 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] Allow function argument type to be omitted when passing a default value from which it can be inferred

[Haravikk via swift-evolution]

> On 11 May 2016, at 14:59, Vladimir.S  wrote:
> 
> On 11.05.2016 16:03, Haravikk wrote:
>> 
>>> On 11 May 2016, at 13:49, Vladimir.S via swift-evolution
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> public var a = 10 // OK, all is clear here
>>> public var a = "sdfsdf" // OK
>>> public var a = someFunction() // not OK - add type of `a` explicitly
>> 
>> I’m not clear on why you think the third one isn’t okay; Xcode can tell you
>> what the type was inferred to be, you can check the function signature (alt
>> - click the name) which will tell the type that it returns, as well as call
>> up any documentation about what it does.
> 
> Well.. First of all Swift != XCode, and the OSX is not the only system where 
> Swift is used ;-)

I don’t disagree, but nor is Xcode unique in helping to figure out what a type 
is; I think it’s okay to consider that any good modern IDE should be able to 
tell us what a type is if the compiler can. Besides, in the example, 
someFunction() could be buried somewhere hard to find, sure, or it could also 
be declared clearly earlier in the same file, or in a commonly used file for 
that module, in which case it’s probably very well known. I think it’s fine to 
infer the type in these cases because forcing the developer to supply it may 
not add anything, and in cases where it does it’s easy enough to just do this 
yourself; even if you’re maintaining unfamiliar code, it shouldn’t take long to 
look up the type and add it for others if you really feel you have to, but 
again, any good IDE should render it a non-issue.


As to the original issue (realised I hadn’t commented on it yet), I’m 
undecided; I like type inference for declarations as inference is very common 
for these, and I myself usually only supply a type if there’s ambiguity or I 
want something to become optional. My main concern is that default parameter 
values are relatively rare (compared to those without them), so it becomes an 
issue of consistency for me.
It might be different if for example we could omit type when it can inferred by 
other means as well, for example:

protocol FooType {
func someMethod(value:String) -> Void
}

struct Foo : FooType {
func someMethod(value) -> Void { … } // value is a String
}

But I’m not sure if I’d want to do that or not. Generally I like things that 
shorten function signatures, but on its own I’d prefer consistency over 
inference in this case I think.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0074: Implementation of Binary Search functions

[Daniel Vollmer via swift-evolution]

> On 10 May 2016, at 19:36, Joe Groff via swift-evolution 
>  wrote:
> 
> I worry that attaching these methods to a strongly-typed `Sorted` wrapper 
> limits their appeal. It's useful to be able to binary-search through data in 
> a standard container that's known to be sorted, or over a subregion of the 
> data that's sorted. While you can of course cobble together a 
> Sorted(Slice(container[sortedRange])), that's pretty inconvenient. Is 
> misapplying binary search algorithms to unsorted data a big problem in 
> practice in C++?

I agree with Joe here, just look at the recursive construction of a kd-tree 
where you recursively sort (and then search for a partitioning point) in 
smaller and smaller slices sorted along different dimensions.

I don’t think misapplying is a big problem in C++.

Daniel.

___
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

[Cole Campbell via swift-evolution]

> My main piece of feedback is that the method names synchronously() and 
> asynchronously() don’t conform to Swift 3 naming conventions for functions 
> and methods:

I agree.

> dispatchAsynch()
> dispatchSynch()

I prefer something like this. It feels more Swifty. As it is, they aren't any 
longer than asynchronously(), if name length is a concern.___
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

[Erica Sadun via swift-evolution]

> On May 11, 2016, at 8:01 AM, Ricardo Parada via swift-evolution 
>  wrote:
>> On May 10, 2016, at 2:53 PM, Chris Lattner > > 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
>>  
>> 
> 
>>  * What is your evaluation of the proposal?
> 
> -1
> 
> I don’t like the proposal.  I understand the flexibility it gives to 
> rearranging elements but to someone reading the code it looks like an element 
> was removed by mistake.


This objection is coming up quite often and I don't really see the difference 
between trailing commas in collections (legal in Swift)

let listenerKeys: NSDictionary = [
AVFormatIDKey: NSNumber(unsignedInt: kAudioFormatAppleLossless),
AVSampleRateKey: 44100.0,
AVNumberOfChannelsKey: 1,
AVEncoderAudioQualityKey: NSNumber(int: Int32(AVAudioQuality.Max.rawValue)),
]

And trailing commas in parameter lists (not yet allowed in Swift):

public convenience init(
_ w: CGFloat,
_ h: CGFloat,
position: CGPoint = .zero,
backgroundColor: UIColor = UIColor.whiteColor(),
translucency alpha: CGFloat = 1.0,
borderWidth: CGFloat = 0.0,
borderColor: UIColor = UIColor.blackColor(),
cornerRadius: CGFloat = 0.0, // this is currently illegal
){
...
}

Neither example reads to me as if an element was removed by mistake. Both 
greatly enhance programming flexibility. Both allow the final comma to be 
omitted and/or the elements to be re-ordered.

To summarize the complaints to date:

* It make code read like errors
* Arrays and dictionaries are different "things" than parameters and tuples; 
They are structurally different
* Parameter lists should always be of fixed size at deployment time; Once a 
signature is fixed and consumed, it's difficult to change

To which I reply:

* Well structured code needn't read like an error. The examples above show an 
in-house style that allows final commas. Your in-house style may differ and a 
linter can catch these issues.
* Both collections and signatures are syntactically similar in layout even if 
they are semantically different in use. In Swift, complex method signatures 
with defaulted arguments like the example shown are not uncommon. Do not limit 
your thinking to single line lists of (x: T, y: U, z: V) signatures.
* Parameter lists and function signatures, like collections, can evolve, 
especially when using defaulted parameters, even when they are consumed at 
multiple points.

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

[Evan Maloney via swift-evolution]

> * What is your evaluation of the proposal?

-1. 

It feels wrong to allow garbage syntax lying around in one's code simply for 
the sake of occasional convenience. It's like littering on the sidewalk because 
it's easier than throwing something in a trash can.

Because commas are allowed in several places, and because there is no 
consistent way to allow a trailing commas throughout the language without 
allowing at least some scenarios in which a trailing comma would change the 
meaning of the code, it is not safe for the Swift compiler to assume that a 
trailing comma is intentional and not a mistake. Doing so would shift a 
compile-time error to runtime.

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

No. Not terminating a list with a comma is about as much of a "problem" as 
having to terminate strings with a quote.

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

Making Swift more forgiving of bad syntax does not feel very Swifty to me.

Allowing trailing commas everywhere comma separation is used would be 
consistent, but would make Swift less strict and less safe. Allowing trailing 
commas only in those places where they could not possibly affect runtime 
behavior would be safer, but would make the language less consistent. Either 
option is sub-optimal.

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

I've never used the feature in any other language, because I don't find 
trailing commas visually appealing. They make the code look the developer 
forgot to finish working on it.

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

You could use dispatch(), and name the synchronous method something else? 
synchronize() or its shortened form sync(), which is a real word, or maybe 
wait(). (However, there was a beauty in the yin-yang of async/sync in the 
original API. I would call them terms of art, like map, filter, reduce, etc)


class DispatchQueue : DispatchObject {
func synchronize(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.synchronize {
print("Hello World")
}


> On 12 May 2016, at 12:50 AM, James Dempsey via swift-evolution 
>  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 
>>> mailto: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

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