[swift-evolution] [Pitch] String revision proposal #1

Hi Swift Evolution, Below is a pitch for the first part of the String revision. This covers a number of changes that would allow the basic internals to be overhauled. Online version here: https://github.com/airspeedswift/swift-evolution/blob/3a822c799011ace682712532cfabfe32e9203fbb/proposals/01

Re: [swift-evolution] [Pitch] String revision proposal #1

Result? > I think Parse. As in, this is the result of a parse, not these are the parsed results (though it does contain parsed results in some cases, but not all). > > On Wed, Mar 29, 2017 at 19:32 Ben Cohen via swift-evolution > mailto:swift-evolution@swift.org>> wrote: >

Re: [swift-evolution] [Pitch] String revision proposal #1

> On Mar 30, 2017, at 8:59 AM, Adrian Zubarev via swift-evolution > wrote: > > We cannot rename SubSequence to Subsequence, because that would be odd > compared to all other types containing Sequence. > > There is a difference between subsequence, which is one word, and the others, which ar

Re: [swift-evolution] [Pitch] String revision proposal #1

> On Mar 30, 2017, at 11:20 AM, Brent Royal-Gordon > wrote: > > (That's why there's no adjective form of "string", which makes naming the > protocol difficult.) We-eelll, there is “Stringy”…. As tempting as it is to call the protocol this, it’s probably not a good idea. (then again, if we c

Re: [swift-evolution] [Pitch] String revision proposal #1

Hi Brent, Thanks for the notes. Replies inline. > On Mar 30, 2017, at 2:48 AM, Brent Royal-Gordon > wrote: > >> On Mar 29, 2017, at 5:32 PM, Ben Cohen via swift-evolution >> wrote: >> >> Hi Swift Evolution, >> >> Below is a pitch for the fir

Re: [swift-evolution] [Pitch] String revision proposal #1

> On Mar 30, 2017, at 2:03 PM, Karl Wagner via swift-evolution > wrote: > > So, running with the parallel, why not add a conditional conformance: "Slice: > Unicode where Base: Unicode”? > Primarily because this would rule out giving substrings the “small string optimization" where we pack t

Re: [swift-evolution] [Pitch] String revision proposal #1

> On Mar 30, 2017, at 10:05 AM, Karim Nassar via swift-evolution > wrote: > > >> Message: 12 >> Date: Thu, 30 Mar 2017 12:23:13 +0200 >> From: Adrian Zubarev >> To: Ben Cohen >> Cc: swift-evolution@swift.org >> Subject: Re: [swift-evolution] [Pitch] String revision proposal #1 >> Message-ID:

Re: [swift-evolution] [Pitch] String revision proposal #1

erminated. What do we >> think of an additional init(cString:) overload that takes an >> UnsafeBufferPointer and reads up to the first NUL or the end of the buffer, >> whichever comes first? >> >>> Le 30 mars 2017 à 02:48, Brent Royal-Gordon via swift-evolutio

Re: [swift-evolution] [Pitch] String revision proposal #1

://stackoverflow.com/a/27456220/251153> >>> is that you take a pointer to the CChar tuple that represents the >>> fixed-size array, but this still requires the string to be NUL-terminated. >>> What do we think of an additional init(cString:) overload that takes an

[swift-evolution] [Pitch] Add an all algorithm to Sequence

Hi, A short proposal for you as part of the algorithms theme. Hopefully non-controversial, aside from the naming of the method and arguments, about which controversy abounds. Online copy here: https://github.com/airspeedswift/swift-evolution/blob/9a778e904c9be8a3692edd19bb757b23c54aacbe/proposa

Re: [swift-evolution] [Pitch] Add an all algorithm to Sequence

> On Mar 31, 2017, at 4:20 PM, Robert Bennett via swift-evolution > wrote: > > Sorry, despite the curt tone of my initial post, I think this is overall a > great idea. Ben, thanks for drafting the proposal. > No worries! >> On Mar 31, 2017, at 6:12 PM, Ricardo Parada wrote: >> >> I agree.

Re: [swift-evolution] [Pitch] String revision proposal #1

Hi Brent, Sorry, I realized I failed to reply to these at the time. See below. > On Mar 30, 2017, at 6:52 PM, Brent Royal-Gordon > wrote: > >> On Mar 30, 2017, at 2:36 PM, Ben Cohen > > wrote: >> >> The big win for Unicode is it is short. We want to encourage peopl

Re: [swift-evolution] [Pitch] String revision proposal #1

> On Mar 31, 2017, at 2:00 AM, Brent Royal-Gordon > wrote: > >> On Mar 30, 2017, at 2:42 PM, Ben Cohen via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> (or rather, given substrings will be 2-3 words, the not-even-that-small >&

[swift-evolution] SE-165: Dictionary & Set Enhancements

Hello, Swift community! The review of "SE-165: Dictionary & Set Enhancements" begins now and runs through next Tuesday, April 11th. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0165-dict.md

Re: [swift-evolution] SE-163: String Revision: Collection Conformance, C Interop, Transcoding

> On Apr 5, 2017, at 10:32 PM, Félix Cloutier wrote: > > During the proposal phase, we asked how this would handle fixed-length > strings with an optional NUL terminator. For instance, in a C `struct Foo { > char name[8]; };`, `name` stops at the first \0, or at the eighth byte, > whichever c

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

> On Apr 6, 2017, at 12:35 PM, Joe Groff via swift-evolution > wrote: > > Hello Swift community, > > The review of SE-0168 "Multi-Line String Literals" begins now and runs > through April 12, 2017. The proposal is available here: > > https://github.com/apple/swift-evolution/blob/master/propo

[swift-evolution] [pitch] Adding in-place removeAll to the std lib

Hi swift-evolution, Another short proposal related to the Collection algorithms theme, this time for removing elements in-place from a collection. Online copy here: https://github.com/airspeedswift/swift-evolution/blob/1aac5593828941431d1805503865e7a2913d538b/proposals/-RemoveWhere.md A

Re: [swift-evolution] [pitch] Adding in-place removeAll to the std lib

> On Apr 8, 2017, at 5:41 PM, Brent Royal-Gordon wrote: > >> On Apr 8, 2017, at 12:44 PM, Xiaodi Wu via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> +1. Perfect. Let's not bikeshed this and get it done! > > > Sorry, I'm going to have to insist on bikeshedding. > > `equ

[swift-evolution] [pitch] One-sided Ranges

Hi Swift community, Another proposal pitch. These operators were mentioned briefly in the String manifesto as prefixing/suffixing is very common with strings. Online copy here: https://github.com/airspeedswift/swift-evolution/blob/71b819d30676c44234bac1aa61fc5c39bcf3/proposals/-OneSided

[swift-evolution] [pitch] Comparison Reform

Hi swift evolution, Here’s another pitch, for The Propoosal Formerly Known As Spaceship. Comparison Reform Proposal: SE- Authors: Robert Widmann , Jaden Geller , Harlan Haskins , Alexis Beingessn

Re: [swift-evolution] [pitch] Comparison Reform

Online copy here: https://github.com/airspeedswift/swift-evolution/blob/fa007138a54895e94d22e053122ca24ffa0b2eeb/proposals/-ComparisonReform.md > On Apr 13, 2017, at 1:17 PM, Ben Cohen via swift-evolution > wrote: > > > Hi swift evolution, > > Here’s another pit

[swift-evolution] SE-0170: NSNumber bridging and Numeric types

Hello Swift community, The review of “SE-0170: NSNumber bridging and Numeric types" begins now and runs through the Friday after next, April 14th. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.md

[swift-evolution] SE-0171: Reduce with inout

Hello Swift community, The review of “SE-0171: Reduce with inout" begins now and runs through the Friday after next, April 14th. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0171-reduce-with-inout.md

Re: [swift-evolution] [swift-evolution-announce] SE-0171: Reduce with inout

Apologies, if you are reading this in HTML the links appear to be pointing to the incorrect proposal. Here is the corrected link: https://github.com/apple/swift-evolution/blob/master/proposals/0171-reduce-with-inout.md > On Apr 14, 2017, at 11:37 AM, Ben Cohen wrote: > > Hello Swift communit

Re: [swift-evolution] SE-0170: NSNumber bridging and Numeric types

Apologies, if you are reading this in HTML the links appear to be pointing to the incorrect proposal. Here is the corrected link: https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.md > On Apr 14, 2017, at 11:30 AM, Ben Cohen wrote: > > Hello Swift community,

Re: [swift-evolution] [pitch] Comparison Reform

> On Apr 17, 2017, at 9:40 PM, Chris Lattner via swift-evolution > wrote: > > >> On Apr 17, 2017, at 9:07 AM, Joe Groff via swift-evolution >> wrote: >> >> >>> On Apr 15, 2017, at 9:49 PM, Xiaodi Wu via swift-evolution >>> wrote: >>> >>> For example, I expect `XCTAssertEqual(_:_:)` to b

[swift-evolution] [Accepted] SE-165: Dictionary & Set Enhancements

Hello Swift Community, The review of SE-165: Dictionary & Set Enhancements ran from April 6...11, 2017. The proposal is accepted with some revisions regarding naming: 1) The key/value sequence of init that does not take a closure resolving key conflicts will be named init(uniqueKeysWithValues:)

[swift-evolution] Add MutableCollection.swap

Hi Swift community, Another pitch, this time related to the ownership manifesto. Add MutableCollection.swap(_:with:) Proposal: SE- Authors: Ben Cohen Review Manager: TBD Status: Awaiting review Introduction As part of the introduction of the Law of Exclu

[swift-evolution] [pitch] Change filter to return an associated type

Hi swift evolution, The following is a proposal that came off the back of the discussions accepting the recent Dictionary proposal. It is small but has source-breaking implications so would be good to get in for the 4.0 release. Online copy here: https://github.com/airspeedswift/swift-evolut

Re: [swift-evolution] [pitch] Change filter to return an associated type

returns a Sequence. > > On Sun, Apr 23, 2017 at 2:37 PM, Ben Cohen via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > > Hi swift evolution, > > The following is a proposal that came off the back of the discussions > accepting the recent Dictionary pr

Re: [swift-evolution] [pitch] Change filter to return an associated type

> On Apr 23, 2017, at 1:30 PM, Xiaodi Wu wrote: > > On Sun, Apr 23, 2017 at 3:12 PM, Ben Cohen > wrote: > >> On Apr 23, 2017, at 1:05 PM, Xiaodi Wu > > wrote: >> >> Is it the intention that `associatedtype Filtered : Sequence` once recur

[swift-evolution] [Accepted] SE-0171: Reduce with inout

Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0171-reduce-with-inout.md Hello Swift Community, The review of SE-0171 "Remove final support in protocol extensions” ran fro

Re: [swift-evolution] [Accepted] SE-0171: Reduce with inout

:head-desk emoji: The one in the subject-line. SE-0171: Reduce with inout. Thanks for the spot, sorry about that. > On Apr 24, 2017, at 4:46 PM, Xiaodi Wu wrote: > > ...um, which proposal is being accepted? > > On Mon, Apr 24, 2017 at 6:31 PM, Ben Cohen via swift-evolution

Re: [swift-evolution] [Review] SE-0173: Add `MutableCollection.swap(_:with:)

Hi everyone, Regarding the naming of the method: we discussed this amongst the core team and the feeling is that elements.swapAt(i, j) is the appropriate choice. We have a specific exception in the API naming guidelines around a preposition at the end of a base name, when the preposition applie

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0173: Add `MutableCollection.swap(_:with:)

> On Apr 26, 2017, at 9:12 PM, John McCall via swift-evolution > wrote: > >> >> Is that a mistake? Wouldn't the free function forward to the added method? > > I'm not sure why this is there. The implementation of the method is not part > of the library specification. If it forwards to the

[swift-evolution] [Accepted] SE-0170: NSNumber bridging and Numeric types

Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.md The review of SE-0170 “NSNumber bridging and Numeric types” ran from April 14 to April 21, 2017. The proposal is accepted for Swift 4. Thanks to everyone who participated! Ben Review Manager

[swift-evolution] [Review] SE-0176: Enforce Exclusive Access to Memory

Hello Swift community, The review of SE-0176: "Enforce Exclusive Access to Memory" begins now and runs through May 8, 2017. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0176-enforce-exclusive-access-to-memory.md

Re: [swift-evolution] [Pitch] Enumerate from offset

> On May 4, 2017, at 10:15 AM, Jaden Geller via swift-evolution > wrote: > > It's been suggested by a core team member that enumerated itself might not > hold its weight in the standard library. Instead, we ought to write > `zip(foo.indices, foo)` or `zip(0..., foo)`. It's easier for the call

Re: [swift-evolution] [Pitch] Enumerate from offset

I agree we shouldn’t have both, that would cause confusion/bloat. The downside I see of making zip a method on Sequence is that the first argument is not somehow more “special” than the second. Were it not for the chaining (and discoverability) issue, I’d be against it – it feels right as a free

[swift-evolution] [pitch] Character.unicodeScalars

Hi swift-evolution, A short string-related pitch for you. Add unicodeScalars property to Character Proposal: SE- Authors: Ben Cohen Review Manager: TBD Status: Awaiting review Introduction This proposal adds a unicodeScalar view to Character, similar t

Re: [swift-evolution] [pitch] Character.unicodeScalars

> On May 10, 2017, at 11:13 PM, Brent Royal-Gordon > wrote: > >> On May 10, 2017, at 4:51 PM, Ben Cohen via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> Add a unicodeScalars property to Character, presending a lazy view of the >

[swift-evolution] [Accepted pending revision review] SE-0176 Enforce Exclusive Access to Memory

Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0176-enforce-exclusive-access-to-memory.md The review of SE-0176 "Enforce Exclusive Access to Memory" ran fro

[swift-evolution] [Review] SE-0176: Enforce Exclusive Access to Memory

Hello Swift community, The review of revisions to SE-0176: Enforce Exclusive Access to Memory begins now and runs through May 17, 2017. Most of this proposal was previously accepted. An implementation issue has been discovered with the use of dynamic enforcement on inout parameters. The prop

Re: [swift-evolution] Revisiting SE-0110

I very much agree with your concerns about this change in general. On this specific example, though, I just wanted to point out that there doesn’t seem to be a good reason to use .forEach here. for (key, value) in self { // etc } Would work perfectly well and is clearer IMO, still works with

Re: [swift-evolution] Int indexing into UTF16View

> On Jun 8, 2017, at 10:32 AM, David Hart via swift-evolution > wrote: > > Hello, > > When working with Strings which are known to be ASCII, I tend to use the > UTF16View for the performance of random access. I would also like to have the > convenience of indexing with Int: > > let barcode

Re: [swift-evolution] Passing functions with default parameters

Hi Oskar, This is actually something we’ve spoken about in the core team meetings in the past as a known thing that ideally would work but doesn’t. The one that hits me a often is that I wish .forEach(print) worked, as it’s very useful as a quick debugging command. I don’t know if we’re tracki

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

> On Jun 28, 2017, at 6:03 AM, Erica Sadun via swift-evolution > wrote: > > In general, does everyone prefer `?? () -> Never` or `!! () -> Never`? I can > argue both ways, with the goal in reading code as "unwrap or die". > Personally, I strongly prefer `foo !! "explanation"` over `foo ??

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

> On Jun 28, 2017, at 8:27 AM, David Hart via swift-evolution > wrote: > > Count me in as a strong proponent of ?? () -> Never. We don't need to burden > the language with an extra operator just for that. You could say the same about ?? The concern that an additional operator (and one that,

[swift-evolution] [pitch] Substring performance affordances

Hi swift-evolution, Below is a short pitch for some performance improvements to be made to String to accommodate Substrings. As outlined in SE-0163, the more general question of implicit conversion from Substring to String was deferred pending feedback on the initial implementation. To date,

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

> On Jun 28, 2017, at 5:27 PM, Xiaodi Wu via swift-evolution > wrote: > > In the initial example, repeated here in largely identical form, the desired > comment is "array must be non-empty." In what way does that provide more > information than a bare `!`? > By the same token, why does prec

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

> On Jun 28, 2017, at 6:32 PM, Xiaodi Wu wrote: > > the reason why a function would return nil _are intended to be obvious, per > the design rationale given in Swift project documents_. The reason .last returns nil is obvious. But it doesn’t tell you anything about why the array itself shoul

Re: [swift-evolution] [pitch] Substring performance affordances

> On Jun 28, 2017, at 2:41 PM, David Hart wrote: > > Should authors use StringProtocol or String as often as possible? Our general advice is to stick with String. Most APIs would be simpler and clearer just using String rather than being made generic (which itself can come at a cost), and us

Re: [swift-evolution] [pitch] Substring performance affordances

> On Jun 28, 2017, at 10:26 AM, rintaro ishizaki wrote: > > Does this mean it's guaranteed that Substring.hashValue is always equal to > String.hashValue? Yes. ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailm

Re: [swift-evolution] [Proposal] Refine SE-0015 (Tuple Comparison Operators) to include empty case

Hi Arjun, Thanks for picking up this Jira. The core team discussed this today and we think it’s OK to consider this a minor amendment to the original proposal and go ahead with the change without needing a further review. Cheers, Ben > On Jul 10, 2017, at 8:35 AM, Arjun Nayini via swift-evolut

[swift-evolution] Revision review: SE-104: Protocol-oriented integers

Hi Swift community, Following feedback during the 4.0 preview, a handful of minor amendments have been suggested to SE-104: Protocol-oriented integers that the core team feels are important to include into 4.0 as they have an impact on source stability. The review of this amendment begins now a

Re: [swift-evolution] Draft: Regular Expression in Swift

Hi Joshua, Thanks for bringing this topic up. It may help to outline why regular expressions were deferred until Swift 5. The work to create a regular expression type itself, and even to add a regex literal protocol, is fairly straightforward and probably could have been done in the Swift 4 ti

Re: [swift-evolution] [Proposal] Random Unification

Hi Alejandro, I’m really happy to see someone pick this up. We had suggested some kind of random support could be a goal for addition to the standard library in Swift 4 phase 2 but didn’t manage it, so I definitely think a good proposal would be given consideration for Swift 5. Regarding the i

Re: [swift-evolution] Additional methods for removing elements from a collection in Swift

> On Sep 26, 2017, at 2:59 AM, Xiaodi Wu via swift-evolution > wrote: > > On Tue, Sep 26, 2017 at 00:15 Jonathan Hull > wrote: > As he says, it is an in-place equivalent of filter, so the use-cases would be > similar. I could see this being extremely useful. Off the

[swift-evolution] Re-pitch: remove(where:)

Hi everyone, Reviving a pitch for a feature that didn’t make it into Swift 4. This was discussed in the core team recently, and feedback was wanted regarding the naming of the method and the polarity of the where closure. Here’s the proposal: https://github.com/airspeedswift/swift-evolution/b

Re: [swift-evolution] Re-pitch: remove(where:)

And here are my answers, in a separate email to maintain a shred of separation between objectivity and subjectivity :) > On Sep 26, 2017, at 4:12 PM, Ben Cohen via swift-evolution > wrote: > > 1. Is it right to assert that with a “removing” operation, the closure should > re

Re: [swift-evolution] Additional methods for removing elements from a collection in Swift

> On Sep 25, 2017, at 2:12 AM, Alwyn Concessao via swift-evolution > wrote: > > mutating func removeElementInSubrange(_ elementToBeRemoved:Element,in > range:Range){ > > //check if elementoBeRemoved exists; if yes, check if the index of > elementToBeRemoved is part of the subrange, if yes t

Re: [swift-evolution] Additional methods for removing elements from a collection in Swift

> On Sep 27, 2017, at 12:44 PM, Tony Allevato wrote: > > > > On Wed, Sep 27, 2017 at 10:36 AM Ben Cohen via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > > >> On Sep 25, 2017, at 2:12 AM, Alwyn Concessao via swift-evolution >>

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0184: Unsafe[Mutable][Raw][Buffer]Pointer: add missing methods, adjust existing labels for clarity, and remove deallocation size

> On Sep 29, 2017, at 1:23 PM, Taylor Swift wrote: > > I think this is a reasonable argument and convinced myself that it's possible > to extend the slice API. I'm also convinced now that we don't need overloads > to handle an UnsafeBufferPointer source, instead we can provide a single > gen

Re: [swift-evolution] [Proposal] Random Unification

> On Sep 30, 2017, at 3:23 PM, Chris Lattner via swift-evolution > wrote: > > >> On Sep 11, 2017, at 9:43 PM, Brent Royal-Gordon > > wrote: >> >>> On Sep 9, 2017, at 10:31 PM, Chris Lattner via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>>

Re: [swift-evolution] [Proposal] Random Unification

> On Oct 4, 2017, at 9:20 AM, Xiaodi Wu via swift-evolution > wrote: > > If trapping is OK, then surely returning Optional is superior; any user who > is OK with trapping can make that decision for themselves by writing > `random()!`. Everyone else can then see clearly that trapping is a >

Re: [swift-evolution] [Proposal] Random Unification

> On Oct 4, 2017, at 9:12 PM, Chris Lattner via swift-evolution > wrote: > >> ``` >> extension Int { >> static func random(in range: Countable{Closed}Range) -> Int >> } > > Nice. Should these be initializers like: > > extension Int { > init(randomIn: Countable{Closed}Range) > } > I do

Re: [swift-evolution] [Proposal] Random Unification

ese static functions from numeric types. >>> >>> - Alejandro >>> >>> El oct. 5, 2017, a la(s) 12:03, Nate Cook via swift-evolution >>> mailto:swift-evolution@swift.org>> escribió: >>> >>>>> On Oct 5, 2017, at 11:30 AM, Ben

Re: [swift-evolution] [Proposal] Random Unification

> On Oct 4, 2017, at 19:26, Xiaodi Wu via swift-evolution > wrote: > > extension Data { > static func random(byteCount: Int) -> Data > } > Instead of methods on specific concrete types, I’d prefer to have a Sequence or Collection-conforming type that you could compose with existing opera

Re: [swift-evolution] SE-1084 (B): buffer pointer partial initialization API

> On Oct 11, 2017, at 1:15 PM, Kelvin Ma via swift-evolution > wrote: > > there is no way to allow one-sided subscripting, but disallow two-sided > subscripting for the memory API One-sided subscripting is just shorthand for “from here to the end” (or from the start to/through here). If a o

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

> On Oct 18, 2017, at 5:28 AM, Ole Begemann via swift-evolution > wrote: > > It also seems to clash with Michael's idea > > that two substitutable sequences should return true for ==. This is a bug in Float

Re: [swift-evolution] gyb template for ZipSequence

It might be worth noting that, in the meantime, you can nest zips as a workaround without having to define zip for n-tuples: let integers = [1, 2, 3, 4, 5] let strings = ["a", "b", "c", "d", "e"] let doubles = [1.0, 2.0, 3.0, 4.0, 5.0] for (integer, (string, double)) in zip(integers, zip(strings

[swift-evolution] [Pitch] Move UnsafeMutablePointer.initialize(from:) to UnsafeMutableBufferPointer

Hi swift-evolution, Below is a draft proposal for a change to facilitate fixing some memory safety issues in the standard library. If you’re interested in the implementation, PRs can be found here: [stdlib] [WIP] Eliminate version of Array.append(contentsOf:) that takes a Collection

Re: [swift-evolution] [Pitch] Normalize Slice Types for Unsafe Buffers

> On Dec 1, 2016, at 11:33 PM, Nate Cook via swift-evolution > wrote: > > 3) Make all buffer pointers their own slices but use a different index type. > If the indices were just wrapped pointers, that would handle the index > sharing without needing an additional property on the buffer. We co

Re: [swift-evolution] [Pitch] Normalize Slice Types for Unsafe Buffers

> On Dec 2, 2016, at 8:27 PM, Nate Cook wrote: > >> On Dec 2, 2016, at 2:12 PM, Ben Cohen via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >>> On Dec 1, 2016, at 11:33 PM, Nate Cook via swift-evolution >>> mailto:swift-e

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0147: Move UnsafeMutablePointer.initialize(from:) to UnsafeMutableBufferPointer

> On Dec 8, 2016, at 10:24 AM, Alex Martini via swift-evolution > wrote: > > >> On Dec 7, 2016, at 10:07 PM, Douglas Gregor > > wrote: >> >> Hello Swift community, >> >> The review of SE-0147 "Move UnsafeMutablePointer.initialize(from:) to >> UnsafeMutableBufferPoi

Re: [swift-evolution] [Pitch] Normalize Slice Types for Unsafe Buffers

> On Dec 8, 2016, at 4:35 PM, Jordan Rose via swift-evolution > wrote: > > Um, Sequence doesn’t have a subscript (or indexes). Sequences are > single-pass. So if this is important, it needs to stay a Collection. > Just because something fulfills one of the requirements of a Collection does

Re: [swift-evolution] [Pitch] Normalize Slice Types for Unsafe Buffers

So now that I look at it, it appears UnsafeRawBufferPointer(copyBytes:) has the same problems we are trying to solve on initialize(as:from) i.e. it is completely at the mercy of the passed-in collection's count being accurate, and if it isn't it'll scribble over memory. We should probably apply

Re: [swift-evolution] [Pitch] Normalize Slice Types for Unsafe Buffers

; > >> On Dec 8, 2016, at 5:44 PM, Xiaodi Wu via swift-evolution >> wrote: >> >>> On Thu, Dec 8, 2016 at 6:53 PM, Ben Cohen via swift-evolution >>> wrote: >>> >>>> On Dec 8, 2016, at 4:35 PM, Jordan Rose via swift-evolution &g

Re: [swift-evolution] [Review] SE-0147: Move UnsafeMutablePointer.initialize(from:) to UnsafeMutableBufferPointer

> On Dec 12, 2016, at 1:32 PM, Andrew Trick wrote: > >> >> On Dec 7, 2016, at 10:07 PM, Douglas Gregor via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> Hello Swift community, >> >> The review of SE-0147 "Move UnsafeMutablePointer.initialize(from:) to >> UnsafeMutableBu

Re: [swift-evolution] Generic Subscripts

> On Jan 12, 2017, at 1:37 PM, Slava Pestov via swift-evolution > wrote: > >> Before I submit it, could someone let me know if adding generics to >> subscripts would influence the ABI? ( still feel pretty clueless in that >> area). > > It won’t change the ABI of existing subscript calls, but

Re: [swift-evolution] Reduce with inout

> On Jan 16, 2017, at 5:49 AM, Chris Eidhof via swift-evolution > wrote: > > Hi, > > How does everyone feel about adding a second version of `reduce` to > `Sequence`? Instead of a `combine` function that's of type `(A, Element) -> > A`, it would be `(inout A, Element) -> ()`. This way, we ca

[swift-evolution] Strings in Swift 4

Hi all, Below is our take on a design manifesto for Strings in Swift 4 and beyond. Probably best read in rendered markdown on GitHub: https://github.com/apple/swift/blob/master/docs/StringManifesto.md We’re eager to hear everyone’s thoughts. Regards, Ben and Dave # String Processing For Swift

Re: [swift-evolution] Strings in Swift 4

> On Jan 19, 2017, at 19:38, David Sweeris wrote: > > Regarding substrings... Instead of having separate `ArraySlice` and > `Substring` types, what about having just one type, `Slice`, for > anything which shares memory? Seems like it'd be easier for users who'd only > have to worry about sha

Re: [swift-evolution] Strings in Swift 4

> On Jan 19, 2017, at 10:42 PM, Jose Cheyo Jimenez wrote: > > I just have one concern about the slice of a string being called Substring. > Why not StringSlice? The word substring can mean so many things, specially in > cocoa. This idea has a lot of merit, as does the option of not giving th

Re: [swift-evolution] Strings in Swift 4

> On Jan 20, 2017, at 8:04 AM, Ole Begemann wrote: > >> The downside of having two types is the inconvenience of sometimes having >> a >> `Substring` when you need a `String`, and vice-versa. It is likely this >> would >> be a significantly bigger problem than with `Array` and `ArraySlice`, as >

[swift-evolution] [pitch] Eliminate Collection.IndexDistance associated type

Hi Swift Evolution, A pitch for review, aimed at simplifying generic Collection algorithms. Online copy here: https://github.com/airspeedswift/swift-evolution/blob/5d1ffda2e83f5b95a88d5ce3948c5fd0d59622f4/proposals/-eliminate-indexdistance.md

Re: [swift-evolution] [pitch] Eliminate Collection.IndexDistance associated type

> On Nov 8, 2017, at 1:37 PM, Ben Cohen via swift-evolution > wrote: > > This turns any problem of writing a generic collection algorithm into both a > collection _and_ > problem. Gah, typo. That should read “This turns any problem of writing a generic collection alg

Re: [swift-evolution] [pitch] Eliminate Collection.IndexDistance associated type

> On Nov 8, 2017, at 1:55 PM, Ben Cohen wrote: > > Apologies to Nate Cook, from whom this important came. I would love to pretend my accidentally a word there was a joke. But it wasn’t… ___ swift-evolution mailing list swift-evolution@swift.org htt

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

> On Nov 7, 2017, at 3:35 PM, Kevin Ballard via swift-evolution > wrote: > > It's a fairly minor issue, one that really only affects new Swift programmers > anyway rather than all users > I’ve seen enough misuse of flatMap at this point to be confident saying it’s not just a beginner erro

[swift-evolution] [Review] SE-188 Make stdlib index types Hashable

Hello, Swift community! The review of “SE-0188: Make stdlib index types Hashable” begins now and runs through November 14th, 2017. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0188-stdlib-index-types-hashable.md

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

> On Nov 9, 2017, at 10:45 AM, BJ Homer via swift-evolution > wrote: > > On Nov 9, 2017, at 11:36 AM, Kevin Ballard via swift-evolution > mailto:swift-evolution@swift.org>> wrote: >> >> On Wed, Nov 8, 2017, at 09:29 PM, Paul Cantrell via swift-evolution wrote: >>> The problem in the Doodads

Re: [swift-evolution] SE-0187: Introduce Sequence.filterMap(_:)

> On Nov 9, 2017, at 11:43 AM, Vladimir.S via swift-evolution > wrote: > > let a : [Int?] = [1,2,3,nil,4,nil,5] > > let b = a.flatMap { $0.flatMap{$0*10} } // current At the risk of taking us further down the rabbit hole… You really want: let b = a.flatMap { $0.map{$0*10} } // current

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

> On Nov 9, 2017, at 4:01 PM, Paul Cantrell wrote: > > using the same name for both flatMap variants causes the type checker to > miss programmer errors Not to mention, makes it do a lot more work, lengthening compile times (especially when mixed with closure and literal type inference… the

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

> On Nov 10, 2017, at 4:07 AM, Tino Heth <2...@gmx.de> wrote: > > >> The “think of optionals as collections” explanation is a good way to help >> people who are confused by the overload. But an even better way would be to >> not have a confusing overload in the first place. > With the renamin

Re: [swift-evolution] [Accepted and Focused Re-review] SE-0187: Introduce Sequence.filterMap(_:)

I continue to favour mapSome, since it’s both literally and figuratively what it does, but appreciate that exposing the name of the Optional.some case isn’t to everyone’s taste. > On Nov 15, 2017, at 12:55 PM, John McCall via swift-evolution > wrote: > > Hello, Swift Community! > > The initi

[swift-evolution] [Accepted]

Hello Swift Community, The review of of “SE-0188: Make stdlib index types Hashable” ran from November 8th to 14th, 2017. This proposal has been accepted. During the review, the only point of discussion was whether to go one step further and make conformance to Hashable a requirement for all Col

Re: [swift-evolution] [Review] SE-0191: Eliminate IndexDistance from Collection

My suggestion would be: don’t have your Collection-like type conform to Collection. Give it collection-like methods if you want them, like an indexing and slicing subscript that takes an Int64. It can still conform to Sequence. In practice, these “huge” collections will be mostly used concretely

Re: [swift-evolution] [Review] SE-0191: Eliminate IndexDistance from Collection

t we are all clear on the implications of this, if IndexDistance > becomes Int, ranges of integers will stop conforming to Collection, because > Int.min.. potentially many more. > > This would entail nontrivial source breakage. > > > On Mon, Nov 27, 2017 at 22

Re: [swift-evolution] [Accepted] SE-0191: Eliminate IndexDistance from Collection

They will continue to conform to Collection just as they do today. Range.IndexDistance is already an Int. > On Dec 4, 2017, at 10:35, Karl Wagner via swift-evolution > wrote: > > What does this mean for ranges of integers, as Xiaodi mentioned in the review > thread? Can they still conform to

Re: [swift-evolution] [Accepted] SE-0191: Eliminate IndexDistance from Collection

ndorsed but then realized this edge case changed matters to rescind their endorsement. > - Karl > >> On 4. Dec 2017, at 19:39, Ben Cohen via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> They will continue to conform to Collection just

  1   2   >