Re: [swift-evolution] [Accepted] SE-0112: Improved NSError Bridging

[Jon Shier via swift-evolution]

Doug, et. al.:
Thanks for the discussion so far; I think I understand the new error 
model from a user’s perspective. However, now I’m looking for some guidance for 
framework developers. While the proposal laid out the system types would wrap 
imported Objective-C errors, I don’t see anything for the desired patters for 
Swift native errors. For instance, in Alamofire we currently either pass 
through the NSErrors we receive from underlying frameworks or generate our own, 
usually in our own domain, with unique error codes and such. I can see my way 
to translating most of these directly to an AFError type that conforms to 
Error, but some of them require associated values (e.g. the content type 
validation error needs to know the expected and actual content types). In these 
cases I’m having a hard time see how these things should be stored, especially 
when only some cases need this data. Of course, I’m away of the LocalizedError 
protocol, but that doesn’t seem applicable here, as I’m mostly wondering about 
storage. Rather than creating types similar to the system error types, perhaps 
a basic enum based error would work, where only the cases that need it capture 
values? I’m mostly curious what the anticipated pattern was here.



Jon

> On Aug 6, 2016, at 1:15 AM, Kevin Ballard via swift-evolution 
>  wrote:
> 
>> 
>> On Aug 5, 2016, at 7:36 PM, Erica Sadun > > wrote:
>> 
>> On Aug 5, 2016, at 8:10 PM, Kevin Ballard > > wrote:
>>> 
 
 On Aug 5, 2016, at 5:16 PM, Erica Sadun > wrote:
 
 
> On Aug 5, 2016, at 4:19 PM, Douglas Gregor via swift-evolution 
> > wrote:
> 
>> 
>> On Aug 5, 2016, at 12:59 PM, Kevin Ballard via swift-evolution 
>> > wrote:
>> 
>> If all you want to do is get the localized description, then you can 
>> just say `(error as NSError).localizedDescription`.
> 
> Just ‘error.localizedDescription’ works now. That was part of SE-0112.
> 
>   - Doug
 
 Would it kill to allow:
 
 let err = NSError()
 err.localizedDescription = "bad things happen"
 throw err
 
 or even
 
 throw NSError("Bad things happen")
 
 for lightweight use? I ended up refactoring entirely to enum : Error 
 because Swift yelled at me for using NSError(): "this results in an 
 invalid NSError instance. It will raise an exception in a future release. 
 Please call errorWithDomain:code:userInfo: or 
 initWithDomain:code:userInfo:. This message shown only once."
 
 enum Errors: Error {case bad}
 Errors.bad._code // 0
 Errors.bad._domain // "Errors"
 Errors.bad._userInfo // Optional({})
 Errors.bad.localizedDescription // "The operation couldn’t be completed. 
 (Errors error 0.)"
 
 Bleh.
>>> 
>>> NSErrors need a domain/code. It doesn’t make much sense to throw one 
>>> without it. And besides, there’s a fairly trivial solution for doing what 
>>> you want to do:
>>> 
>>> struct GenericError: LocalizedError {
>>> let message: String
>>> init(_ message: String) {
>>> self.message = message
>>> }
>>> var errorDescription: String? {
>>> return message
>>> }
>>> }
>>> 
>>> Now you can just say `throw GenericError(“Bad things happen”)`.
>>> 
>>> -Kevin Ballard
>> 
>> I know I can build workarounds but if we're going to have the 
>> error.localizedDescription, making it an initializable/assignable property 
>> just seems like a nice thing™. Why can't we have nice things™?
> 
> I don’t actually think it’s a nice thing™ to have it be assignable like you 
> ask, because we should be encouraging people to use typed errors. You may as 
> well just ask for String to conform to Error (in fact, you could just add 
> that conformance yourself and skip the GenericError wrapper entirely).
> 
> -Kevin
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Proposal for swift build linux on Mac os x

[Saagar Jha via swift-evolution]

Apple's bug reporter would be a better place.
On Sat, Aug 13, 2016 at 16:16 Félix Cloutier 
wrote:

> The swift-evolution mailing list is about the language itself, Xcode is
> independent. I don't know where you could try to push that suggestion.
>
>
> Félix
>
> Le 13 août 2016 à 16:40:42, apps4u via swift-evolution <
> swift-evolution@swift.org> a écrit :
>
> I have a Proposal but I'm not sure if Its the right place to propose but
> as it has to do with building Swift So I'm going to submit here. So Please
> let me know if that is not the place to propose this feature. As it
> includes Xcode.
>
>
> Ok So this is a proposal for being able to build swift for linux on Mac Os
> X in Xcode just like a native target.
>
> With the release of Hypervisor.framework It would be good if from within
> Xcode I can create a project with a Linux Target and when clicking Build
> and run it create a VM running a small linux Kernel using
> Hypervisor.framework.
> By using Hypervisor.framework it would be better integrated into the tools
> as it has a small foot print. The idea would be to have the VM downloaded
> before a build. The linux VM should be small and only have the required
> software to test a server and using the hypervisor.framework the project
> build folder can be attached to the vm at build time so the working with
> different projects at the same time would not require lots of VM.
>
> Now I know that this would be best if integrated into Xcode and this is
> the Swift Language mailing list but Swift build is part of the Language.
>
> This could also be used to debugging. Now Its possible now to use Docker
> to run a linux vm and have a shared folder for your project and some
> scripts to kick off the build. But it take time to setup per project and is
> not the Experience i would expect in Xcode.
>
> Now My first thought when I found out about Hypervisor.framework that the
> reason it was created was to add linux targets to Xcode.
>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Proposal for swift build linux on Mac os x

[Félix Cloutier via swift-evolution]

The swift-evolution mailing list is about the language itself, Xcode is 
independent. I don't know where you could try to push that suggestion.

Félix

> Le 13 août 2016 à 16:40:42, apps4u via swift-evolution 
>  a écrit :
> 
> I have a Proposal but I'm not sure if Its the right place to propose but as 
> it has to do with building Swift So I'm going to submit here. So Please let 
> me know if that is not the place to propose this feature. As it includes 
> Xcode.
> 
> 
> Ok So this is a proposal for being able to build swift for linux on Mac Os X 
> in Xcode just like a native target.
> 
> With the release of Hypervisor.framework It would be good if from within 
> Xcode I can create a project with a Linux Target and when clicking Build and 
> run it create a VM running a small linux Kernel using Hypervisor.framework. 
> By using Hypervisor.framework it would be better integrated into the tools as 
> it has a small foot print. The idea would be to have the VM downloaded before 
> a build. The linux VM should be small and only have the required software to 
> test a server and using the hypervisor.framework the project build folder can 
> be attached to the vm at build time so the working with different projects at 
> the same time would not require lots of VM. 
> 
> Now I know that this would be best if integrated into Xcode and this is the 
> Swift Language mailing list but Swift build is part of the Language.
> 
> This could also be used to debugging. Now Its possible now to use Docker to 
> run a linux vm and have a shared folder for your project and some scripts to 
> kick off the build. But it take time to setup per project and is not the 
> Experience i would expect in Xcode.
> 
> Now My first thought when I found out about Hypervisor.framework that the 
> reason it was created was to add linux targets to Xcode.
> 
> 
>  
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Proposal for swift build linux on Mac os x

[apps4u via swift-evolution]

I have a Proposal but I'm not sure if Its the right place to propose but as it 
has to do with building Swift So I'm going to submit here. So Please let me 
know if that is not the place to propose this feature. As it includes Xcode.
Ok So this is a proposal for being able to build swift for linux on Mac Os X in 
Xcode just like a native target.

With the release of Hypervisor.framework It would be good if from within Xcode 
I can create a project with a Linux Target and when clicking Build and run it 
create a VM running a small linux Kernel using Hypervisor.framework. 
By using Hypervisor.framework it would be better integrated into the tools as 
it has a small foot print. The idea would be to have the VM downloaded before a 
build. The linux VM should be small and only have the required software to test 
a server and using the hypervisor.framework the project build folder can be 
attached to the vm at build time so the working with different projects at the 
same time would not require lots of VM. 

Now I know that this would be best if integrated into Xcode and this is the 
Swift Language mailing list but Swift build is part of the Language.

This could also be used to debugging. Now Its possible now to use Docker to run 
a linux vm and have a shared folder for your project and some scripts to kick 
off the build. But it take time to setup per project and is not the Experience 
i would expect in Xcode.

Now My first thought when I found out about Hypervisor.framework that the 
reason it was created was to add linux targets to Xcode.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] What're the Swift team's thoughts on Go's concurrency?

[Paulo Faria via swift-evolution]

Just so you know, it’s already possible to use coroutines in Swift with Venice.

https://github.com/VeniceX/Venice 


> On Aug 11, 2016, at 7:36 PM, Dan Stenmark via swift-evolution 
>  wrote:
> 
> Guys, as I have already mentioned a couple of times in this thread, let’s 
> please not turn this into a explicit discussion about how Swift could do 
> concurrency.  That discussion is at least a few more months out, especially 
> with memory ownership ala Rust/Cyclone being explored for Swift 4.  I 
> intended this thread to be about general language & runtime design theory 
> above all else, and I’m sure the team is already quite weary of folks jumping 
> the gun and posting their pitches.
> 
> Dan
> 
>> On Aug 11, 2016, at 3:24 PM, Goffredo Marocchi via swift-evolution 
>> > wrote:
>> 
>> LLVM is getting actual coroutine support, do you think it is going to help 
>> Swift started in this direction?
>> 
>> Sent from my iPhone
>> 
>> On 11 Aug 2016, at 22:17, Slava Pestov > > wrote:
>> 
>>> 
 On Aug 11, 2016, at 11:47 AM, Goffredo Marocchi via swift-evolution 
 > wrote:
 
 Thanks for the concise and clear review of green threads :). I can 
 understand the concerns of runtime implementation when the runtime of the 
 language is replacing the kernel scheduler.
 
 Sent from my iPhone
>>> 
>>> One interesting thing that you can do to get around the limitations is to 
>>> run blocking system calls in their own special thread pool off to the side. 
>>> This is how node.js deals with blocking I/O I believe. However this seems 
>>> like it would add a lot of overhead, and it’s probably not a direction we 
>>> want to go in with Swift. Of course nothing prevents users from developing 
>>> their own thread pool libraries, if they so choose. Even coroutines would 
>>> not be too difficult to do with Swift, since we don’t do anything funny 
>>> with the callstack. So the usual tricks should work.
>>> 
>>> Slava
>>> 
 
 On 11 Aug 2016, at 19:09, Kevin Ballard > wrote:
 
> AIUI, fibers are basically coroutines. Even the Naughty Dog presentation 
> says that fibers are run on threads, and you have to make an explicit 
> call to switch between fibers. Looking at Ruby's Fiber type, that's also 
> an explicit coroutine, where you actually yield up a value when you yield 
> your fiber (which is exactly what coroutines do).
> 
> So basically, green threading is preemptive multithreading where the 
> preempting is done in user-space by the runtime (so it only happens at 
> specific points where your code calls back into the runtime, but it can 
> happen at any of those points), and multiple green threads get scheduled 
> onto the same OS thread, whereas fibers is cooperative multithreading 
> where your code explicitly yields back to the runtime to switch fibers.
> 
> Of course I could be wrong, but that's the impression I got after reading 
> a few different things about Fibers.
> 
> -Kevin
> 
> On Thu, Aug 11, 2016, at 10:54 AM, Goffredo Marocchi wrote:
>> Hello Kevin,
>> I may be wrong in my equating support for fibers to green threads (and 
>> the runtime cost of supporting them), but I do have seen and linked to a 
>> presentation of the use and more than trivial benefits to Naughty Dog's 
>> engine in utilising the 8 Jaguar x86 cores in the PlayStation 4 CPU. 
>> Although like you said, it did not come for free or without evident pain 
>> points for them.
>> 
>> On Thu, Aug 11, 2016 at 6:50 PM, Kevin Ballard > > wrote:
>> 
>> I'm confused by your email. Rust is all about performance, and embedded 
>> devices are one of the targets for Rust. And I can't think of any 
>> language that uses green threading that is appropriate for constrained 
>> devices (e.g. Go definitely isn't appropriate for that). One of the 
>> arguments for getting rid of green threading in Rust is that the extra 
>> runtime complexity imposed a performance cost.
>> 
>> 
>> -Kevin
>> 
>> 
>> On Thu, Aug 11, 2016, at 10:36 AM, Goffredo Marocchi wrote:
>>> Thanks Kevin, I think they have accepted that they do not need to enter 
>>> every segment of computing so the extra performance they could get on 
>>> some devices is not worth the risk and the complexity it brings. Not 
>>> everyone is trying to cram complex 3D experiences at 60-90+ FPS on a 
>>> console like constrained devices and I guess Rust is not targeting that 
>>> right now :).
>>> 
>>> On Thu, Aug 11, 2016 at 6:12 PM, Kevin Ballard via swift-evolution 

Re: [swift-evolution] [Late Pitch] Deprecations, Moves, and Renames

[Dave Abrahams via swift-evolution]

on Fri Aug 12 2016, Ben Rimmington  wrote:

>> On 12 Aug 2016, at 21:03, Dave Abrahams wrote:
>> 
>>> on Fri Aug 12 2016, Ben Rimmington wrote:
>>> 
 On 9 Aug 2016, at 20:09, Dave Abrahams wrote:
>
 
 Deprecate the ExpressibleByStringInterpolation protocol with a
 message indicating that its design is expected to change.  We know
 this protocol to be mis-designed
 (https://bugs.swift.org/browse/SR-1260) and limited
 (https://bugs.swift.org/browse/SR-2303), but there's no time to fix it
 for Swift 3.  If we knew what the new design should look like, we
 might be able to calculate that the current API is supportable in a
 forward-compatible way (as we do for Comparable).  Unfortunately, we
 do not.
>>> 
>>> Can the deprecation of ExpressibleByStringInterpolation be reverted next 
>>> year,
>>> if a backwards-compatible design is proposed for Swift 4.0?
>> 
>> Yes, that's the plan, even if a backwards-compatible design isn't
>> proposed.  The reason to deprecate it now is that we're not sure a
>> backwards-compatible design will be possible.
>
> The only downside is when manually converting to current Swift syntax:
>
> 1. ⚠️ 'StringInterpolationConvertible' is deprecated: 
> renamed to 'ExpressibleByStringInterpolation'
>
> 2. ☑️ Fix-it: Use 'ExpressibleByStringInterpolation' instead
>
> 3. ⚠️ 'ExpressibleByStringInterpolation' is deprecated: 
> it will be replaced or redesigned in Swift 4.0.  
> Instead of conforming to 'ExpressibleByStringInterpolation', 
> consider adding an 'init(_:String)'

That's bad; we'll make sure to update the unavailable annotation for
StringInterpolationConvertible so this doesn't happen!

-- 
-Dave

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [late pitch] UnsafeBytes proposal

[Andrew Trick via swift-evolution]

> On Aug 13, 2016, at 7:12 AM, Félix Cloutier  wrote:
> 
> And then, we can't really use UnsafeBufferPointer for the purpose of 
> UnsafeBytes because we want to expose a different API. Is that right?

UnsafeBufferPointer should be used in the same situation that 
UnsafePointer is used for any T. A view over an array of UInt8 that can 
bypasses release bounds checks and can interoperate with C.

UnsafeBufferPointer should not be used to erase the memory’s pointee 
type.

UnsafeBytes erases the pointee type and gives algorithms a collection of bytes 
to work with. It turns out to be an important use case that I very much want to 
distinguish from the UnsafeBufferPointer use case. I don’t want to present 
users with a false analogy to UnsafeBufferPointer.

-Andy

> 
>> Le 13 août 2016 à 01:44:28, Andrew Trick > > a écrit :
>> 
>> 
>>> On Aug 13, 2016, at 12:17 AM, Brent Royal-Gordon >> > wrote:
>>> 
 On Aug 12, 2016, at 9:34 PM, Andrew Trick > wrote:
 
 That matrix is the correct starting point. UnsafeRawBufferPointer would be 
 in the lower right. But it would be nothing more than a raw pointer with 
 length. It wouldn’t be a collection of anything. UnsafeBytes is a powerful 
 abstraction on top of what we just called UnsafeRawBufferPointer. It is a 
 collection of typed elements `UInt8`. 
>>> 
>>> But how is that different from UnsafeBufferPointer? Put another way, what 
>>> is it about the UnsafeRawPointer -> UnsafeBytes relationship that isn't 
>>> true about UnsafePointer -> UnsafeBufferPointer, and that therefore 
>>> justifies the different name?
>> 
>> 
>> Giving UnsafeRawPointer a memory size doesn’t imply a collection of any 
>> specific type. You’re supposed to used bindMemory(to:capacity:) to get a 
>> collection out of it. Giving UnsafeBytes a name analogous to 
>> UnsafeBufferPointer only exposes that subtle difference, which is actually 
>> irrelevant. In the common case, users don’t need to know how 
>> UnsafeRawPointer works, so why start with that analogy?
>> 
>> The use cases justify the name. `UnsafeBytes` is what developers have been 
>> trying to get all along with `UnsafeBufferPointer`. The concept 
>> already exists to developers, but we have failed to give them a distinct, 
>> simple, and intuitive name for it, not to mention a correct implementation.
>> 
>> -Andy
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [late pitch] UnsafeBytes proposal

[Andrew Trick via swift-evolution]

> On Aug 13, 2016, at 2:56 AM, Magnus Ahltorp  wrote:
> 
>> This proposal adds basic usability for working with raw memory without 
>> breaking source. The need to provide higher level API for working with raw 
>> memory buffers has always been evident, but making improvements in this area 
>> depended on first introducing `UnsafeRawPointer`. It was not clear until the 
>> final week of source-breaking changes whether SE-0107 would make it into 
>> Swift 3. Now that it has, we should use the little remaining time to improve 
>> the migration experience and encourage correct use of the memory model by 
>> introducing a low-risk additive API.
> 
> As I wrote during the UnsafeRawPointer review, which seems to apply to this 
> proposal as well (forgive me if I have totally misunderstood the proposal):
> 
> When glancing at the examples, they strike me as mostly being marshalling, 
> which in my opinion would be better served by a safe marshalling API followed 
> by unsafe handling of the resulting buffer, and vice versa for unmarshalling. 
> I think it is very important (in the long run) that code that doesn't 
> interact with C directly has safe ways of doing inherently safe operations, 
> and not take the unsafe route just because that is the only API available.
> 
> My question is, how does this API fit into the bigger picture of marshalling, 
> and what are the benefits of using this API instead of marshalling with safe 
> buffers?
> 
> /Magnus

I agree. This proposal has `Unsafe` in its name because it’s not the final 
solution. It fills an important hole in these use cases—all of which currently 
interoperate with C—but leaves lifetime management of the memory on the table. 
It leaves the design of the marshalling feature up to the user intentionally 
because the primary goal is to migrate existing code. What you’re proposing is 
more of a new feature and less of a Swift 3 migration usability bug.

-Andy

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [late pitch] UnsafeBytes proposal

[Félix Cloutier via swift-evolution]

And then, we can't really use UnsafeBufferPointer for the purpose of 
UnsafeBytes because we want to expose a different API. Is that right?

Félix

> Le 13 août 2016 à 01:44:28, Andrew Trick  a écrit :
> 
> 
>> On Aug 13, 2016, at 12:17 AM, Brent Royal-Gordon  
>> wrote:
>> 
>>> On Aug 12, 2016, at 9:34 PM, Andrew Trick  wrote:
>>> 
>>> That matrix is the correct starting point. UnsafeRawBufferPointer would be 
>>> in the lower right. But it would be nothing more than a raw pointer with 
>>> length. It wouldn’t be a collection of anything. UnsafeBytes is a powerful 
>>> abstraction on top of what we just called UnsafeRawBufferPointer. It is a 
>>> collection of typed elements `UInt8`. 
>> 
>> But how is that different from UnsafeBufferPointer? Put another way, what is 
>> it about the UnsafeRawPointer -> UnsafeBytes relationship that isn't true 
>> about UnsafePointer -> UnsafeBufferPointer, and that therefore justifies the 
>> different name?
> 
> 
> Giving UnsafeRawPointer a memory size doesn’t imply a collection of any 
> specific type. You’re supposed to used bindMemory(to:capacity:) to get a 
> collection out of it. Giving UnsafeBytes a name analogous to 
> UnsafeBufferPointer only exposes that subtle difference, which is actually 
> irrelevant. In the common case, users don’t need to know how UnsafeRawPointer 
> works, so why start with that analogy?
> 
> The use cases justify the name. `UnsafeBytes` is what developers have been 
> trying to get all along with `UnsafeBufferPointer`. The concept 
> already exists to developers, but we have failed to give them a distinct, 
> simple, and intuitive name for it, not to mention a correct implementation.
> 
> -Andy

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [late pitch] UnsafeBytes proposal

[Magnus Ahltorp via swift-evolution]

> This proposal adds basic usability for working with raw memory without 
> breaking source. The need to provide higher level API for working with raw 
> memory buffers has always been evident, but making improvements in this area 
> depended on first introducing `UnsafeRawPointer`. It was not clear until the 
> final week of source-breaking changes whether SE-0107 would make it into 
> Swift 3. Now that it has, we should use the little remaining time to improve 
> the migration experience and encourage correct use of the memory model by 
> introducing a low-risk additive API.

As I wrote during the UnsafeRawPointer review, which seems to apply to this 
proposal as well (forgive me if I have totally misunderstood the proposal):

When glancing at the examples, they strike me as mostly being marshalling, 
which in my opinion would be better served by a safe marshalling API followed 
by unsafe handling of the resulting buffer, and vice versa for unmarshalling. I 
think it is very important (in the long run) that code that doesn't interact 
with C directly has safe ways of doing inherently safe operations, and not take 
the unsafe route just because that is the only API available.

My question is, how does this API fit into the bigger picture of marshalling, 
and what are the benefits of using this API instead of marshalling with safe 
buffers?

/Magnus

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [late pitch] UnsafeBytes proposal

[Andrew Trick via swift-evolution]

> On Aug 13, 2016, at 12:17 AM, Brent Royal-Gordon  
> wrote:
> 
>> On Aug 12, 2016, at 9:34 PM, Andrew Trick  wrote:
>> 
>> That matrix is the correct starting point. UnsafeRawBufferPointer would be 
>> in the lower right. But it would be nothing more than a raw pointer with 
>> length. It wouldn’t be a collection of anything. UnsafeBytes is a powerful 
>> abstraction on top of what we just called UnsafeRawBufferPointer. It is a 
>> collection of typed elements `UInt8`. 
> 
> But how is that different from UnsafeBufferPointer? Put another way, what is 
> it about the UnsafeRawPointer -> UnsafeBytes relationship that isn't true 
> about UnsafePointer -> UnsafeBufferPointer, and that therefore justifies the 
> different name?


Giving UnsafeRawPointer a memory size doesn’t imply a collection of any 
specific type. You’re supposed to used bindMemory(to:capacity:) to get a 
collection out of it. Giving UnsafeBytes a name analogous to 
UnsafeBufferPointer only exposes that subtle difference, which is actually 
irrelevant. In the common case, users don’t need to know how UnsafeRawPointer 
works, so why start with that analogy?

The use cases justify the name. `UnsafeBytes` is what developers have been 
trying to get all along with `UnsafeBufferPointer`. The concept already 
exists to developers, but we have failed to give them a distinct, simple, and 
intuitive name for it, not to mention a correct implementation.

-Andy
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [late pitch] UnsafeBytes proposal

[Brent Royal-Gordon via swift-evolution]

> On Aug 12, 2016, at 9:34 PM, Andrew Trick  wrote:
> 
> That matrix is the correct starting point. UnsafeRawBufferPointer would be in 
> the lower right. But it would be nothing more than a raw pointer with length. 
> It wouldn’t be a collection of anything. UnsafeBytes is a powerful 
> abstraction on top of what we just called UnsafeRawBufferPointer. It is a 
> collection of typed elements `UInt8`. 

But how is that different from UnsafeBufferPointer? Put another way, what is it 
about the UnsafeRawPointer -> UnsafeBytes relationship that isn't true about 
UnsafePointer -> UnsafeBufferPointer, and that therefore justifies the 
different name?

-- 
Brent Royal-Gordon
Architechies

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution