Re: [swift-evolution] Strings in Swift 4

Hi David W. please read inline responses > On 25 Feb 2017, at 07:26, David Waite wrote: > > Ted, > > It might have helped if instead of being called String and Character, they > were named Text and ExtendedGraphemeCluster. Imho,l “text” maybe, but in computer

Re: [swift-evolution] Strings in Swift 4

> On Feb 25, 2017, at 2:54 PM, Michael Ilseman wrote: > > >> On Feb 25, 2017, at 3:26 PM, David Waite via swift-evolution >> > wrote: >> >> Ted, >> >> It might have helped if instead of being called String and

Re: [swift-evolution] Strings in Swift 4

> On Feb 25, 2017, at 3:26 PM, David Waite via swift-evolution > wrote: > > Ted, > > It might have helped if instead of being called String and Character, they > were named Text I would oppose taking a good name like “Text” and using it for Strings which are

Re: [swift-evolution] Strings in Swift 4

Ted, It might have helped if instead of being called String and Character, they were named Text and ExtendedGraphemeCluster. They don’t really have the same behavior or functionality as string/characters in many other languages, especially older languages. This is because in many languages,

Re: [swift-evolution] Strings in Swift 4

ok, I understand, thank you TedvG > On 25 Feb 2017, at 00:25, David Sweeris wrote: > > >> On Feb 24, 2017, at 13:41, Ted F.A. van Gaalen wrote: >> >> Hi David & Dave >> >> can you explain that in more detail? Wouldn’t that turn simple

Re: [swift-evolution] Strings in Swift 4

> On Feb 24, 2017, at 13:41, Ted F.A. van Gaalen wrote: > > Hi David & Dave > > can you explain that in more detail? >>> Wouldn’t that turn simple character access into a mutating function? > > assigning like s[11…14] = str is of course, yes. > only then - that is if

Re: [swift-evolution] Strings in Swift 4

Hi Dave Thanks for your time to go in to this an explain. This optimising goes much further then I thought. > That's fine. Please don't be offended that I don't wish to argue it further. > It's been an interesting exercise while I'm on vacation and I hoped it would > lay out some general

Re: [swift-evolution] Strings in Swift 4

Hi David & Dave can you explain that in more detail? >> Wouldn’t that turn simple character access into a mutating function? assigning like s[11…14] = str is of course, yes. only then - that is if the character array thus has been changed - it has to update the string in storage, yes. but

Re: [swift-evolution] Strings in Swift 4

Sent from my moss-covered three-handled family gradunza > On Feb 23, 2017, at 2:04 PM, Ted F.A. van Gaalen > wrote: > > >> On 23 Feb 2017, at 02:24, Dave Abrahams wrote: >> >> Equally a non-starter. All known threadsafe schemes that require

Re: [swift-evolution] Strings in Swift 4

Exactly. Sent from my moss-covered three-handled family gradunza > On Feb 24, 2017, at 9:49 AM, David Sweeris wrote: > > >>> On Feb 23, 2017, at 4:04 PM, Ted F.A. van Gaalen via swift-evolution >>> wrote: >>> >>> >> >>> On 23 Feb 2017, at

Re: [swift-evolution] Strings in Swift 4

> On Feb 23, 2017, at 4:04 PM, Ted F.A. van Gaalen via swift-evolution > wrote: > > >> On 23 Feb 2017, at 02:24, Dave Abrahams > > wrote: >> >> Equally a non-starter. All known threadsafe schemes that require

Re: [swift-evolution] Strings in Swift 4

> On 23 Feb 2017, at 02:24, Dave Abrahams wrote: > > Equally a non-starter. All known threadsafe schemes that require caches to be > updated upon non-mutating operations have horrible performance issues, and > further this would penalize all string code by reserving space

Re: [swift-evolution] Strings in Swift 4

Equally a non-starter. All known threadsafe schemes that require caches to be updated upon non-mutating operations have horrible performance issues, and further this would penalize all string code by reserving space for the cache and filling it even for the vast majority of operations that

Re: [swift-evolution] Strings in Swift 4

Thank you Michael, I did that already in this extension: (as written before) extension String { var count: Int { get { return self.characters.count } } // properties in extensions not possible // var ar = Array(self.characters)

Re: [swift-evolution] Strings in Swift 4

Given that the behavior you desire is literally a few key strokes away (see below), it would be unfortunate to pessimize the internal representation of Strings for every application. This would destroy the applicability of the Swift standard library to entire areas of computing such as

Re: [swift-evolution] Strings in Swift 4

Ted, that sort of implementation grows many common strings by a factor of 8 and makes some less common strings require multiple memory allocations. Considering that our research has shown it is a big performance and energy-use win to heroically compress

Re: [swift-evolution] Strings in Swift 4

Hi Ben, thank you, yes, I know all that by now. Have seen that one goes to great lengths to optimise, not only for storage but also for speed. But how far does this need to go? In any case, optimisation should not be used as an argument for restricting a PLs functionality that is to refrain

Re: [swift-evolution] Strings in Swift 4

Hi Ted, While Character is the Element type for String, it would be unsuitable for a String’s implementation to actually use Character for storage. Character is fairly large (currently 9 bytes), very little of which is used for most values. For unusual graphemes that require more storage, it

Re: [swift-evolution] Strings in Swift 4

Hi Ben, Dave (you should not read this now, you’re on vacation :o) & Others As described in the Swift Standard Library API Reference: The Character type represents a character made up of one or more Unicode scalar values, grouped by a Unicode boundary algorithm. Generally, a Character

Re: [swift-evolution] Strings in Swift 4

ift-evolution evolut...@swift.org> > Date: 01/31/2017 02:24 PM > Subject: Re: [swift-evolution] Strings in Swift 4 > Sent by: dabrah...@apple.com > > > on Mon Jan 30 2017, Olivier Tardieu wrote: > > > Thanks for the clarifications. > > More comments below. &g

Re: [swift-evolution] Strings in Swift 4

> On Feb 10, 2017, at 12:38 PM, Hooman Mehr via swift-evolution > wrote: > > >> On Feb 9, 2017, at 6:50 PM, Shawn Erickson > > wrote: >> >> >> >> On Thu, Feb 9, 2017 at 3:45 PM Hooman Mehr >

Re: [swift-evolution] Strings in Swift 4

> On 11 Feb 2017, at 18:33, Dave Abrahams wrote: > > All of these examples should be efficiently and expressively handled by the > pattern matching API mentioned in the proposal. They definitely do not > require random access or integer indexing. > Hi Dave, then I am

Re: [swift-evolution] Strings in Swift 4

Hi Ted, Dave is on vacation next two weeks so this is a reply on behalf of both him and me: > On Feb 12, 2017, at 10:17, "Ted F.A. van Gaalen" > wrote: >> On 11 Feb 2017, at 18:33, Dave Abrahams >

Re: [swift-evolution] Strings in Swift 4

Sent from my moss-covered three-handled family gradunza > On Feb 11, 2017, at 5:16 AM, Karl Wagner wrote: > > >>> On 11 Feb 2017, at 04:23, Brent Royal-Gordon wrote: >>> >>> On Feb 10, 2017, at 5:49 PM, Jonathan Hull via swift-evolution >>>

Re: [swift-evolution] Strings in Swift 4

Sent from my moss-covered three-handled family gradunza > On Feb 9, 2017, at 3:45 PM, Hooman Mehr wrote: > > >> On Feb 9, 2017, at 3:11 PM, Dave Abrahams wrote: >> >> >> on Thu Feb 09 2017, "Ted F.A. van Gaalen" wrote: >> >>> Hello Shawn >>> Just

Re: [swift-evolution] Strings in Swift 4

One of the major (so far unstated) goals of the String rethink is to eliminate reasons for people to process textual data outside of String, though. You shouldn't have to use an array of bytes to get performance processing of ASCII, for example. Sent from my moss-covered three-handled family

Re: [swift-evolution] Strings in Swift 4

All of these examples should be efficiently and expressively handled by the pattern matching API mentioned in the proposal. They definitely do not require random access or integer indexing. Sent from my moss-covered three-handled family gradunza > On Feb 9, 2017, at 5:09 PM, Ted F.A. van

Re: [swift-evolution] Strings in Swift 4

> On 11 Feb 2017, at 04:23, Brent Royal-Gordon wrote: > >> On Feb 10, 2017, at 5:49 PM, Jonathan Hull via swift-evolution >> wrote: >> >> An easier to implement, but slightly less useful approach, would be to have >> methods which take an

Re: [swift-evolution] Strings in Swift 4

> On Feb 10, 2017, at 5:49 PM, Jonathan Hull via swift-evolution > wrote: > > An easier to implement, but slightly less useful approach, would be to have > methods which take an array of indexes along with the proposed change, and > then it adjusts the indexes (or

Re: [swift-evolution] Strings in Swift 4

Ok, appending was a dumb example (It has been a long week). Imagine the same idea with insert/remove… Thanks, Jon > On Feb 10, 2017, at 5:49 PM, Jonathan Hull via swift-evolution > wrote: > > This is the biggest need I have from strings (and collections) that is

Re: [swift-evolution] Strings in Swift 4

This is the biggest need I have from strings (and collections) that is not being met, and is I think why people reach for integers. I have a stored index which points to something important, and if the string/collection is edited, I now have to update the index to be correct. Lots of chances

Re: [swift-evolution] Strings in Swift 4

Hi Ted, Here’s a sketch of one way to handle this kind of processing without requiring integer indexing. Hopefully not too buggy though I haven’t tested it extensively :). Here I’m stashing the parsed values in a dictionary, but you could also write code to insert them into a proper data

Re: [swift-evolution] Strings in Swift 4

> On Feb 9, 2017, at 6:50 PM, Shawn Erickson wrote: > > > > On Thu, Feb 9, 2017 at 3:45 PM Hooman Mehr > wrote: >> On Feb 9, 2017, at 3:11 PM, Dave Abrahams > > wrote: >> >> >> on

Re: [swift-evolution] Strings in Swift 4

Please see in-line response below > On 10 Feb 2017, at 03:56, Shawn Erickson wrote: > > > On Thu, Feb 9, 2017 at 5:09 PM Ted F.A. van Gaalen > wrote: >> On 10 Feb 2017, at 00:11, Dave Abrahams >

Re: [swift-evolution] Strings in Swift 4

Hello Shawn Just google with any programming language name and “string manipulation” and you have enough reading for a week or so :o) TedvG > On 9 Feb 2017, at 16:48, Shawn Erickson wrote: > > I also wonder what folks are actually doing that require indexing into > strings.

Re: [swift-evolution] Strings in Swift 4

Regarding the string-collection question, I have some corner-cases which may be worth consideration: Is it safe to pass a view (EG: String.UTF8View) to a generic function/initialiser over Collections, which either has an inout parameter or stores the result? I could imagine these situations

Re: [swift-evolution] Strings in Swift 4

On Thu, Feb 9, 2017 at 5:09 PM Ted F.A. van Gaalen wrote: > On 10 Feb 2017, at 00:11, Dave Abrahams wrote: > > > on Thu Feb 09 2017, "Ted F.A. van Gaalen" > wrote: > > Hello Shawn > Just google with any programming language name and “string

Re: [swift-evolution] Strings in Swift 4

On Thu, Feb 9, 2017 at 3:45 PM Hooman Mehr wrote: > On Feb 9, 2017, at 3:11 PM, Dave Abrahams wrote: > > > on Thu Feb 09 2017, "Ted F.A. van Gaalen" > wrote: > > Hello Shawn > Just google with any programming language name and “string manipulation” > and

Re: [swift-evolution] Strings in Swift 4

> On Feb 9, 2017, at 3:11 PM, Dave Abrahams wrote: > > > on Thu Feb 09 2017, "Ted F.A. van Gaalen" wrote: > >> Hello Shawn >> Just google with any programming language name and “string manipulation” >> and you have enough reading for a week or so :o) >> TedvG > > That

Re: [swift-evolution] Strings in Swift 4

on Thu Feb 09 2017, "Ted F.A. van Gaalen" wrote: > Hello Shawn > Just google with any programming language name and “string manipulation” > and you have enough reading for a week or so :o) > TedvG That truly doesn't answer the question. It's not, “why do people index strings with integers

Re: [swift-evolution] Strings in Swift 4

> On Feb 9, 2017, at 7:48 AM, Shawn Erickson via swift-evolution > wrote: > > I also wonder what folks are actually doing that require indexing into > strings. I would love to see some real world examples of what and why > indexing into a string is needed. Who is

Re: [swift-evolution] Strings in Swift 4

I also wonder what folks are actually doing that require indexing into strings. I would love to see some real world examples of what and why indexing into a string is needed. Who is the end consumer of that string, etc. Do folks have so examples? -Shawn On Thu, Feb 9, 2017 at 6:56 AM Ted F.A.

Re: [swift-evolution] Strings in Swift 4

Hello Hooman That invalidates my assumptions, thanks for evaluating it's more complex than I thought. Kind Regards Ted > On 8 Feb 2017, at 00:07, Hooman Mehr wrote: > > >> On Feb 7, 2017, at 12:19 PM, Ted F.A. van Gaalen via swift-evolution >>

Re: [swift-evolution] Strings in Swift 4

> On 7 Feb 2017, at 19:44, Dave Abrahams wrote: > > > on Tue Feb 07 2017, "Ted F.A. van Gaalen" wrote: > >>> On 7 Feb 2017, at 05:42, Karl Wagner wrote: >>> On 6 Feb 2017, at 19:29, Ted F.A. van Gaalen via swift-evolution

Re: [swift-evolution] Strings in Swift 4

Thanks ..seeing now all this being heavily intertwined with external libs ICU etc. then yes, too much effort for too little (making fixed width Unicode strings) Why am i doing this? Unicode is a wasp nest, how do you survive, Dave ? :o) But I do use “random string access" e.g. extracting

Re: [swift-evolution] Strings in Swift 4

> On 7 Feb 2017, at 05:42, Karl Wagner wrote: > >> >> On 6 Feb 2017, at 19:29, Ted F.A. van Gaalen via swift-evolution >> > wrote: >> >>> >>> On 6 Feb 2017, at 19:10, David Waite

Re: [swift-evolution] Strings in Swift 4

on Mon Feb 06 2017, David Waite wrote: >> On Feb 6, 2017, at 10:26 AM, Ted F.A. van Gaalen via swift-evolution >> > wrote: >> >> Hi Dave, >> Oops! yes, you’re right! >> I did read again more thoroughly about Unicode > >> and how Unicode is handled within Swift...

Re: [swift-evolution] Strings in Swift 4

> On Feb 6, 2017, at 10:26 AM, Ted F.A. van Gaalen via swift-evolution > wrote: > > Hi Dave, > Oops! yes, you’re right! > I did read again more thoroughly about Unicode > and how Unicode is handled within Swift... > -should have done that before I write something-

Re: [swift-evolution] Strings in Swift 4

> On 6 Feb 2017, at 19:10, David Waite wrote: > >> >> On Feb 6, 2017, at 10:26 AM, Ted F.A. van Gaalen via swift-evolution >> wrote: >> >> Hi Dave, >> Oops! yes, you’re right! >> I did read again more thoroughly about Unicode >> and

Re: [swift-evolution] Strings in Swift 4

> On Feb 6, 2017, at 10:26 AM, Ted F.A. van Gaalen via swift-evolution > wrote: > > Hi Dave, > Oops! yes, you’re right! > I did read again more thoroughly about Unicode > and how Unicode is handled within Swift... > -should have done that before I write something-

Re: [swift-evolution] Strings in Swift 4

We know that: The cumbersome complexity of current Swift String handling and programming is caused by the fact that Unicode characters are stored and processed as streams/arrays with elements of variable-width (1...4 bytes for each character) Unicode characters. Because of that, direct

Re: [swift-evolution] Strings in Swift 4

Hi Dave, Oops! yes, you’re right! I did read again more thoroughly about Unicode and how Unicode is handled within Swift... -should have done that before I write something- sorry. Nevertheless: How about this solution: (if I am not making other omissions in my thinking again) -Store the

Re: [swift-evolution] Strings in Swift 4

> On Feb 5, 2017, at 2:57 PM, Ted F.A. van Gaalen wrote: > > However, that is not the case with UTF-32, because with UTF-32 encoding > each character has a fixed-width and always occupies exactly 4 bytes, 32 bit. > Ergo: the problem can be easily solved: The simple

Re: [swift-evolution] Strings in Swift 4

> On Feb 5, 2017, at 02:22, Jonathan Hull via swift-evolution > wrote: > > Just out of curiosity, what are the use-cases for an infinite sequence > (as opposed to a sequence which is bounded to the type’s representable > values)? 1. The type

Re: [swift-evolution] Strings in Swift 4

Just out of curiosity, what are the use-cases for an infinite sequence (as opposed to a sequence which is bounded to the type’s representable values)? >>> >>> 1. The type may not have an inherent expressible bound (see BigInt, >>> UnsafePointer, and *many* real-life Index types).

Re: [swift-evolution] Strings in Swift 4

on Sat Feb 04 2017, Saagar Jha wrote: > Sorry, it looks like I left you hanging on this–luckily I found it when I was > cleaning my inbox. > > Overall, I believe the issue I have with the Swift String indexing > model is that indices cannot be operated on like an Int

Re: [swift-evolution] Strings in Swift 4

Sorry, it looks like I left you hanging on this–luckily I found it when I was cleaning my inbox. Overall, I believe the issue I have with the Swift String indexing model is that indices cannot be operated on like an Int can–you can multiply, divide, square, whatever you want on integer

Re: [swift-evolution] Strings in Swift 4

> On Feb 2, 2017, at 2:19 PM, Dave Abrahams wrote: > > > on Thu Feb 02 2017, Jonathan Hull wrote: > >> Just out of curiosity, what are the use-cases for an infinite sequence >> (as opposed to a sequence which is bounded to the type’s representable >> values)? > > 1. The

Re: [swift-evolution] Strings in Swift 4

on Thu Feb 02 2017, Xiaodi Wu wrote: > On Thu, Feb 2, 2017 at 9:45 AM, Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote: > > If indeed the desired semantics for ranges is that they should continue to > lack precise semantics, then an agreement

Re: [swift-evolution] Strings in Swift 4

A bit late, but I agree with Ben on all of this. We could have separate IncompleteRange and InfiniteRange types, and have a consistent world, and even figure out how to get the context-less case to pick InfiniteRange. But we don’t have to, and I don’t think it buys us anything because—as was

Re: [swift-evolution] Strings in Swift 4

On Thu, Feb 2, 2017 at 9:45 AM, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > > Sent from my iPad > > On Feb 2, 2017, at 7:11 AM, Matthew Johnson > wrote: > > > > Furthermore, we emphatically do *not* need to make the distinction you > claim

Re: [swift-evolution] Strings in Swift 4

on Thu Feb 02 2017, Jonathan Hull wrote: > Just out of curiosity, what are the use-cases for an infinite sequence > (as opposed to a sequence which is bounded to the type’s representable > values)? 1. The type may not have an inherent expressible bound (see BigInt, UnsafePointer, and *many*

Re: [swift-evolution] Strings in Swift 4

> On Feb 2, 2017, at 12:35 PM, Erica Sadun via swift-evolution > wrote: > > >> On Feb 2, 2017, at 8:58 AM, Jonathan Hull via swift-evolution >> wrote: >> >> Just out of curiosity, what are the use-cases for an infinite sequence (as >>

Re: [swift-evolution] Strings in Swift 4

> On Feb 2, 2017, at 1:19 PM, Dave Abrahams via swift-evolution > wrote: > > > on Thu Feb 02 2017, Matthew Johnson wrote: > >>> On Feb 2, 2017, at 9:45 AM, Dave Abrahams >> wrote: >>> >>> >>> >>> >> >>> >>> On

Re: [swift-evolution] Strings in Swift 4

on Thu Feb 02 2017, Jonathan Hull wrote: > I really like the IncompleteRange/RangeExpression idea! > > I don’t think that IncompleteRange/RangeExpression should, by themselves, > conform to Sequence. It > seems like necessary information is missing there. Instead,

Re: [swift-evolution] Strings in Swift 4

on Thu Feb 02 2017, Matthew Johnson wrote: >> On Feb 2, 2017, at 9:45 AM, Dave Abrahams > wrote: >> >> >> >> > >> >> On Feb 2, 2017, at 7:11 AM, Matthew Johnson > > wrote: >>

Re: [swift-evolution] Strings in Swift 4

> On Feb 2, 2017, at 8:58 AM, Jonathan Hull via swift-evolution > wrote: > > Just out of curiosity, what are the use-cases for an infinite sequence (as > opposed to a sequence which is bounded to the type’s representable values)? > > Thanks, > Jon Now that

Re: [swift-evolution] Strings in Swift 4

on Thu Feb 02 2017, Nevin Brackett-Rozinsky wrote: > So, not to be “that guy”, but does anyone recall what the status of the > actual *String* revamp for Swift 4 currently is? > > There was a lot of good discussion on the matter, and I want to make sure > it hasn’t

Re: [swift-evolution] Strings in Swift 4

> On Feb 2, 2017, at 9:45 AM, Dave Abrahams wrote: > > > > Sent from my iPad > > On Feb 2, 2017, at 7:11 AM, Matthew Johnson > wrote: > >>> Furthermore, we emphatically do *not* need to make the

Re: [swift-evolution] Strings in Swift 4

So, not to be “that guy”, but does anyone recall what the status of the actual *String* revamp for Swift 4 currently is? There was a lot of good discussion on the matter, and I want to make sure it hasn’t gotten lost or dropped. Nevin ___

Re: [swift-evolution] Strings in Swift 4

Just out of curiosity, what are the use-cases for an infinite sequence (as opposed to a sequence which is bounded to the type’s representable values)? Thanks, Jon > On Feb 2, 2017, at 7:52 AM, Dave Abrahams via swift-evolution > wrote: > > > > Sent from my iPad >

Re: [swift-evolution] Strings in Swift 4

Sent from my iPad > On Feb 2, 2017, at 7:32 AM, Matthew Johnson wrote: > > >>> On Feb 2, 2017, at 6:07 AM, Brent Royal-Gordon via swift-evolution >>> wrote: >>> >>> On Feb 2, 2017, at 3:06 AM, Jaden Geller via swift-evolution >>>

Re: [swift-evolution] Strings in Swift 4

Sent from my iPad > On Feb 2, 2017, at 7:11 AM, Matthew Johnson wrote: > >>> >>> >>> Furthermore, we emphatically do *not* need to make the distinction you >>> claim between “infinite” and “incomplete” ranges, which *is* needless >>> hairsplitting. >> >> Strongly

Re: [swift-evolution] Strings in Swift 4

> On Feb 2, 2017, at 6:07 AM, Brent Royal-Gordon via swift-evolution > wrote: > >> On Feb 2, 2017, at 3:06 AM, Jaden Geller via swift-evolution >> wrote: >> >> It's not infinite (else subscript would trap) > > I'm not necessarily a fan

Re: [swift-evolution] Strings in Swift 4

I really like the IncompleteRange/RangeExpression idea! I don’t think that IncompleteRange/RangeExpression should, by themselves, conform to Sequence. It seems like necessary information is missing there. Instead, there needs to be a conditional conformance to Sequence based on another

Re: [swift-evolution] Strings in Swift 4

> On Feb 2, 2017, at 3:06 AM, Jaden Geller via swift-evolution > wrote: > > It's not infinite (else subscript would trap) I'm not necessarily a fan of the idea of allowing you to iterate over an `IncompleteRange`, but I have to ask: What do you imagine an infinite

Re: [swift-evolution] Strings in Swift 4

> On Feb 1, 2017, at 2:30 PM, Nate Cook via swift-evolution > wrote: > > With a lot of these new features, it helps me greatly to see them in action. > I've built a poor man's version of these incomplete ranges in a Swift Sandbox > here: >

Re: [swift-evolution] Strings in Swift 4

With a lot of these new features, it helps me greatly to see them in action. I've built a poor man's version of these incomplete ranges in a Swift Sandbox here: http://swiftlang.ng.bluemix.net/#/repl/58925f5d42b65e6dce9a5bea This implementation suffers greatly from a lack of generic

Re: [swift-evolution] Strings in Swift 4

I think Dave has already made these points separately but it probably helps to recap more explicitly the behavior we expect from “x…" Names are just for discussion purposes, exact naming can be left as a separate discussion from functionality: - Informally, one-sided ranges are a thing.

Re: [swift-evolution] Strings in Swift 4

I had read the discussion live as it happened. And just now I went back to see Jaden’s posts again: there are only a handful, and all are quite brief. To the extent that they “sketched a direction”, I would say no. We should instead base the proposal on ideas laid out by Dave Abrahams, Brent

Re: [swift-evolution] Strings in Swift 4

Drafting a proposal sounds like a good idea, to establish all the relevant information in one place. I don’t recall off the top of my head what directions Jaden sketched out, but as long as the proposal hits the high points of the uses and benefits, and summarizes the discussion and alternatives,

Re: [swift-evolution] Strings in Swift 4

> On Feb 1, 2017, at 9:52 AM, Nevin Brackett-Rozinsky > wrote: > > Drafting a proposal sounds like a good idea, to establish all the relevant > information in one place. I don’t recall off the top of my head what > directions Jaden sketched out, but as long

Re: [swift-evolution] Strings in Swift 4

> On Feb 1, 2017, at 9:15 AM, Nevin Brackett-Rozinsky > wrote: > > I am also +1. > > > On Wed, Feb 1, 2017 at 9:29 AM, Matthew Johnson via swift-evolution > > wrote: > > I’m still curious how

Re: [swift-evolution] Strings in Swift 4

I am also +1. On Wed, Feb 1, 2017 at 9:29 AM, Matthew Johnson via swift-evolution < swift-evolution@swift.org> wrote: > > I’m still curious how postfix `…` would impact our options for variadic > generics and tuple unpacking in the future. Somebody who happens to have originally created

Re: [swift-evolution] Strings in Swift 4

Brent-- In general, I agree with the direction of your thinking. Time constraints prevent me from responding as thoroughly as I'd like, but briefly, where we don't agree at the moment boil down to a few points: * Agree that "to" vs "through" is not ideal. However, having spent a lot of time on

Re: [swift-evolution] Strings in Swift 4

> On Feb 1, 2017, at 6:58 AM, Brent Royal-Gordon via swift-evolution > wrote: > >> On Jan 31, 2017, at 2:04 PM, Xiaodi Wu via swift-evolution >> wrote: >> >> Therefore I'd conclude that `arr[upTo: i]` is the most consistent spelling. >>

Re: [swift-evolution] Strings in Swift 4

I entirely agree with you on the desired behavior of `zip(...)`. However, if you insist on 0... being notionally an infinite range, then you would have to insist on `for i in 0...` also trapping. Which is not a big deal, IMO, but will surely make the anti-trapping crowd upset. The bigger issue

Re: [swift-evolution] Strings in Swift 4

> On Jan 31, 2017, at 2:04 PM, Xiaodi Wu via swift-evolution > wrote: > > Therefore I'd conclude that `arr[upTo: i]` is the most consistent spelling. > It also yields the sensible result that `arr[from: i][upTo: j] == arr[upTo: > j][from: i] == arr[i..

Re: [swift-evolution] Strings in Swift 4

on Tue Jan 31 2017, Xiaodi Wu wrote: > But that's not getting to the biggest hitch with your proposal. If > subscript were lenient, then `arr[lenient: 42...]` would also have to give > you a result even if `arr.count == 21`. > > This is not at all what Dave Abrahams was proposing, though

Re: [swift-evolution] Strings in Swift 4

Sent from my iPad > On Jan 31, 2017, at 7:28 PM, Xiaodi Wu wrote: > >> On Tue, Jan 31, 2017 at 7:08 PM, Matthew Johnson >> wrote: >> >>> On Jan 31, 2017, at 6:54 PM, Xiaodi Wu wrote: >>> On Tue, Jan 31, 2017 at 6:40

Re: [swift-evolution] Strings in Swift 4

> On Jan 31, 2017, at 6:54 PM, Xiaodi Wu wrote: > > On Tue, Jan 31, 2017 at 6:40 PM, Matthew Johnson > wrote: > >> On Jan 31, 2017, at 6:15 PM, Xiaodi Wu > > wrote:

Re: [swift-evolution] Strings in Swift 4

> On Jan 31, 2017, at 6:15 PM, Jaden Geller wrote: > > >> On Jan 31, 2017, at 4:09 PM, Matthew Johnson via swift-evolution >> > wrote: >> >> >>> On Jan 31, 2017, at 5:35 PM, Xiaodi Wu via swift-evolution

Re: [swift-evolution] Strings in Swift 4

On Tue, Jan 31, 2017 at 6:40 PM, Matthew Johnson wrote: > > On Jan 31, 2017, at 6:15 PM, Xiaodi Wu wrote: > > On Tue, Jan 31, 2017 at 6:09 PM, Matthew Johnson > wrote: > >> >> On Jan 31, 2017, at 5:35 PM, Xiaodi Wu via

Re: [swift-evolution] Strings in Swift 4

> On Jan 31, 2017, at 6:15 PM, Xiaodi Wu wrote: > > On Tue, Jan 31, 2017 at 6:09 PM, Matthew Johnson > wrote: > >> On Jan 31, 2017, at 5:35 PM, Xiaodi Wu via swift-evolution >>

Re: [swift-evolution] Strings in Swift 4

On Tue, Jan 31, 2017 at 6:27 PM, Jaden Geller wrote: > > On Jan 31, 2017, at 4:20 PM, Xiaodi Wu wrote: > > On Tue, Jan 31, 2017 at 6:15 PM, Jaden Geller > wrote: > >> >> On Jan 31, 2017, at 4:09 PM, Matthew Johnson via

Re: [swift-evolution] Strings in Swift 4

On Tue, Jan 31, 2017 at 5:58 PM, Matthew Johnson wrote: > > On Jan 31, 2017, at 5:20 PM, Xiaodi Wu wrote: > > On Tue, Jan 31, 2017 at 5:04 PM, Matthew Johnson > wrote: > >> >> I think it’s fair to say that we get to decide on

Re: [swift-evolution] Strings in Swift 4

On Tue, Jan 31, 2017 at 6:15 PM, Jaden Geller wrote: > > On Jan 31, 2017, at 4:09 PM, Matthew Johnson via swift-evolution < > swift-evolution@swift.org> wrote: > > > On Jan 31, 2017, at 5:35 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > On

Re: [swift-evolution] Strings in Swift 4

> On Jan 31, 2017, at 4:20 PM, Xiaodi Wu wrote: > > On Tue, Jan 31, 2017 at 6:15 PM, Jaden Geller > wrote: > >> On Jan 31, 2017, at 4:09 PM, Matthew Johnson via swift-evolution >>

Re: [swift-evolution] Strings in Swift 4

> On Jan 31, 2017, at 4:15 PM, Xiaodi Wu via swift-evolution > wrote: > > We don't have partially applied functions doubling as function calls with > default arguments. I think this best summarizes my problem with simultaneously treating `0…` as a partially

Re: [swift-evolution] Strings in Swift 4

> On Jan 31, 2017, at 4:09 PM, Matthew Johnson via swift-evolution > wrote: > > >> On Jan 31, 2017, at 5:35 PM, Xiaodi Wu via swift-evolution >> > wrote: >> >> On Tue, Jan 31, 2017 at 5:28 PM, David

  1   2   3   >