+1 with this clarification / revision > On Apr 6, 2017, at 5:34 PM, Ben Cohen via swift-evolution > <[email protected]> wrote: > > >> On Apr 5, 2017, at 10:32 PM, Félix Cloutier <[email protected] >> <mailto:[email protected]>> 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 comes first. IIRC, Ben said that it would be handled, but I'd like >> to have it clarified. >> >> Is it correct to assume that a UnicodeEncoding is expected to return >> UnicodeParseResult.emptyInput when it sees a NUL character (thus stopping >> before the end of the buffer if necessary)? Is it also correct to assume >> that if you need this functionality, you'll be looking at code like this? >> >> var result = "" >> UnicodeEncoding.parseForward(bufferPointer) { result += $0 } >> > > > Hi Félix, > > Having talked about it among the team, it feels like we should add an > initializer from a Collection of code units to this proposal. Therefore > given a pointer p to some utf8 and a length n, you would write: > > let b = UnsafeBuffer(start: p, count: n) > // naming opinions on the argument labels welcomed, this is probably what I’d > go for... > let s = String(b, fromEncoding: UTF8.self) > > Similar to the C string inits, this would only be a repairing initializer. > > Your request goes a little bit further though. For that, I would say that it > probably doesn’t deserve a special dedicated initializer. You could instead > search for the nil using index(of:): > > let i = b.index(of: 0) > let s = String(b[..<i], UTF8.self) // one-sided ranges pitch forthcoming ;) > > Does this sound reasonable? > >>> Le 5 avr. 2017 à 11:39, John McCall via swift-evolution >>> <[email protected] <mailto:[email protected]>> a écrit : >>> >>> Hello, Swift community! >>> >>> The review of "SE-163: String Revision: Collection Conformance, C Interop, >>> Transcoding" begins now and runs through next Tuesday, April 11th. The >>> proposal is available here: >>> >>> https://github.com/apple/swift-evolution/blob/master/proposals/0163-string-revision-1.md >>> >>> <https://github.com/apple/swift-evolution/blob/master/proposals/0163-string-revision-1.md> >>> >>> Reviews are an important part of the Swift evolution process. All reviews >>> should be sent to the swift-evolution mailing list at >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> or, if you would like to keep your feedback private, directly to the review >>> manager. When replying, please try to keep the proposal link at the top of >>> the message: >>> >>> Proposal link: >>> https://github.com/apple/swift-evolution/blob/master/proposals/0155-normalize-enum-case-representation.md >>> >>> <https://github.com/apple/swift-evolution/blob/master/proposals/0155-normalize-enum-case-representation.md> >>> >>> Reply text >>> >>> Other replies >>> >>> What goes into a review? >>> >>> The goal of the review process is to improve the proposal under review >>> through constructive criticism and, eventually, determine the direction of >>> Swift. When writing your review, here are some questions you might want to >>> answer in your review: >>> >>> • What is your evaluation of the proposal? >>> • Is the problem being addressed significant enough to warrant a change >>> to Swift? >>> • Does this proposal fit well with the feel and direction of Swift? >>> • If you have used other languages or libraries with a similar feature, >>> how do you feel that this proposal compares to those? >>> • How much effort did you put into your review? A glance, a quick >>> reading, or an in-depth study? >>> >>> More information about the Swift evolution process is available at >>> https://github.com/apple/swift-evolution/blob/master/process.md >>> <https://github.com/apple/swift-evolution/blob/master/process.md> >>> >>> Thank you, >>> >>> John McCall >>> Review Manager >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
