Re: [swift-evolution] Fixing Apple Framework APIs in regard to the Swift Design Guidelines

> On Jun 18, 2016, at 10:14 PM, Brent Royal-Gordon > wrote: > >> swift-evolution isn’t the right process for proposing changes to Apple >> frameworks, but you raise good points, and I really value the feedback. >> >> If you file a radar with bugreporter.apple.com

Re: [swift-evolution] libdispatch renaming feedback

> On Jun 15, 2016, at 11:14 AM, Guillaume Lessard via swift-evolution > wrote: > > Here’s some feedback after translating some Dispatch-heavy code for the new > Dispatch module. > > 1. I like the result. Thanks for the effort! > > 2. Omissions > > - Can't

Re: [swift-evolution] Fixing Apple Framework APIs in regard to the Swift Design Guidelines

> swift-evolution isn’t the right process for proposing changes to Apple > frameworks, but you raise good points, and I really value the feedback. > > If you file a radar with bugreporter.apple.com and let us know the radar #, > we will be happy to escalate this with the team in question.

Re: [swift-evolution] [Pitch] "unavailable" members shouldn't need an impl

> On Jun 10, 2016, at 5:47 PM, John McCall via swift-evolution > wrote: > >> On Jun 10, 2016, at 2:22 PM, Austin Zheng via swift-evolution >> wrote: >> >> Hello swift-evolutioneers, >> >> Here's an idea. It's technically additive, but

Re: [swift-evolution] Why hard-code octet-sized bytes?

> On Jun 17, 2016, at 1:01 PM, Daryle Walker via swift-evolution > wrote: > > When I first looked into Swift, I noticed that the base type was called > “UInt8” (and “Int8”) and not something like “Byte.” I know modern computers > have followed the bog standard

Re: [swift-evolution] Proposal: Deprecate optionals in string interpolation

> On Jun 16, 2016, at 12:44 PM, Charlie Monroe via swift-evolution > wrote: > > Sorry, didn't have time to actually submit the proposal, but it at least gave > me some time to think it through a few more times. > > After reconsiderations, I suggest the following: >

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

On Sat, Jun 18, 2016 at 9:09 PM, Karl via swift-evolution wrote: > So like most good pitches, this one comes about because of a bug I recently > fixed which seems common and subtle enough that I think it would be nice to > include in the standard library. > > Removing

Re: [swift-evolution] Fixing Apple Framework APIs in regard to the Swift Design Guidelines

> On Jun 16, 2016, at 3:57 PM, David Hart via swift-evolution > wrote: > > I’ve only started using the transformed APIs from Apple frameworks that were > auto-modified and I’ve found a few cases where the automatic translation > doesn’t seem to follow the Swift

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

> 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

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

So like most good pitches, this one comes about because of a bug I recently fixed which seems common and subtle enough that I think it would be nice to include in the standard library. Removing a collection of elements at once from a collection. You might want to do this in some kind of

Re: [swift-evolution] [Pitch] String prefix operator

Hi everyone, this is my first post to swift-evolution, so I apologize in advance if I violate any rules of list etiquette, and thanks for reading! > On Jun 18, 2016, at 17:44, Xiaodi Wu via swift-evolution > wrote: > > On Sat, Jun 18, 2016 at 4:50 PM, Michael

Re: [swift-evolution] Allow a typealias to be named after the corresponding type

This doesn’t work if `DataStructureKit` and `BinarySearchTree` have the same name. > > public struct BinarySearchTree{ > > typealias Node = Node > > var root: Node? > > } > > > > private class Node{ } > > > > This code currently doesn’t compile because the Node typealias circularly

Re: [swift-evolution] [Pitch] String prefix operator

On Sat, Jun 18, 2016 at 4:50 PM, Michael Peternell via swift-evolution < swift-evolution@swift.org> wrote: > > > Am 17.06.2016 um 07:45 schrieb Charlie Monroe via swift-evolution < > swift-evolution@swift.org>: > > > > Motivational example: > > > > var urlString = self.urlString > > if

Re: [swift-evolution] [Pitch] String prefix operator

> Am 17.06.2016 um 07:45 schrieb Charlie Monroe via swift-evolution > : > > Motivational example: > > var urlString = self.urlString > if urlString.hasPrefix("//") { > urlString = "http:" + urlString // urlString needs to be typed twice > } > > While there is

Re: [swift-evolution] Bitshift operators

> On 18 Jun 2016, at 02:25, Dave Abrahams via swift-evolution > wrote: > > on Fri Jun 17 2016, Ben Rimmington wrote: > >> >> >>> **In initializers that perform

Re: [swift-evolution] Suppress unused result warnings on try? if attempted statement does not return

I discussed the same issue in a WWDC lab with Doug yesterday and we came to the conclusion that warnings about unused return values of type Optional were a bug. The basic line of argumentation was that if you have class Foo { func bar() {} } then foo?.bar() returns Optional but does not

Re: [swift-evolution] Bitshift operators

on Fri Jun 17 2016, Ben Rimmington wrote: > > >> **In initializers that perform full-width type conversions, omit the >> first argument label**, e.g. `Int64(someUInt32)` > > OptionSet could add

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

> Am 17.06.2016 um 16:11 schrieb Douglas Gregor : > > >> On Jun 16, 2016, at 9:46 AM, Thorsten Seitz via swift-evolution >> > wrote: >> >>> >>> Am 16.06.2016 um 17:36 schrieb Paul Cantrell

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

> > Sure, but `mappingAndFlattening(to:)` would have brevity issues as well. My point was that if you want to transform sin() -> sine() you'd be pretty much forced to also do atanh() -> hyperbolicArcTangent(). However the proposed transformation is for flatMap() to flatMapped(), which doesn't