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

> On Apr 5, 2017, at 12:16 PM, Ben Cohen wrote: > > The idea is, if you don’t want to make repairs, you use the transcoding > primitives instead. The belief is that the old non-repairing versions (return > nil if repairs needed) weren’t useful. Yes—I was asking about the

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 >> > wrote: >> >> (or rather, given substrings will be 2-3 words, the

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

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

Re: ### C String Interop Will the `init(cString: UnsafePointer)` API be deprecated in Swift 4 mode? It was added by

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

You could even argue that what we need is a Collection wrapper that turns a pointer + a terminating sigil into a Collection… but from-C-string-creation is such a common operation that it deserves a dedicated shorthand. Non-null-terminated creation probably doesn’t. > On Mar 31, 2017, at 8:03

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

When you have a pointer and a length, you can create a fully functional Collection using UnsafeBufferPointer. This means you aren't need something that’s C interop-specific any more – just the ability to create a String from a Collection of code units of some encoding. We’ll add something to

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

I’m with you for a C intro API that support taking a non-null terminated string. I often work with API that support efficient parsing by providing pointer to a global buffer + length to report parsed strings. Without a way to create a Swift string from buffer + length, interop with such API

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

> On Mar 30, 2017, at 2:42 PM, Ben Cohen via swift-evolution > wrote: > > (or rather, given substrings will be 2-3 words, the not-even-that-small > string optimization) Wait, if you're using the `startIndex` and `endIndex` words for the small substring

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

Does it? According to the documentation for the current decodeCString , it seems to accept an UnsafePointer, not a buffer pointer, and expects the string to be null-terminated. Am I missing another overload? > Le 30 mars

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

> On Mar 30, 2017, at 2:36 PM, Ben Cohen wrote: > > The big win for Unicode is it is short. We want to encourage people to write > their extensions on this protocol. We want people who previously extended > String to feel very comfortable extending Unicode. It also helps

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

On Thu, Mar 30, 2017, at 12:35 PM, Félix Cloutier via swift-evolution wrote: > I don't have much non-nitpick issues that I greatly care about; I'm in > favor of this. > > My only request: it's currently painful to create a String from a fixed- > size C array. For instance, if I have a pointer to

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

Message: 12 >>> Date: Thu, 30 Mar 2017 12:23:13 +0200 >>> From: Adrian Zubarev <adrian.zuba...@devandartist.com> >>> To: Ben Cohen <ben_co...@apple.com> >>> Cc: swift-evolution@swift.org >>> Subject: Re: [swift-evolution] [Pitch] String re

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

On Thu, Mar 30, 2017 at 10:38 AM, Ben Cohen wrote: > > On Mar 29, 2017, at 6:59 PM, Xiaodi Wu wrote: > > This looks great. The restored conformances to *Collection will be huge. > > Is this to be the first of several or the only major part of the

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

n_co...@apple.com> >> Cc: swift-evolution@swift.org >> Subject: Re: [swift-evolution] [Pitch] String revision proposal #1 >> Message-ID: <etpan.58dcdc91.583a4c4b.1...@devandartist.com> >> Content-Type: text/plain; charset="utf-8" >> >>

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

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

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

> On 30 Mar 2017, at 21:39, Robert Bennett via swift-evolution > wrote: > > Adrian, > > I think there are a few competing claims here. > > 1) Substring is a term of art used universally throughout computing, and > camel-casing it would run counter to that. > 2)

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

> In order to be able to write extensions accross both String and Substring, a > new Unicode protocol to which the two types will conform will be introduced. > For the purposes of this proposal, Unicode will be defined as a protocol to > be used whenver you would previously extend String. It

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

On Thu, Mar 30, 2017 at 3:39 PM, Robert Bennett via swift-evolution < swift-evolution@swift.org> wrote: > > > (for instance, mathematical sets may contain anything at all, including > themselves) Well actually they can’t , for…reasons

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

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

Adrian, I think there are a few competing claims here. 1) Substring is a term of art used universally throughout computing, and camel-casing it would run counter to that. 2) While subsequence is a word, its precise mathematical meaning differs from what it means in Swift. In Swift a

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

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

> On Mar 30, 2017, at 8:38 AM, Ben Cohen via swift-evolution > wrote: > > It should definitely be Substring. My rule of thumb: if you might hyphenate > it, you can capitalize it. I was going to make the same argument, but you beat me to it. "String" and

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

> Message: 12 > Date: Thu, 30 Mar 2017 12:23:13 +0200 > From: Adrian Zubarev <adrian.zuba...@devandartist.com> > To: Ben Cohen <ben_co...@apple.com> > Cc: swift-evolution@swift.org > Subject: Re: [swift-evolution] [Pitch] String revision proposal #1 > Messa

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

I don't have much non-nitpick issues that I greatly care about; I'm in favor of this. My only request: it's currently painful to create a String from a fixed-size C array. For instance, if I have a pointer to a `struct foo { char name[16]; }` in Swift where the last character doesn't have to

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

If I had to choose as a not native English speaker I’d go for SubString just for the camel case consistency across all other types. We cannot rename SubSequence to Subsequence, because that would be odd compared to all other types containing Sequence. AnySequence LazyPrefixWhileSequence

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

> > ...my vote would be to lowercase Subsequence. We can typealias > SubSequence = Subsequence to aid migration +1 didn't think that was an option. A good solution would be to have them either camel case (SubString, SubSequence) or just capitalized (Substring, Substring) either would be nice as

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

Loving it so far. `encode` and `parseScalar[Forward|Backward]` feel asymmetric. What's wrong with `decode[Forward|Backward]`? `UnicodeParseResult` really feels like it could/should be defined as `UnicodeEncoding.ParseResult` (or `DecodeResult`, given the above). I can't remember if

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

> On Mar 29, 2017, at 6:59 PM, Xiaodi Wu wrote: > > This looks great. The restored conformances to *Collection will be huge. > > Is this to be the first of several or the only major part of the manifesto to > be delivered in Swift 4? > First of several. This lays the

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

Restoring Collection conformance back to String is a big win for Swift! This revision looks great but I agree with the naming I believe it should be SubString not Substring. I think SubString looks odd written out over Substring but it keeps the convention of SubSequence. On Wed, Mar 29, 2017 at

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

I haven’t followed the topic and while reading the proposal I found it a little confusing that we have inconsistent type names. I’m not a native English speaker so that’s might be the main case for my confusion here, so I’d appreciate for any clarification. ;-) SubSequence vs. Substring and

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

> On Mar 29, 2017, at 5:32 PM, Ben Cohen via swift-evolution > wrote: > > 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

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

This looks great. The restored conformances to *Collection will be huge. Is this to be the first of several or the only major part of the manifesto to be delivered in Swift 4? Nits on naming: are we calling it Substring or SubString (à la SubSequence)? and shouldn't it be UnicodeParsedResult

[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: