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 We

Re: [swift-evolution] [Proposal] Fix lazy filter

on Sun Jun 19 2016, Haravikk wrote: >> On 19 Jun 2016, at 14:50, Dave Abrahams via swift-evolution >> wrote: >> >> >> on Sun Jun 19 2016, Kevin Lundberg wrote: >> >>> this seems more like a bug fix to me than a language change. Does it >&g

Re: [swift-evolution] [Proposal] Fix lazy filter

on Sun Jun 19 2016, Антон Жилин wrote: >> >> It's not a bug. Measuring the length of the source before allocating >> the destination array is usually a big win when compared to repeatedly >> growing the array's memory and copying all its elements. >> -- >> -Dave > > Usually yes, but not in the

Re: [swift-evolution] [Proposal] Fix lazy filter

on Sun Jun 19 2016, Kevin Lundberg wrote: > this seems more like a bug fix to me than a language change. Does it > need to go through evolution? It's not a bug. Measuring the length of the source before allocating the destination array is usually a big win when compared to repeatedly growing t

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 `init(_ rawValue: RawValue)`

Re: [swift-evolution] API Guidelines: dropFirst?

on Thu Jun 16 2016, David Waite wrote: > I’ve always considered the term of art argument to be at least partially a > red herring. > > These methods are difficult because you don’t have guarantees of > non-mutability until you get to Collection - on Sequence, a dropFirst > method may mean that

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

on Thu Jun 16 2016, David Waite 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 the interfa

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol syntax with Any

> >>>> >>>>> Am 09.06.2016 um 18:49 schrieb Dave Abrahams via swift-evolution >>>>> : >>> >>>>> >>>>> on Wed Jun 08 2016, Jordan Rose wrote: >>>>> >>>>>>> On Jun 8,

Re: [swift-evolution] API Guidelines: dropFirst?

on Thu Jun 16 2016, Jonathan Hull wrote: > …Thus, I don’t really see the harm in renaming these to match the rest > of Swift. It won’t cause any confusion that can’t be easily recovered > from. I'm beginning to think you may be right. -- -Dave _

Re: [swift-evolution] API Guidelines: dropFirst?

on Thu Jun 16 2016, Brent Royal-Gordon wrote: >> What is the rationale behind the name dropFirst()? Being a > non-mutating method it should clearly be e.g. droppingFirst() > according to the API Naming Guidelines. > > Like many `Sequence` and `Collection` operations, `dropFirst()` is a > result

Re: [swift-evolution] Bitshift operators

on Wed Jun 15 2016, Brent Royal-Gordon wrote: > While I was watching WWDC videos today, I noticed that there's a bit > of annoying boilerplate in OptionSet specifications, and set out to > get rid of it. Basically, what I'd like to do is this: > > extension OptionSet where RawValue: Intege

Re: [swift-evolution] Arbitrary-sized integers

on Tue Jun 14 2016, Félix Cloutier wrote: > I'm writing a program that would need Int128s. Since Swift uses LLVM > and LLVM has good support for arbitrary-sized integers (well, up to > 2^24 bits anyways), I was wondering if there was any interest in > having arbitrary-sized integers in Swift. T

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol syntax with Any

on Sat Jun 11 2016, Jonathan Hull wrote: >> If your code has many manual type erasing wrappers corresponding to >> protocols with associated types and/or Self requirements that also never >> have to trap type mismatches, that would certainly be instructive >> empirical data. Would you care to s

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol syntax with Any

on Sun Jun 12 2016, L Mihalkovic wrote: > My understanding is that dave is the type system designer. That would be a misunderstanding. I am a contributor, but other people take the lead on the type system. -- Dave ___ swift-evolution mailing list s

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol syntax with Any

on Fri Jun 10 2016, Thorsten Seitz wrote: >> Am 09.06.2016 um 19:50 schrieb Thorsten Seitz via swift-evolution >> : >> >> >>> Am 09.06.2016 um 18:49 schrieb Dave Abrahams via swift-evolution >>> : >>> > >>> >>> on

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol syntax with Any

apple.com>> >>>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> on Tue Jun 07 2016, Matthew Johnson >>>>>>> <http://matthew-at-anandabits.com/>> wrote: >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0091: Improving operator requirements in protocols

on Fri Jun 10 2016, Tony Allevato wrote: >> >> 5) Forwarding functions aren’t good for tools. Under this proposal, if I >> write “1 + 2” and use a tool to look at which “+” it resolved to, what will >> we see? The generic forwarding operator. Even though I could look in the >> source and see thi

Re: [swift-evolution] [Proposal] Remove force unwrapping in function signature.

on Thu Jun 09 2016, Saagar Jha wrote: > Yes, that’s exactly my point. Force unwrapping optionals adds > confusion for new users; all too often I see newcomers ending up with > the assumption that the force unwrapping takes care of the check for > them. ...but, it *does*. -- Dave

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol syntax with Any

Jun 07 2016, Matthew Johnson >>>>> <http://matthew-at-anandabits.com/>> wrote: >>>>>> >>>>> >>>>>>>> On Jun 7, 2016, at 9:15 PM, Dave Abrahams >>>>>>> <mailto:dabrah...@apple.com>> wrote: >>>

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

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 > <http://brent-at-architechies.com/>> wrote: >> >>>> I'm not sure that these id

Re: [swift-evolution] Philosophy of Swift

on Wed Jun 08 2016, Brent Royal-Gordon wrote: > Ack, hit Send while I was still typing. > >> Swift does not believe in the no-win scenario. It does not assume > that strong typing must be cumbersome, that memory-safe code must be > slow, or that a language must choose whether to be high-level or

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol syntax with Any

on Wed Jun 08 2016, Jordan Rose wrote: >> On Jun 8, 2016, at 13:16, Dave Abrahams via swift-evolution >> wrote: >> >> >> on Wed Jun 08 2016, Thorsten Seitz > >> > <mailto:swift-evolution@swift.org>> >> wrote: >> >>&g

Re: [swift-evolution] Enhanced existential types proposal discussion

on Thu Jun 09 2016, Douglas Gregor wrote: >> On Jun 8, 2016, at 11:57 AM, Dave Abrahams via swift-evolution > wrote: >> >> >> on Sun Jun 05 2016, Douglas Gregor <mailto:swift-evolution@swift.org>> wrote: >> > >>> Sent from my iPhone

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol syntax with Any

hams wrote: >>>> >>>> >>>> on Tue Jun 07 2016, Matthew Johnson wrote: >>>> >>> >>>>>> On Jun 7, 2016, at 9:15 PM, Dave Abrahams wrote: >>>>>> >>>>>> >>>>>> on

Re: [swift-evolution] [Pre-proposal/Question] Exposing the Unboxing Capabilities of AnyIndex (and similar types)

on Thu Jun 09 2016, Haravikk wrote: >> On 8 Jun 2016, at 20:53, Dave Abrahams via swift-evolution > wrote: >> >>> on Wed Jun 08 2016, Haravikk <mailto:swift-evolution@swift.org>> wrote: >>> >>> But those shouldn't be the public name

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

on Wed Jun 08 2016, Brent Royal-Gordon wrote: >> I'm not sure that these ideas are consistent with the Swift >> error-handling philosophy, which IIUC is very consciously designed *not* >> to support things like file- and database-backed Collections. My >> understanding is that if you have somet

Re: [swift-evolution] Philosophy of Swift

on Wed Jun 08 2016, Paul Cantrell wrote: >> On Jun 8, 2016, at 6:13 PM, Dave Abrahams via swift-evolution >> wrote: >> >> on Wed Jun 08 2016, Paul Cantrell wrote: >> >>> The interplay of the first two and the last two is what makes the >>&

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol syntax with Any

ns API; I don't remember all the new indexing APIs off the >> top >> >> of my head): >> >> >> >> func doSomething(x: T, y: T) { >> >> // Get indexes out of x and use them to index into y >> >> var idx = x.startIndex >> >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol syntax with Any

> >>>> on Tue Jun 07 2016, Matthew Johnson >>> <http://matthew-at-anandabits.com/>> wrote: >>>> >>> >>>>>> On Jun 7, 2016, at 4:13 PM, Dave Abrahams via swift-evolution >>>>>> wrote: >>>>>> >

Re: [swift-evolution] Philosophy of Swift

on Wed Jun 08 2016, Paul Cantrell wrote: > The interplay of the first two and the last two is what makes the > language unique. For example, structs have a simple, high-level > programmer model — “pass by value semantics” — but the compiler jumps > through all those COW hoops to make them perfor

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol syntax with Any

ial variables >> may be different >> doSomething(someSeq, anotherSeq) >> >> It's this situation (using an existential type to fulfill a generic type >> parameter constrained to the same requirements that comprise that >> existential) that requires

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol syntax with Any

on Wed Jun 08 2016, Austin Zheng wrote: > We might be talking past each other. I think Matthew is talking about using > an existential outside the context of generic functions. For example, > something like this should be trap-proof (as long as 'x' is immutable, > which it is in this example):

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol syntax with Any

on Wed Jun 08 2016, Jordan Rose wrote: >> On Jun 8, 2016, at 13:16, Dave Abrahams via swift-evolution >> wrote: >> >> >> on Wed Jun 08 2016, Thorsten Seitz > <mailto:swift-evolution@swift.org>> wrote: >> > >>> Ah, thanks, I fo

Re: [swift-evolution] Proposal: Filter split extension on Sequence to return tuple of sequences that meet criteria and that do not

on Wed Jun 08 2016, Nate Cook wrote: >> On Jun 8, 2016, at 3:40 PM, Dave Abrahams via swift-evolution >> wrote: >> >> >> on Wed Jun 08 2016, Dave Abrahams wrote: >> > >>> on Wed Jun 08 2016, gadiraju praneeth wrote: >>> >>&

Re: [swift-evolution] Proposal: Filter split extension on Sequence to return tuple of sequences that meet criteria and that do not

esults to be Arrays (rather than, say ArraySlices). > > > On Wed, Jun 8, 2016 at 3:40 PM, Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote: > >> >> on Wed Jun 08 2016, Dave Abrahams wrote: >> >> > on Wed Jun 08 2016, gadiraju pran

Re: [swift-evolution] Proposal: Filter split extension on Sequence to return tuple of sequences that meet criteria and that do not

on Wed Jun 08 2016, Dave Abrahams wrote: > on Wed Jun 08 2016, gadiraju praneeth wrote: > >> Many times, I came across a scenario where I had to filter an array with a >> condition and filter the same array with opposite of that condition. For >> example: >> >> let values = [2, 4, 3, 5, 6, 9] >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol syntax with Any

ks is probably worth a proposal by itself. >> >> Austin >> >> >> On Wed, Jun 8, 2016 at 12:34 PM, Thorsten Seitz via swift-evolution >> > <mailto:swift-evolution@swift.org>> >> wrote: >> >> > Am 08.06.2016 um 20:33 schrieb

Re: [swift-evolution] Proposal: Filter split extension on Sequence to return tuple of sequences that meet criteria and that do not

on Wed Jun 08 2016, gadiraju praneeth wrote: > Many times, I came across a scenario where I had to filter an array with a > condition and filter the same array with opposite of that condition. For > example: > > let values = [2, 4, 3, 5, 6, 9] > > let divisibleByTwo = values.filter { $0 % 2 == 0

Re: [swift-evolution] [Pre-proposal/Question] Exposing the Unboxing Capabilities of AnyIndex (and similar types)

on Wed Jun 08 2016, Haravikk wrote: > So I’m working on a kind of collection wrapper, and hoping to avoid > having to expose the underlying type of the collection, by instead > returning indices of AnyIndex. This works fine in one direction, but > when it comes time to actually use these I have

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

on Wed May 18 2016, Brent Royal-Gordon wrote: >>> If we're doing this, I wonder if category 1 shouldn't just be >> `Convertible`. This would preserve our `LiteralConvertible` >> protocols with the same names (which, consistency issues aside, seem >> perfectly cromulent), while shifting the `Stri

Re: [swift-evolution] Enhanced existential types proposal discussion

on Sun Jun 05 2016, Douglas Gregor wrote: > Sent from my iPhone > >> On Jun 5, 2016, at 6:41 PM, Matthew Johnson wrote: >> >> >> >> Sent from my iPad >> >>> On Jun 5, 2016, at 6:20 PM, Douglas Gregor wrote: >>> >>> On May 18, 2016, at 12:35 AM, Austin Zheng wrote: I've p

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol syntax with Any

on Tue Jun 07 2016, Matthew Johnson wrote: >> On Jun 7, 2016, at 9:15 PM, Dave Abrahams wrote: >> >> >> on Tue Jun 07 2016, Matthew Johnson > <http://matthew-at-anandabits.com/>> wrote: >> > >>>> On Jun 7, 2016, at 4:13 PM, Dave Abrah

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

on Wed Jun 08 2016, John McCall wrote: >> On Jun 7, 2016, at 4:25 PM, Dave Abrahams wrote: >> on Tue Jun 07 2016, John McCall wrote: >> >>>> On Jun 5, 2016, at 5:18 PM, Dave Abrahams via swift-evolution >>>> wrote: >>>> on Thu Jun 02 2

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

on Wed Jun 08 2016, Brent Royal-Gordon wrote: >> Is there a widely used comparison function that throws? > > Any comparison function that examines external data related to the instance: > > * Sorting filenames by the data in the corresponding files > > * Instances backed by a database where actu

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

on Wed Jun 08 2016, Chris Lattner wrote: >> On Jun 8, 2016, at 7:52 AM, Brent Royal-Gordon >> wrote: >> >>> Is there a widely used comparison function that throws? >> >> Any comparison function that examines external data related to the instance: >> >> * Sorting filenames by the data in the

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol syntax with Any

on Tue Jun 07 2016, Matthew Johnson wrote: >> On Jun 7, 2016, at 4:13 PM, Dave Abrahams via swift-evolution >> wrote: >> >> >> on Tue Jun 07 2016, Matthew Johnson wrote: >> > >>>> , but haven't realized >>>> that if you

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

on Tue Jun 07 2016, John McCall wrote: >> On Jun 5, 2016, at 5:18 PM, Dave Abrahams via swift-evolution >> wrote: >> on Thu Jun 02 2016, John McCall > <mailto:swift-evolution@swift.org>> wrote: >> >>> The official way to build a literal of a sp

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol syntax with Any

on Tue Jun 07 2016, Matthew Johnson wrote: >> , but haven't realized >> that if you step around the type relationships encoded in Self >> requirements and associated types you end up with types that appear to >> interoperate but in fact trap at runtime unless used in exactly the >> right way. >

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

store the original ordering, when >> that restoration may not be needed at all, is prohibitive. It's often >> the case that the caller will be throwing away the partially-modified >> original when an error is thrown. >> >> > On Mon, Jun 6, 2016 at 5:31 PM Dave

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol syntax with Any

on Tue Jun 07 2016, Matthew Johnson wrote: >> On Jun 6, 2016, at 12:22 AM, Dave Abrahams > wrote: >> >> >> on Sun Jun 05 2016, Matthew Johnson <http://matthew-at-anandabits.com/>> wrote: >> > >>> Sent from my iPhone >>> >

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

store the original ordering, when that restoration may not be needed at all, is prohibitive. It's often the case that the caller will be throwing away the partially-modified original when an error is thrown. > On Mon, Jun 6, 2016 at 5:31 PM Dave Abrahams via swift-evolution < > sw

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

on Sun Jun 05 2016, Haravikk wrote: >> On 5 Jun 2016, at 19:14, Tim Vermeulen via swift-evolution >> wrote: >> >> Most standard library functions that take a closure allow that >> closure to throw (and those functions are subsequently marked with >> rethrows). sort and sorted are exceptions t

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

.self).size 2. memoryLayout(Int.self).size 3. MemoryLayout.size I don't see any advantage of #1 over #2, and there's no need at all to define a new nominal type if we only want #2: func memoryLayout(_ T.type) -> (size: Int, stride: Int, alignment: Int) { // implementation }

Re: [swift-evolution] SE-0045 status?

on Mon Jun 06 2016, Erica Sadun wrote: > Did we ever get to a stopping point on SE-0045, with the take while / > drop while methods? I remember we were discussing using prefix / > suffix and a bunch of other names, but was the consensus ever fully > settled? I'm going back through the gmane arch

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

on Thu Jun 02 2016, John McCall wrote: > On Jun 2, 2016, at 1:43 PM, Russ Bishop wrote: > > On Jun 2, 2016, at 11:30 AM, John McCall via swift-evolution > > wrote: > > I still think the value-based APIs are misleading and that it would be > better to ask people to just use a type explici

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

on Thu Jun 02 2016, John McCall wrote: > On Jun 2, 2016, at 8:48 AM, Matthew Johnson via swift-evolution > > wrote: > > On Jun 2, 2016, at 10:38 AM, Xiaodi Wu wrote: > > Well, as I understand it, it's not actually possible to write your own > type(of:), so we're going from a "magic" prop

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

on Thu Jun 02 2016, Matthew Johnson wrote: > On Jun 2, 2016, at 10:03 AM, Xiaodi Wu wrote: > > That proposal was returned for revision; as far as user ergonomics in Swift > 3, .self is going to be a consideration. Best to find a solution > that reads nicely regardless of the situation with

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

on Thu Jun 02 2016, Matthew Johnson wrote: > On Jun 2, 2016, at 10:01 AM, Charlie Monroe > wrote: > > Isn’t this a short-term concern? I thought that requirement was going away. > > AFAIK there are still concerns about ambiguity - [Int] - is it an array with > one element (Int.self), or is

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

on Wed Jun 01 2016, Xiaodi Wu wrote: > On Wed, Jun 1, 2016 at 11:55 PM, Xiaodi Wu wrote: > > On Wed, Jun 1, 2016 at 11:28 PM, Erica Sadun via swift-evolution > > wrote: > > Upon accepting SE-0098, the core team renamed the proposed stdlib function > from dynamicType() to type(of:). They w

Re: [swift-evolution] Proposal: 'T(literal)' should construct T using the appropriate literal protocol if possible

on Thu Jun 02 2016, John McCall wrote: > The official way to build a literal of a specific type is to write the > literal in an explicitly-typed context, like so: > let x: UInt16 = 7 > or > let x = 7 as UInt16 > > Nonetheless, programmers often try the following: > UInt16(7) > > Unfo

Re: [swift-evolution] [Pre-proposal] Forward/Reverse Only Indexing Methods

Sorry, I can't seem to find the original message. on Tue May 31 2016, Thorsten Seitz wrote: >> Am 31.05.2016 um 14:46 schrieb Haravikk via swift-evolution >> : >> >> So for Swift 3 we’re going to have the great new indexing model that >> performs index manipulation through the collection to wh

Re: [swift-evolution] [Pre-proposal] Forward/Reverse Only Indexing Methods

on Sat Jun 04 2016, Thorsten Seitz wrote: > That's a good idea! I'd like to see how some real algorithms would > look like with that approach. Exactly. -- -Dave ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mail

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

on Sun Jun 05 2016, Tim Vermeulen wrote: > Most standard library functions that take a closure allow that closure > to throw (and those functions are subsequently marked with > rethrows). sort and sorted are exceptions to this. I couldn’t find > this documented anywhere, but I assume this is bec

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol syntax with Any

on Wed May 25 2016, Matthew Johnson wrote: > Sent from my iPad > >> On May 25, 2016, at 12:10 PM, Jordan Rose via swift-evolution >> wrote: >> >> On May 25, 2016, at 05:27, Brent Royal-Gordon via swift-evolution wrote: AFAIK an existential type is a type T with type para

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0089: Renaming String.init(_: T)

on Tue May 31 2016, Thorsten Seitz wrote: > I agree with Vladimir. Having a value preserving representation is > orthogonal to a human readable representation. I too think he's making a good point. I could be missing something, but it seems to me we don't fully understand this design yet. --

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0050: Decoupling Floating Point Strides from Generic Implementations

on Mon May 30 2016, Brent Royal-Gordon wrote: >> The core team believes that the existing strideable API cannot efficiently >> and correctly handle all the real-world use cases one would want. However, >> a multiplication-based implementation similar to the one proposed in SE-0050 >> (but po

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0089: Renaming String.init(_: T)

on Thu May 26 2016, Patrick Smith wrote: >> On 27 May 2016, at 2:40 PM, Austin Zheng via swift-evolution >> wrote: >> >> Any of the NSObject subclass candidates may require their >> `description`s to be altered to meet the semantics, which may or may >> not be an acceptable breaking change. >

Re: [swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0089: Renaming String.init(_: T)

on Thu May 26 2016, Austin Zheng wrote: > I think this is an incredible idea. > > Should we eventually prepare an updated proposal? I think that's what “returned for revision” implies ;-) > Given the need for further discussion I'd be happy to drive it > forward, or if someone else wants they

Re: [swift-evolution] [Pre-proposal] Replace [Foo] With CollectionType

On May 24, 2016, at 9:35 PM on Tue May 24 2016, Matthew Johnson wrote: > , Austin Zheng > wrote: > > On Tue, May 24, 2016 at 4:24 PM, Brent Royal-Gordon > wrote: > > > I’m not sure what you mean about introducing type unsafely. > > What I mean is that once you do this: > >

Re: [swift-evolution] [Pre-proposal] Replace [Foo] With CollectionType

on Fri May 27 2016, Xiaodi Wu wrote: > Firstly, the syntax is about to get a lot cleaner. Soon, your example will be: > > func doSomething< > S: Sequence, T: Sequence, U: Sequence >>(foos: S, bars: T, bazzes: U) > where S.Element == Foo, T.Element == Bar, U.Element == Baz > > Second, this syntax

[swift-evolution] Foundational Algorithms prototype

FYI: notwithstanding the recent deferral of rotate from the standard library, I believe such foundational algorithms are very important for Swift. I have established https://github.com/apple/swift/blob/master/test/Prototypes/Algorithms.swift with implementations of rotate and stablePartition. In

Re: [swift-evolution] [Pitch] Add `mapValues` method to Dictionary

on Tue May 24 2016, Nate Cook wrote: >> On May 24, 2016, at 7:43 AM, Matthew Johnson via swift-evolution >> wrote: >> >> Sent from my iPad >> >> On May 24, 2016, at 12:59 AM, Brent Royal-Gordon via swift-evolution >> wrote: > >> I have a small remark though, wouldn’t it be better to

Re: [swift-evolution] [Accepted with modifications] SE-0045: Add scan, prefix(while:), drop(while:), and unfold to the stdlib

on Fri May 06 2016, Kevin Ballard wrote: > On Fri, May 6, 2016, at 07:33 PM, Dave Abrahams via swift-evolution wrote: >> >> on Fri May 06 2016, Kevin Ballard wrote: >> >> > On Fri, May 6, 2016, at 06:05 PM, Dave Abrahams via swift-evolution wrote: >> &

Re: [swift-evolution] [Accepted with modifications] SE-0045: Add scan, prefix(while:), drop(while:), and unfold to the stdlib

on Fri May 06 2016, Kevin Ballard wrote: > As I said to Chris in an off-list email, unfold() was actually the > function that I was the most excited about in the proposal, because it > allows for a very elegant solution to a variety of looping needs, > especially now that we've gotten rid of the

[swift-evolution] [Accepted] SE-0093: Adding a public base property to slices

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0093-slice-base.md The review of "SE-0093: Adding a public base property to slices" ran from May 19…23, 2016. The proposal has been *accepted* without changes: - There was little feedback from the community other tha

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

on Wed May 25 2016, Tony Allevato wrote: > I was inspired to put together a draft proposal based on an older discussion > in > the Universal Equality, Hashability, and Comparability thread > that recently > got necromanced (thanks

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol syntax with Any

on Thu May 26 2016, Adrian Zubarev wrote: > There is great feedback going on here. I'd like to consider a few things here: > > * What if we name the whole thing `Existential<>` to sort out all > confusion? Some of us believe that “existential” is way too theoretical a word to force into the off

Re: [swift-evolution] Add a stride(by:) method to ClosedRange

on Fri May 20 2016, Tim Vermeulen wrote: > * that there was no one obvious behavior with a negative stride size > (range > operators require a smaller number on the lhs and a bigger one on the rhs, > so you can't write `9...0`, but stride(from:to:by) can start from a bigger > nu

Re: [swift-evolution] [Review] SE-0094: Add sequence(initial:next:) and sequence(state:next:) to the stdlib

On behalf of Dmitri Gribenko, Max Moiseev, and myself: on Thu May 19 2016, Kevin Ballard wrote: > After having given this some thought, it seems apparent that `sequence > (state:next:)` is equivalent to `AnyIterator({ ... })` where the closure > captures a single mutable variable. Yes.

Re: [swift-evolution] [Idea] A 128-bit unsigned integer value type

on Sat May 21 2016, Károly Lőrentey wrote: > On 2016-05-17 14:30:36 +, Muse M via swift-evolution said: > >> Most programming languages does have 128-bit of type except Swift. > > I don't think there is huge demand for a full-blown Int128 type in the > standard library, but it would be nice

Re: [swift-evolution] [Review] SE-0094: Add sequence(initial:next:) and sequence(state:next:) to the stdlib

on Wed May 25 2016, Erica Sadun wrote: > On May 25, 2016, at 2:18 PM, Kevin Ballard via swift-evolution > wrote: > > We think the need to do a capture is icky, so the sequence form is > almost always better. > > I agree that the need for a capture is ugly. > > The design of AnySequence an

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0096: Converting dynamicType from a property to an operator

on Wed May 25 2016, Joe Groff wrote: >> On May 25, 2016, at 12:28 PM, Dave Abrahams wrote: >> >> >> on Wed May 25 2016, Joe Groff wrote: >> > >>>> On May 25, 2016, at 11:42 AM, Erica Sadun wrote: >>>> >>>>

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0096: Converting dynamicType from a property to an operator

on Wed May 25 2016, Joe Groff wrote: >> On May 25, 2016, at 11:42 AM, Erica Sadun wrote: >> >> >>> On May 25, 2016, at 12:26 PM, Dave Abrahams via swift-evolution >>> wrote: >>> I don't understand why the proposal says we can't implem

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0096: Converting dynamicType from a property to an operator

on Tue May 24 2016, Chris Lattner wrote: > Hello Swift community, > > The review of "SE-0096: Converting dynamicType from a property to an > operator" begins now and runs through May 30. The proposal is available here: > > > https://github.com/apple/swift-evolution/blob/master/proposals/

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

on Sun May 22 2016, Matthew Johnson wrote: > Are you sure that is Sean’s entire point? I take more away from it than that. > Look at slide 13 here: > https://github.com/boostcon/cppnow_presentations_2012/blob/master/fri/value_semantics/value_semantics.pdf > > “The shared structure also breaks ou

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

on Sun May 22 2016, Matthew Johnson wrote: >> On May 22, 2016, at 3:42 PM, Dave Abrahams via swift-evolution >> wrote: >> >> >> on Sun May 22 2016, Matthew Johnson wrote: >> >>> What I am arguing for is the ability to distinguish aggregates whi

Re: [swift-evolution] [Pitch] Rename `AnyObject` to `AnyClass` and drop current `AnyClass`

on Sun May 22 2016, Brent Royal-Gordon wrote: >> I haven't had the >> chance to consider all the implications yet, but—at least until someone >> can demonstrate that we really custom == for classes—we should be open >> to the idea as we consider the value semantics story. > > I've been lurking a

Re: [swift-evolution] [Pitch] Rename `AnyObject` to `AnyClass` and drop current `AnyClass`

on Sun May 22 2016, Matthew Johnson wrote: >> On May 22, 2016, at 1:23 PM, Dave Abrahams via swift-evolution >> wrote: >> >> >> on Fri May 20 2016, Matthew Johnson >> > <mailto:swift-evolution@swift.org>> >> wrote: >> >>

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

on Sun May 22 2016, Matthew Johnson wrote: > What I am arguing for is the ability to distinguish aggregates which > are logically isolated from aggregates which contain salient > references to shared mutable state. Everything with value semantics is logically isolated in that way. > To be hon

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

on Sun May 22 2016, Matthew Johnson wrote: >> On May 22, 2016, at 12:04 PM, Dave Abrahams via swift-evolution >> wrote: >> >> >> on Mon May 16 2016, Matthew Johnson wrote: >> >>>> On May 15, 2016, at 2:01 PM, Dave Abrahams >>>>

Re: [swift-evolution] [Pitch] Add `mapValues` method to Dictionary

on Sat May 21 2016, Honza Dvorsky wrote: > Hi Brent, > > thanks, I should have caught that, unfortunately I don't know of a > nice way to search the mailing list, other than searching your own > inbox, which doesn't include messages from the time you weren't > subscribed - how do you do it? Try

Re: [swift-evolution] [Review] SE-0089: Renaming String.init(_: T)

on Fri May 20 2016, Kevin Ballard wrote: > On Fri, May 20, 2016, at 05:14 PM, Dave Abrahams via swift-evolution wrote: >> >> on Fri May 20 2016, Kevin Ballard wrote: >> >> > On Tue, May 17, 2016, at 08:32 PM, Chris Lattner via swift-evolution wrote: >> &

Re: [swift-evolution] [Pitch] Rename `AnyObject` to `AnyClass` and drop current `AnyClass`

on Fri May 20 2016, Matthew Johnson wrote: >> On May 20, 2016, at 7:40 PM, Brent Royal-Gordon via swift-evolution >> wrote: >> >>> The Any-class requirement could replace the current `AnyObject` >>> protocol with a typealias like this: `typealias AnyObject = >>> Any` > >>> >>> Assume Swift w

Re: [swift-evolution] [Pitch] Rename `AnyObject` to `AnyClass` and drop current `AnyClass`

on Fri May 20 2016, Adrian Zubarev wrote: > I’d like to discuss with the community to see their reactions on that topic. > > Basically from the beginning of Swift I thought it was just confusing how > these typealiases were used and named. > As we know from Apply API Guidelines to the Standard

Re: [swift-evolution] [Proposal] Add property for negation to Bool

on Sat May 21 2016, Антон Миронов wrote: > I found negation operator (!) the least detectable among the code. So > I’ve decided to add property “not” to BooleanType (Swift 2.2) or > Boolean on 3.0 with extension: > > extension BooleanType { > var not: Bool { return !self.boolValue } > } >

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

on Mon May 16 2016, Matthew Johnson wrote: >> On May 16, 2016, at 1:39 AM, Dave Abrahams wrote: >> >> >> on Sun May 15 2016, Tyler Fleming Cloutier > <http://cloutiertyler-at-aol.com/>> wrote: >> > >>> On May 15, 2016, at 1

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

on Mon May 16 2016, Matthew Johnson wrote: >> On May 15, 2016, at 2:01 PM, Dave Abrahams >> wrote: >> >> >> on Fri May 13 2016, Matthew Johnson > > wrote: >> > >>> Sent from my iPad >>> On May 13, 2016, at 9:12 AM, Dave Abrahams wrote:

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

on Sat May 21 2016, Brent Royal-Gordon wrote: >>> Similarly, we shouldn't provide operations which are going to >>> repeatedly seek elements near the tail of the list unless we're using >>> a type which can access that tail efficiently. `last` is one >>> thing—it's only O(N). `lastIndex(of:)` is

Re: [swift-evolution] [Review] SE-0089: Renaming String.init(_: T)

on Fri May 20 2016, Kevin Ballard wrote: > On Tue, May 17, 2016, at 08:32 PM, Chris Lattner via swift-evolution wrote: >> * What is your evaluation of the proposal? > > I'm a little nervous about this change, because converting things to > strings is a fairly basic operation and it should b

Re: [swift-evolution] Static Dispatch Pitfalls

on Fri May 20 2016, Fabian Ehrentraud wrote: > Hi, > > there's been a little discussion about static vs. dynamic dispatch on > this mailing list, and there is a good post about the pitfalls when > using attributes defined in extensions [1]. > > Having run into this myself during development, is

<    3   4   5   6   7   8   9   10   11   12   >