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

Hey Jacob, I agree with you that there are some unanswered questions and areas we would need some more polish on, but libdispatch was a bit unwieldy in Objective-C already and when used as is in Swift code it looks to be even less user friendly and not because it has to, but because of a lack o

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

I like those a lot. Crystal clear. > On 11 May 2016, at 05:14, Patrick Smith via swift-evolution > wrote: > > How about: > > Consuming (from) > Producing (to) > > > IntegerLiteralConsuming > StringLiteralConsuming > > CustomStringProducing > CustomDebugStringProducing > > > As for somethi

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

Thanks for all your feedback! This is the current statistic: Closure syntax: All positive Function syntax: 3 (or 4) positive, 2 negative I’ll try to address the concern Geordie and T.J. have. > func takesATuple(someInt: Int, tuple: (valueA: String, valueB: String)) {} > It’s true that you still

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

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 t

Re: [swift-evolution] Change `repeat` to loop indefinitely if no while clause is present

> On May 10, 2016, at 9:11 PM, Tyler Cloutier via swift-evolution > 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

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

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

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

I completely disagree with what you said. It sounds extreme to me to release a v1 of a library without giving yourself the flexibility to iterate on it beforehand. > On 11 May 2016, at 08:30, Drew Crawford via swift-evolution > wrote: > > I'm one of the largest dispatch-on-linux users right n

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

> On May 11, 2016, at 6:34 AM, David Hart wrote: > > It sounds extreme to me to release a v1 of a library without giving yourself > the flexibility to iterate on it beforehand. Dispatch is already released (on two platforms). So that ship sailed in 2010. The question in front of us is wheth

Re: [swift-evolution] [proposal] Treat (case .Foo = bar) as a Boolean expression

Am 11. Mai 2016 um 05:31 schrieb Chris Lattner via swift-evolution : On May 10, 2016, at 4:33 AM, Sam Dods via swift-evolution wrote: I propose that (case .Foo = bar) should be treated as an expression with a Boolean value, so the result can be set to a variable or returned from a method

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

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 de

Re: [swift-evolution] [proposal] Treat (case .Foo = bar) as a Boolean expression

Btw, do we have now any proposal now for enums improvement in Swift3 ? On 11.05.2016 6:31, Chris Lattner via swift-evolution wrote: On May 10, 2016, at 4:33 AM, Sam Dods via swift-evolution mailto:swift-evolution@swift.org>> wrote: I propose that *(case .Foo = bar)* should be treated as an ex

[swift-evolution] Pitch: Soft unwrapping of optionals

Forcing unwrapping of optionals is bad practice, but safely unwrapping can be tedious. I’m hoping for something in between that would that would provide soft unwrapping using a syntax like: myVar?! For example, currently we have to do this: let temp = (myString ?? “”); print(“\(temp)”) if (mySt

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

+1 for the classification of the protocols to be renamed I completely agree that you can divide the protocols being examined into those categories and I appreciate the effort put in to doing so. -1 for the names chosen == The new Representable is being applied to - CustomStringConvertibl

Re: [swift-evolution] Pitch: Soft unwrapping of optionals

I actually think this is less safe. It depends on the situation for what value the default should be. Sometimes it will be false, other times it will be true. So far better to explicitly show what the default is. > On 11 May 2016, at 10:16 PM, Basem Emara via swift-evolution > wrote: > > For

Re: [swift-evolution] Pitch: Soft unwrapping of optionals

The immediate problem I see with your suggestion is the reason why optionals in Swift are pretty damned awesome: Swift doesn't have default values. A Bool is not false by default; the Swift compiler will complain if you don't initialise a Bool variable with a value, one way or the other. The idea

Re: [swift-evolution] Pitch: Soft unwrapping of optionals

Maybe I’m missing something, but aren’t these the default values of primitives deep in the language? String = “” Int = 0 Boolean = false So if you needed a different default value for your code, you’d do: if !myBool?! {…} //Default to true in my app You can still do which is better: if myBool ??

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

* What is your evaluation of the proposal? -1. I support the opinion that dictionary/array is different "thing" than parameters in functions/methods and parameters in tuples. * Is the problem being addressed significant enough to warrant a change to Swift? I don't think so

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

Am 10. Mai 2016 um 20:11 schrieb Matthew Johnson : Sent from my iPad On May 10, 2016, at 12:59 PM, Thorsten Seitz wrote: Am 10.05.2016 um 18:41 schrieb Timothy Wood via swift-evolution : On May 10, 2016, at 9:28 AM, Matthew Johnson wrote: Yep, understood. It's perfectly clear t

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

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

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

I +1 the proposal. If it doesn’t make the compiler more complicated, and its a purely opt-in feature for writers, then I don’t why it couldn’t literally extend to everywhere there’s a comma-separated list as a general rule. > On 11 May 2016, at 6:57 AM, Rob Napier via swift-evolution > wrote:

Re: [swift-evolution] Pitch: Soft unwrapping of optionals

Yes, having to be explicit is the whole point about optionals: having to think about what the missing case means in the current context. -Thorsten   Am 11. Mai 2016 um 14:20 schrieb Patrick Smith via swift-evolution : I actually think this is less safe. It depends on the situation for wh

[swift-evolution] Re-Visit Proposal: Weak Native Swift Containers (12 2015)

Hello, I'd like to re-visit a proposal from Riley Testut about weak containers. Since no conclusion/outcome was achieved (AFAICS from looking at the archives and the repository) and since I just would have needed this again too... I found it a good time to re-propose this :D --- " In mult

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

> On 11 May 2016, at 13:49, Vladimir.S via swift-evolution > 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

Re: [swift-evolution] Pitch: Soft unwrapping of optionals

I think what you’re referring to as default values would be what you get if you initialize the type directly. eg: let integer = Int() // integer = 0 let string = String() // string = “” let bool = Bool()// bool = false That said, I’m going to -1 this proposal as well.

Re: [swift-evolution] Pitch: Soft unwrapping of optionals

Thanks for the input everybody, and for the deeper analysis, Rod. It’s set straight in my mind now and have even a greater appreciation of optionals than before thanks to this discussion. Let’s scrape this pitch :) Happy coding! -Basem > On May 11, 2016, at 9:10 AM, Rod Brown wrote: > > I thi

Re: [swift-evolution] Pitch: Soft unwrapping of optionals

Ha great stuff Basem! Glad we could help :) Look forward to your next proposal! > On 11 May 2016, at 11:17 PM, Basem Emara wrote: > > Thanks for the input everybody, and for the deeper analysis, Rod. > > It’s set straight in my mind now and have even a greater appreciation of > optionals than

Re: [swift-evolution] Re-Visit Proposal: Weak Native Swift Containers (12 2015)

I’ve used the following in some similar cases: struct Weak { weak var value:T? init(_ value:T) { self.value = value } } let myCache = Array>() When inserting new values I just look for the first one that’s nil or append if it’s taking too l

Re: [swift-evolution] Change `repeat` to loop indefinitely if no while clause is present

> On 10 May 2016, at 22:27, Tyler Cloutier via swift-evolution > wrote: > >> > And isn’t this the point really. Yes there are many different ways of doing > something, but there should be one obvious way. IMHO, there is nothing more > obvious than just > > repeat { > > } Yes there is:

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

Sent from my iPad > On May 10, 2016, at 9:33 PM, Erica Sadun wrote: > > >> On May 10, 2016, at 6:51 PM, Chris Lattner via swift-evolution >> wrote: >> >> >>> On May 10, 2016, at 11:48 AM, Chris Lattner wrote: >>> >>> Hello Swift community, >>> >>> The review of "SE-0041: Updating Proto

Re: [swift-evolution] Re-Visit Proposal: Weak Native Swift Containers (12 2015)

I remember reading that Swift’s weak references are ‘lazy’, and only clear (and release if needed) when they are next accessed. So you couldn’t observe them AFAIK. > On 11 May 2016, at 11:23 PM, Haravikk via swift-evolution > wrote: > > I’ve used the following in some similar cases: > >

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

+1, I like this one a lot. -Matt > On May 10, 2016, at 21:25, David Waite via swift-evolution > wrote: > >> >> https://github.com/apple/swift-evolution/blob/master/proposals/0081-move-where-expression.md >> >> * What is your evaluation of the proposal? > +1, I like the syntax and t

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

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: "Name functions and methods according to their side-effects • Those without side-effects should read as noun phrases, e.g. x.di

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

Sent from my iPad > On May 11, 2016, at 7:33 AM, Thorsten Seitz wrote: > > > >> Am 10. Mai 2016 um 20:11 schrieb Matthew Johnson : >> >> >> >> Sent from my iPad >> On May 10, 2016, at 12:59 PM, Thorsten Seitz wrote: > Am 10.05.2016 um 18:41 schrieb Timothy Wood via

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

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 ove

Re: [swift-evolution] Re-Visit Proposal: Weak Native Swift Containers (12 2015)

Associated object based tricks may be used in the meantime, KVO on objects with an uncertain duration was always problematic. Sent from my iPhone > On 11 May 2016, at 14:30, Patrick Smith via swift-evolution > wrote: > > I remember reading that Swift’s weak references are ‘lazy’, and only cle

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

> 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

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

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

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

Resending to the list (thanks, Vladimir!) -Thorsten Anfang der weitergeleiteten E‑Mail: > Von: "Vladimir.S" > Datum: 11. Mai 2016 um 14:58:33 MESZ > An: Thorsten Seitz > Betreff: Re: [swift-evolution] [Review] SE-0084: Allow trailing commas in > parameter lists and tuples > > Thorsten, as I

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

I like the idea. I didn't see these function but I am not sure if they are part of that library. dispatch_queue_create("uniqueName", DISPATCH_QUEUE_CONCURRENT) dispatch_apply(someInt, queue){ > On May 10, 2016, at 9:39 PM, Chris Lattner via swift-evolution > wrote: > > Hello Swift com

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

> On May 10, 2016, at 11:52 PM, Jacob Bandes-Storch via swift-evolution > wrote: > > > * What is your evaluation of the proposal? > > I'm generally in favor of a modernized API overlay like this (and I've > written something like it myself, albeit much simpler), but I'm hoping this

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

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

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

> 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

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

On 11.05.2016 16:42, Matthew Johnson wrote: 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. OK.. I see you

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

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

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

Sent from my iPad > On May 11, 2016, at 9:33 AM, Vladimir.S wrote: > >> On 11.05.2016 16:42, Matthew Johnson wrote: >> 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 inhe

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

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

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

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 chara

Re: [swift-evolution] Pitch: Soft unwrapping of optionals

I too agree the unwrapping process can be tedious but I believe this is best because it forces us to check we're doing the right thing in code and prevents a lot of errors we have to keep on checking in more dynamic languages. -1 from me too. - Leonardo On 11 May 2016 at 10:19, Patrick Smith via

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

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

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

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

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

> 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

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

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

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

> 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

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

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

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

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

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

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

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

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 meth

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

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

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

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

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

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

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

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 co

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

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 e

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

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

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

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

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

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 sho

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

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 togethe

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

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

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

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

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

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 i

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

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

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

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 synchro

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

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

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

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 t

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

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

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

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

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

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.

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

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 lett

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

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 A

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

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 decla

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

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

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

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

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

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.

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

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

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

> 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 = “he

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

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 mig

Re: [swift-evolution] NSRange and Range

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 aw

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

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 ru

Re: [swift-evolution] NSRange and Range

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*

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

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

Re: [swift-evolution] NSRange and Range

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

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

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

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

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

Re: [swift-evolution] NSRange and Range

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 ho

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

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 dro

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

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 u

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

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

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

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 }

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

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 i

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

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.

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

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

  1   2   >