Re: [swift-evolution] [SE-0088] Dispatch API names

> The guideline that methods should "read as imperative verb phrases" applies > to the full name, labels and arguments and all, and not just the base name. > You'll recall that the original proposal had .asynchronously(execute:), which > is very much an imperative phrase. `.async(execute:)` was

[swift-evolution] [Pitch] Detecting and working with Optionals from Any

I've recently written a CoreData editor on iOS which automatically generates UI based on the model which is described using classes such as PrimitiveProperty, etc. Since it automatically sets the value on the entity, it needs to convert the value to AnyObject in order to pass it to setValue(_:fo

[swift-evolution] the "guard" keyword, again

In the Commonly Rejected Changes page and in this swift-evolution email to which it refers, I read that first there was “unless", then

Re: [swift-evolution] Fixing modules that contain a type with the same name

On Mon, Jun 20, 2016 at 11:12 PM, Félix Cloutier wrote: > I think that it takes some chutzpah to declare that your B-tree is > authoritative enough that it should be called "BTreeCore". > I don't know why it sounds more authoritative than `BTree` itself. If you and I both name a type `BTree` (ve

Re: [swift-evolution] Prohibit invisible characters in identifier names

> On Jun 21, 2016, at 2:23 AM, Brent Royal-Gordon via swift-evolution > wrote: > >> Perhaps stupid but: why was Swift designed to accept most Unicode characters >> in identifier names? Wouldn’t it be simpler to go back to a model where only >> standard ascii characters are accepted in identif

Re: [swift-evolution] An implicit return for guard

On Mon, Jun 20, 2016 at 10:48 PM, Yarden Eitan wrote: > The one line ‘if’ was just a known example of having the capability to > choose based on preference, and is not the core of this issue. > My point is that, as an opinionated language, Swift rejects certain options such as one-line `if` stat

Re: [swift-evolution] Fixing modules that contain a type with the same name

I think that it takes some chutzpah to declare that your B-tree is authoritative enough that it should be called "BTreeCore". I also by far prefer BTree to MyBTree or BTreePackage; of course these are all possible workarounds for a name resolution *bug*, but they certainly don't sound great to m

Re: [swift-evolution] An implicit return for guard

The one line ‘if’ was just a known example of having the capability to choose based on preference, and is not the core of this issue. If Swift doesn’t allow warnings to be suppressed, then what is @discardableResult as an example. I don’t find your last argument of it being a control flow statement

Re: [swift-evolution] An implicit return for guard

On Mon, Jun 20, 2016 at 10:04 PM, Yarden Eitan via swift-evolution < swift-evolution@swift.org> wrote: > I agree that by having different implicit ending statements (i.e. > break/return/etc.) based on context makes it more complicated and less > intuitive. Having said that, I do think that an impl

Re: [swift-evolution] An implicit return for guard

I agree that by having different implicit ending statements (i.e. break/return/etc.) based on context makes it more complicated and less intuitive. Having said that, I do think that an implicit ‘return’ with/without a warning (rather than an error), gives people the opportunity to either exclude or

Re: [swift-evolution] Fixing modules that contain a type with the same name

On Mon, Jun 20, 2016 at 9:08 PM, Félix Cloutier wrote: > I'm trying to reply to everybody in this message. > > I think that it's a rather common and intuitive thing to name a module > after its most important class, especially for small-ish packages. What > would you call a package that provides

Re: [swift-evolution] [SE-0088] Dispatch API names

On Mon, Jun 20, 2016 at 9:05 PM, Brent Royal-Gordon via swift-evolution < swift-evolution@swift.org> wrote: > > DispatchQueue.async(execute:) and DispatchQueue.sync(execute:) > > -- > > The lack of verb in the base name bothers me. The AP

Re: [swift-evolution] Fixing modules that contain a type with the same name

I'm trying to reply to everybody in this message. I think that it's a rather common and intuitive thing to name a module after its most important class, especially for small-ish packages. What would you call a package that provides a BTree, or a BigInt, and not much else? I'd also make the case

Re: [swift-evolution] Prohibit invisible characters in identifier names

On Mon, Jun 20, 2016 at 8:58 PM, John McCall via swift-evolution < swift-evolution@swift.org> wrote: > On Jun 20, 2016, at 5:22 PM, Jordan Rose via swift-evolution < > swift-evolution@swift.org> wrote: > IIRC, some languages *require* zero-width joiners (though not zero-width > spaces, which are d

Re: [swift-evolution] [SE-0088] Dispatch API names

> DispatchQueue.async(execute:) and DispatchQueue.sync(execute:) > -- > The lack of verb in the base name bothers me. The API Design Guidelines say > “methods with side-effects should read as imperative verb phrases”. You could > argue t

Re: [swift-evolution] [Proposal] Make non-escaping closures the default

I've created the PR for the proposal at https://github.com/apple/swift-evolution/pull/373. Thanks again to everyone that has discussed this so far. On Mon, Jun 20, 2016 at 8:18 PM, Joe Groff via swift-evolution < swift-evolution@swift.org> wrote: > > > On Jun 9, 2016, at 4:15 PM, Jordan Rose via

Re: [swift-evolution] Prohibit invisible characters in identifier names

> On Jun 20, 2016, at 5:22 PM, Jordan Rose via swift-evolution > wrote: > IIRC, some languages require zero-width joiners (though not zero-width > spaces, which are distinct) to properly encode some of their characters. I'd > be very leery of having Swift land on a model where identifiers can b

Re: [swift-evolution] [Proposal] Generic and `throw`ing subscripts

Closures are a valid argument to pass to a subscript. Granted, I’m not sure of a use-case, but it’s certainly something that is possible. > On Jun 20, 2016, at 5:54 PM, Dany St-Amant wrote: > > > Le 20 juin 2016 à 14:10, Robert Widmann via swift-evolution > mailto:swift-evolution@swift.org>>

Re: [swift-evolution] [Proposal] Generic and `throw`ing subscripts

> Le 20 juin 2016 à 14:10, Robert Widmann via swift-evolution > a écrit : > > This change will modify and add the following productions in the Swift grammar > > GRAMMAR OF A SUBSCRIPT DECLARATION > > subscript-declaration → subscript-head subscript-result code-block > subscript-declaration →

[swift-evolution] Make UUID conform to RawRepresentable

I’m the developer of PureSwift/SwiftFoundation on GitHub, and I originally wrote that library after WWDC 2015 because I did not expect Apple to release an Open Source version of Foundation, and also because Foundation in Swift 2.2 was class based, and not struct based. Now in Swift 3 that is all

[swift-evolution] [SE-0088] Dispatch API names

SE-0088 was accepted with revisions a month ago. However, some of the APIs just don’t feel right to me. I’ve only used DispatchQueue and DispatchSource so far, so I will only comment on those. DispatchQueue.async(execute:) and DispatchQueue.sync(execute:)

Re: [swift-evolution] Fixing modules that contain a type with the same name

Yeah! I’m working on a formal proposal that would solve the same problem. Jordan, the problem he described is exactly like the one you explained to me, haha. Now I’m a bit confused about how the proposal should be called. Have any suggestions? What title could fit the two use cases we mentioned.

Re: [swift-evolution] An implicit return for guard

> Le 20 juin 2016 à 02:30, Yarden Eitan via swift-evolution > a écrit : > > ... > > My proposal is to allow for an implicit return when no ending statement is > provided. We could take this one step further and have the compiler aware of > it’s most inner scope and see if it is a while loop

Re: [swift-evolution] Fixing modules that contain a type with the same name

I've been encouraging Paulo Faria to mention this case in his push for a way to disambiguate extension methods, with the thought being we could then use the same syntax to differentiate top-level names as well. I'd also be happy with the "import as" syntax. The underscore syntax seems a little

Re: [swift-evolution] Prohibit invisible characters in identifier names

> Perhaps stupid but: why was Swift designed to accept most Unicode characters > in identifier names? Wouldn’t it be simpler to go back to a model where only > standard ascii characters are accepted in identifier names? I assume it has something to do with the fact that 94.6% of the world's pop

Re: [swift-evolution] Prohibit invisible characters in identifier names

IIRC, some languages require zero-width joiners (though not zero-width spaces, which are distinct) to properly encode some of their characters. I'd be very leery of having Swift land on a model where identifiers can be used with some languages and not others; that smacks of ethnocentrism. Jorda

Re: [swift-evolution] [Proposal] Make non-escaping closures the default

> On Jun 9, 2016, at 4:15 PM, Jordan Rose via swift-evolution > wrote: > >> >> On Jun 9, 2016, at 16:10, John McCall wrote: >> >>> On Jun 9, 2016, at 3:43 PM, Jordan Rose via swift-evolution >>> wrote: >>> >>> I'm against this for library evolution reasons: if someone releases a >>> vers

Re: [swift-evolution] [Proposal] Generic and `throw`ing subscripts

They are quite related considering a subscript can have a getter-setter pair. Brent already has a proposal to cover throwing properties (and subscripts), so we’re overlapping in that regard. > On Jun 20, 2016, at 1:33 PM, David Rönnqvist > wrote: > > Would this proposal in any way be relate

Re: [swift-evolution] Stdlib closure argument labels and parameter names

> A couple of weeks ago we started to notice that we had some poorly-named > closure parameters and argument labels in the standard library, so we > did a complete audit of the standard library's APIs and came up with a > preliminary proposal for changes, which we applied in a branch and you > can

Re: [swift-evolution] Prohibit invisible characters in identifier names

Perhaps stupid but: why was Swift designed to accept most Unicode characters in identifier names? Wouldn’t it be simpler to go back to a model where only standard ascii characters are accepted in identifier names? > On 20 Jun 2016, at 20:26, Vladimir.S via swift-evolution > wrote: > > Very in

Re: [swift-evolution] [Proposal] Generic and `throw`ing subscripts

I may be wrong, but I think this proposal will not be merged or scheduled for review until August as it seems like post-Swift 3 material. > On 20 Jun 2016, at 20:10, Robert Widmann via swift-evolution > wrote: > > Good morning all. Attached is the proposal Harlan Haskins and I will be > subm

Re: [swift-evolution] Prohibit invisible characters in identifier names

On Mon, Jun 20, 2016 at 5:20 PM, João Pinheiro wrote: > > > On 20 Jun 2016, at 22:44, Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote: > > I'm a little concerned about cases like these: > > > > 1D6CE ; 0076 ; MA # ( 𝛎 → v ) MATHEMATICAL BOLD SMALL NU → > LATIN S

Re: [swift-evolution] Prohibit invisible characters in identifier names

On Mon, Jun 20, 2016 at 4:44 PM, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > on Mon Jun 20 2016, Xiaodi Wu wrote: > > > On Mon, Jun 20, 2016 at 2:42 PM, João Pinheiro > > wrote: > > > >> I agree that treating zero-width spaces as non-existent would be a > >> possibl

Re: [swift-evolution] An implicit return for guard

I think I understand Yarden. I did some C# recently, which does not have *implicit* switch case fall-through and forces you to end all switch case bodies with break (for clarity I guess). It felt redundant coming from Swift. I understand why Adrian would feel the same way about void-return state

Re: [swift-evolution] [Pitch] remove(at: Set)

on Sun Jun 19 2016, Haravikk wrote: >> On 19 Jun 2016, at 11:12, Haravikk via swift-evolution >> wrote: >> >> I think the following should work for the generic case, and is pretty >> similar: >> >> extension MutableCollection { >> public mutating func remove(indices: Set) { >>

Re: [swift-evolution] Prohibit invisible characters in identifier names

> On 20 Jun 2016, at 22:44, Dave Abrahams via swift-evolution > wrote: > I'm a little concerned about cases like these: > > 1D6CE ; 0076 ; MA # ( 𝛎 → v ) MATHEMATICAL BOLD SMALL NU → LATIN > SMALL LETTER V # →ν→ > 1D6D2 ; 0070 ; MA # ( 𝛒 → p ) MATHEMATICAL BOLD SMALL

Re: [swift-evolution] [Draft] Apply -ed/-ing rule to core functional methods (e.g. filter => filtered)

on Mon Jun 20 2016, Brent Royal-Gordon wrote: >>> And as I said, if we feel `filter` is unsalvageable, the alternate >>> Smalltalk-lineage `select` is clearer. >> >> Than “where?” > > No, than "filter". "filter" is the most common name, but "select" is > also fairly popular, and doesn't have th

Re: [swift-evolution] [Draft] Apply -ed/-ing rule to core functional methods (e.g. filter => filtered)

>> And as I said, if we feel `filter` is unsalvageable, the alternate >> Smalltalk-lineage `select` is clearer. > > Than “where?” No, than "filter". "filter" is the most common name, but "select" is also fairly popular, and doesn't have the same ambiguity issues as "filter". "where" is slightly

Re: [swift-evolution] Prohibit invisible characters in identifier names

on Mon Jun 20 2016, Xiaodi Wu wrote: > On Mon, Jun 20, 2016 at 2:42 PM, João Pinheiro > wrote: > >> I agree that treating zero-width spaces as non-existent would be a >> possible solution, but I think it would make more sense to consider it as >> white space and thus not admissible in identifie

Re: [swift-evolution] [Draft] Apply -ed/-ing rule to core functional methods (e.g. filter => filtered)

on Thu Jun 16 2016, Patrick Pijnappel wrote: >> >> -1, for the same reasons stated on the thread. These are neither >> guaranteed to be mutating or non-mutating until you get to Collection. >> Changing map() to mapped() would be lying to the developer some of the >> time about the mutability of

[swift-evolution] Stdlib closure argument labels and parameter names

Hi All, A couple of weeks ago we started to notice that we had some poorly-named closure parameters and argument labels in the standard library, so we did a complete audit of the standard library's APIs and came up with a preliminary proposal for changes, which we applied in a branch and you can

Re: [swift-evolution] [Draft] Apply -ed/-ing rule to core functional methods (e.g. filter => filtered)

on Fri Jun 17 2016, Brent Royal-Gordon wrote: >> – What sin(x) should do is unambiguous, unlike array.filter { ... }. > > A decent argument label, like `including` or even `to`, would fix the > name `filter`. x.filter(to: isPrime) ? I don't think that reads nearly as well as x.where(isP

Re: [swift-evolution] Prohibit invisible characters in identifier names

On 20 Jun 2016, at 21:07, Xiaodi Wu wrote: > > On Mon, Jun 20, 2016 at 2:42 PM, João Pinheiro > wrote: > I agree that treating zero-width spaces as non-existent would be a possible > solution, but I think it would make more sense to consider it as white space > an

Re: [swift-evolution] [Proposal] Generic and `throw`ing subscripts

Would this proposal in any way be related to `throw`ing properties (more specifically throwing setters)? Or would that be a completely different discussion/proposal? - David > On 20 Jun 2016, at 21:27, Matthew Johnson via swift-evolution > wrote: > > > > Sent from my iPhone > >> On Jun 20

Re: [swift-evolution] Prohibit invisible characters in identifier names

On Mon, Jun 20, 2016 at 2:42 PM, João Pinheiro wrote: > I agree that treating zero-width spaces as non-existent would be a > possible solution, but I think it would make more sense to consider it as > white space and thus not admissible in identifier names. > If you treat it like whitespace, the

Re: [swift-evolution] Marking sort and sorted with rethrows

on Mon Jun 20 2016, John McCall wrote: >> On Jun 20, 2016, at 9:57 AM, Dave Abrahams wrote: >> on Thu Jun 09 2016, John McCall wrote: >> On Jun 9, 2016, at 12:59 PM, Dave Abrahams wrote: on Thu Jun 09 2016, John McCall wrote: > >> On Jun 9, 2016, at 9:04 AM, Dave Abraham

Re: [swift-evolution] Prohibit invisible characters in identifier names

I agree that treating zero-width spaces as non-existent would be a possible solution, but I think it would make more sense to consider it as white space and thus not admissible in identifier names. I'm not sure of what the best way to handle left-to-right and right-to-left markers would be. Does

Re: [swift-evolution] [Discussion] File-level declarations having highest priority for shadowing

On Mon, Jun 20, 2016 at 2:17 PM, Charlie Monroe wrote: > IMHO file-level scope *is* special. Aside from the fact that some > declarations (e.g. protocols) are only valid at file-level scope, the way I > see it, it's a scope where you have *global* symbols to the file - i.e. > they should be avail

Re: [swift-evolution] [Proposal] Generic and `throw`ing subscripts

Sent from my iPhone > On Jun 20, 2016, at 1:10 PM, Robert Widmann via swift-evolution > wrote: > > Good morning all. Attached is the proposal Harlan Haskins and I will be > submitting shortly about adding generic and `throw`ing subscript declarations > to the language. +1. Thank you for

Re: [swift-evolution] Prohibit invisible characters in identifier names

On Mon, Jun 20, 2016 at 2:17 PM, João Pinheiro wrote: > Nice feature in the IBM Swift Sandbox. Xcode doesn't display zero-width > spaces either so the identifier names look exactly the same. > > The issue with left-to-right and right-to-left markers is interesting and > has previously been exploi

Re: [swift-evolution] Prohibit invisible characters in identifier names

Nice feature in the IBM Swift Sandbox. Xcode doesn't display zero-width spaces either so the identifier names look exactly the same. The issue with left-to-right and right-to-left markers is interesting and has previously been exploited in email phishing attacks. It would be possible to highlig

Re: [swift-evolution] [Discussion] File-level declarations having highest priority for shadowing

IMHO file-level scope *is* special. Aside from the fact that some declarations (e.g. protocols) are only valid at file-level scope, the way I see it, it's a scope where you have *global* symbols to the file - i.e. they should be available *globally* anywhere within the file. I undestand that th

Re: [swift-evolution] [Discussion] File-level declarations having highest priority for shadowing

I can see how this is a problem, but I don't like this solution for the same reasoning that Jordan provided in the bug. Namely, the general rule is that the inner scope shadows the outer scope. This would be a very strange exception that you're proposing. I'd rather cope temporarily with the curre

[swift-evolution] [Discussion] File-level declarations having highest priority for shadowing

I've filed this previously as a compiler bug, but was told to discuss this here (https://bugs.swift.org/browse/SR-1772). Motivation: Consider the following code: private func _validateAccount(name: String, existingAccounts: [Account]) -> Bool { // Logic goes here... } class MyController {

Re: [swift-evolution] [Proposal] Make non-escaping closures the default

Trent Nadeau via swift-evolution writes: > https://github.com/tanadeau/swift-evolution/blob/make-noescape- default/proposals/-make-noescape-default.md -1 from me. 1. One must break API and ABI compatibility to add @escaping to an existing function 2. @nonescaping case is actually quite as

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

Thanks, overlooked the proposal (or forgot about it)... will try to get some time to look it over. On Mon, Jun 20, 2016 at 11:03 AM Charles Srstka wrote: > It was deferred until after Swift 3.0. > > https://github.com/apple/swift-evolution/pull/331 > > I plan to resubmit the proposal after Swift

Re: [swift-evolution] specialize a generic type in a method

Something like this should work: protocol P1 { associatedtype T func foo(t: T) func bar(t: U) } > On Jun 20, 2016, at 8:07 PM, Vladimir.S wrote: > > Thank you for reply. Yes, seems this could be solved by extension. No other > solutions? > > But how should I be if I n

Re: [swift-evolution] Prohibit invisible characters in identifier names

Very interesting. Btw, IBM Swift Sandbox shows these spaces: https://swiftlang.ng.bluemix.net/ But my mail client does not - i.e. I saw exactly the same "test"&"abc" Also, I read about some issues with left-to-right and right-to-left markers that also somehow change the actual text of source -

Re: [swift-evolution] Prohibit invisible characters in identifier names

+1 l8r Sean > On Jun 20, 2016, at 12:51 PM, João Pinheiro via swift-evolution > wrote: > > Recently there has been a screenshot going around Twitter about C++ allowing > zero-width spaces in variable names. Swift also suffers from this problem > which can be abused to create ambiguous, misl

Re: [swift-evolution] State of @noescape ?

> On Jun 20, 2016, at 10:55 AM, Антон Жилин via swift-evolution > wrote: > IIRC, there were at least the following counter-arguments: > 1. One must break API and ABI compatibility to add @escaping to an existing > function > 2. @nonescaping case is actually quite as common as @escaping > > Fran

[swift-evolution] [Proposal] Generic and `throw`ing subscripts

Good morning all. Attached is the proposal Harlan Haskins and I will be submitting shortly about adding generic and `throw`ing subscript declarations to the language. Cheers, ~Robert Widmann Generic and Throwing Subscripts Proposal: SE-

Re: [swift-evolution] specialize a generic type in a method

Thank you for reply. Yes, seems this could be solved by extension. No other solutions? But how should I be if I need such a protocol? protocol P1 { associatedtype T func foo(t: T) func bar(t: T) // where T:Equatable ?? } I.e. I need to specify T & Equatable for bar in requirements

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

It was deferred until after Swift 3.0. https://github.com/apple/swift-evolution/pull/331 I plan to resubmit the proposal after Swift 3.0 comes out. Do you have any improvements or suggestions for it? Charles > On Jun 20, 2016, at 12:51 PM, S

Re: [swift-evolution] State of @noescape ?

IIRC, there were at least the following counter-arguments: 1. One must break API and ABI compatibility to add @escaping to an existing function 2. @nonescaping case is actually quite as common as @escaping Frankly speaking, I support both of this arguments. I'll also add another counter-argument.

[swift-evolution] Prohibit invisible characters in identifier names

Recently there has been a screenshot going around Twitter about C++ allowing zero-width spaces in variable names. Swift also suffers from this problem which can be abused to create ambiguous, misleading, and potentially obfuscate nefarious code. I would like to propose a change to prohibit the

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

I am curious on the disposition of this discussion / proposal pitch. Has any additional effort taken place since this email thread tampered off? On Sat, May 14, 2016 at 2:40 AM Charles Srstka via swift-evolution < swift-evolution@swift.org> wrote: > On May 14, 2016, at 3:51 AM, Michael Peternell

Re: [swift-evolution] State of @noescape ?

Trent Nadeau had prepared a proposal on Chris Lattner's recommendation, and there was a discussion thread a few weeks back: http://thread.gmane.org/gmane.comp.lang.swift.evolution/19756. Not sure what the outcome was. I don't see any open PRs to merge the proposal into the swift-evolution repo. A

Re: [swift-evolution] Marking sort and sorted with rethrows

> On Jun 20, 2016, at 9:57 AM, Dave Abrahams wrote: > on Thu Jun 09 2016, John McCall wrote: > >>> On Jun 9, 2016, at 12:59 PM, Dave Abrahams wrote: >>> on Thu Jun 09 2016, John McCall wrote: >>> > On Jun 9, 2016, at 9:04 AM, Dave Abrahams via swift-evolution > wrote: > on Wed J

Re: [swift-evolution] specialize a generic type in a method

This is IMHO better solved via an extension - it even makes more sense to put together methods whose use is limited only to certain generics constraint: extension Foo where I: Equatable { func bar(i: I) { /// } } > On Jun 20, 2016, at 6:57 PM, Vladimir.S via sw

Re: [swift-evolution] Fixing modules that contain a type with the same name

I'd like to suggest such alternative syntax to mention in your proposal: Module::Type On 20.06.2016 19:16, Félix Cloutier via swift-evolution wrote: If no one has anything to say, I'll be starting a proposal to introduce the _.Module.Type syntax. Félix Le 17 juin 2016 à 19:52:45, Félix Clou

Re: [swift-evolution] Marking sort and sorted with rethrows

on Thu Jun 09 2016, John McCall wrote: >> On Jun 9, 2016, at 12:59 PM, Dave Abrahams wrote: >> on Thu Jun 09 2016, John McCall wrote: >> On Jun 9, 2016, at 9:04 AM, Dave Abrahams via swift-evolution wrote: on Wed Jun 08 2016, Brent Royal-Gordon >>>

[swift-evolution] specialize a generic type in a method

Should we be able to specialize a generic type in a method, if that generic type declared in type's definition like here? : struct Foo { func bar(i: I) where I: Equatable { } // should this work? } As I understand, for concrete instance of foo: Foo, if X is not Equatable, then compiler sho

Re: [swift-evolution] Fixing modules that contain a type with the same name

I'm not sure that `_.` reads very well; it rather seems to denote that there is no module name. The most conservative change would be to prohibit module names that collide with a contained (public) type. If, later, this is found to be unduly restrictive, another syntax can be designed and added. I

Re: [swift-evolution] [Proposal] Make non-escaping closures the default

That proposal was rejected because the swift evolution is not the correct vehicle to drive changes to Apple frameworks. > On Jun 6, 2016, at 8:33 AM, Ben Rimmington via swift-evolution > wrote: > > Trent Nadeau wrote: > >> ### Imported C/Objective-C APIs >> >> Per the Core Team, most Coco

Re: [swift-evolution] Fixing modules that contain a type with the same name

If no one has anything to say, I'll be starting a proposal to introduce the _.Module.Type syntax. Félix > Le 17 juin 2016 à 19:52:45, Félix Cloutier via swift-evolution > a écrit : > > Hello all, > > I recently ran into a bug that > leaves me una

Re: [swift-evolution] An implicit return for guard

On the contrary, having a compiler error for a guard body that doesn't exit the scope is the very point of having guard. The links were for your review because the discussion on this idea has been extensive and both times reached consensus that this is not a workable idea. On Mon, Jun 20, 2016 a

Re: [swift-evolution] State of @noescape ?

Hmm, I guess you are right, there would be no point keeping @nonescaping, then. - Anton 2016-06-20 18:55 GMT+03:00 David Waite : > > On Jun 20, 2016, at 9:39 AM, Антон Жилин via swift-evolution < > swift-evolution@swift.org> wrote: > * Rename @noescape to @nonescaping, and make @nonescaping the

Re: [swift-evolution] State of @noescape ?

> On Jun 20, 2016, at 9:39 AM, Антон Жилин via swift-evolution > wrote: > * Rename @noescape to @nonescaping, and make @nonescaping the default case Do you mean replace @noescape with its opposite, @escaping? -DW signature.asc Description: Message signed with OpenPGP using GPGMail __

[swift-evolution] State of @noescape ?

There were at least two possible solutions: * Rename @noescape to @nonescaping * Rename @noescape to @nonescaping, and make @nonescaping the default case Everyone agrees that we would better resolve issues with @noescape until Swift 3. Has anyone prepared a proposal? Has anyone submitted a pull re

Re: [swift-evolution] Thoughts on clarity of Double and Float type names?

On Jun 20, 2016, at 7:22 AM, Ben Rimmington via swift-evolution wrote: > DEC64 > as the default number type! At some danger of going off on a tangent, I should point out that DEC64 has very little to recommend it. It’s not much more efficient performance-w

Re: [swift-evolution] An implicit return for guard

Adrian: I would prefer to not have it at all. But this is a better alternative than a brand new line declaring a return, and nothing else. This is inline and part of the ‘guard’ declaration (better context), and definitely better than having a warning stay in your codebase. Putting the code clarit

Re: [swift-evolution] generic typealias inside generic type

On 19.06.2016 7:52, Chris Lattner wrote: On Jun 17, 2016, at 11:06 AM, Vladimir.S via swift-evolution wrote: Please consider this code: struct Foo { typealias Group = (key:Key, group:[Value]) func bar(u: U, v: V) -> Foo> { return Foo>() } } It will not compile: cannot spe

Re: [swift-evolution] [Pitch] Allow use of the name "default" for enum cases and function names

Also didn't know `case _: ` works as `default`. So we have 2 things that do exactly the same. Agree, that leaving `case _:` and removing 'default' will increase the consistency of the language. I even think `case _:` is better than `default` in any way. Don't agree that this case confuse anybody

Re: [swift-evolution] generic typealias inside generic type

On 19.06.2016 7:52, Chris Lattner wrote: On Jun 17, 2016, at 11:06 AM, Vladimir.S via swift-evolution wrote: Please consider this code: struct Foo { typealias Group = (key:Key, group:[Value]) func bar(u: U, v: V) -> Foo> { return Foo>() } } It will not compile: cannot spe

Re: [swift-evolution] Thoughts on clarity of Double and Float type names?

I hope it's not too late to submit a proposal. [stdlib/public/core/FloatingPointTypes.swift.gyb] public struct Float32: BinaryFloatingPoint public struct Float64: BinaryFloatingPoint public struct

Re: [swift-evolution] LibDispatch : access to current queue, or queue name

I stand corrected! "currentLabel" would be my prevailing suggestion, then. -- Gwynne Raskind > On Jun 20, 2016, at 04:51, Ben Rimmington wrote: > > >> On 20 Jun 2016, at 10:14, Gwynne Raskind wrote: >> >> dispatch_queue_get_label() isn’t marked as a for-debugging-only API as far >> as I c

Re: [swift-evolution] LibDispatch : access to current queue, or queue name

> On 20 Jun 2016, at 10:14, Gwynne Raskind wrote: > > dispatch_queue_get_label() isn’t marked as a for-debugging-only API as far as > I can see, and I can see uses in non-debugging contexts (logging is the > obvious one) for knowing the current queue’s label (without also allowing the > error

Re: [swift-evolution] [Discussion] access control modifier inconsistency

> On Jun 20, 2016, at 10:35 AM, Adrian Zubarev via swift-evolution > wrote: > > Everyone does feel comfortable with implicit public extensions? > > > > -- > Adrian Zubarev > Sent with Airmail > > Am 19. Juni 2016 um 09:18:35, Adrian Zubarev > (adrian.zuba...@devandartist.com) schrieb: >

Re: [swift-evolution] [Discussion] access control modifier inconsistency

Access control modifier: public > internal == /* implicitly internal */ > fileprivate >= private //= TOPLEVEL / File - Scope //= some protocols public protocol A { func aa() } private protocol B { func bb() } fileprivate protocol C { func cc() }

Re: [swift-evolution] LibDispatch : access to current queue, or queue name

dispatch_queue_get_label() isn’t marked as a for-debugging-only API as far as I can see, and I can see uses in non-debugging contexts (logging is the obvious one) for knowing the current queue’s label (without also allowing the error-prone usage of dispatch_get_current_queue() itself). As such,

Re: [swift-evolution] LibDispatch : access to current queue, or queue name

> On 19 Jun 2016, at 23:52, Jérôme Duquennoy via swift-evolution > wrote: > > With the release of swift 3, The interface to libDispatch has evolved quite a > lot, to a much cleaner, object oriented interface. > There seems to be one feature that is no longer available : > In swift 2, it was po

Re: [swift-evolution] [Discussion] access control modifier inconsistency

I'd strongly favor correcting this inconsistency; I’ve run into it and been confused until I remembered the semantics more than once. I would much prefer always explicitly specifying the access modifier to receive its effect (versus changing the documentation) - in short I agree that extensions

Re: [swift-evolution] [Discussion] access control modifier inconsistency

Everyone does feel comfortable with implicit public extensions? --  Adrian Zubarev Sent with Airmail Am 19. Juni 2016 um 09:18:35, Adrian Zubarev (adrian.zuba...@devandartist.com) schrieb: One problem I found with the mentioned suggestion of mine is this: public protocol A {} public class B

Re: [swift-evolution] An implicit return for guard

@implicitreturn guard a = b else { print(“foo”) } Isn’t that just the same? I mean now you even write more boilerplate then bebore. How does your return type look, what are you trying to solve? --  Adrian Zubarev Sent with Airmail Am 20. Juni 2016 um 08:30:39, Yarden Eitan via swift-evolution