Re: [swift-evolution] [Concurrency] Async/Await

[Jonathan Hull via swift-evolution]

I (feel like I) understand the generator example with yield.  It is like 
return, but if you call it again, it picks up from where it left off.  Or at 
least that is my reading of what it does.

I am finding that I DO NOT understand beginAsync.  At first I thought it was 
the async/await version of 'do{}’, but as others are giving examples which use 
it in different ways, I find I don’t actually know how it works… because the 
examples aren’t using it that way.  

Can anyone give a layman’s explanation of beginAsync.  That might actually help 
with the bike shedding.  If you can’t explain something simply, then you don’t 
really understand it… and if you don’t understand it, you can’t really give it 
an intuitive name.

Thanks,
Jon 


> On Aug 20, 2017, at 10:58 PM, David Hart via swift-evolution 
>  wrote:
> 
> Hello,
> 
> Thanks for the great work on the async/await proposal! After reading it, I 
> have a few questions and comments about it, so I’m creating this thread to 
> concentrate on that topic (instead of Actors).
> 
> Generators
> 
> The proposal mentions in Problem 6 of the Motivation how generators can help 
> write sequences:
> 
> In contrast, languages that have generators allow you to write something more 
> close to this:
> 
> func getSequence() -> AnySequence {
> let seq = sequence {
> for i in 1...10 {
> yield(i*i)
> }
> }
> return AnySequence(seq)
> }
> 
> This feels very similar to me from C# where the yield keyword is used to 
> support the generator feature. But I fail to see how the coroutines as 
> described in this proposal resolve this problem. Can someone explain?
> 
> beginAsync
> 
> The documentation of the beginAsync and suspendAsync functions state:
> 
> // NB: Names subject to bikeshedding. These are low-level primitives that most
> // users should not need to interact with directly, so namespacing them
> // and/or giving them verbose names unlikely to collide or pollute code
> // completion (and possibly not even exposing them outside the stdlib to begin
> // with) would be a good idea.
> 
> But I don’t understand how they can be kept private to the standard library 
> when they are used for the important pattern of spawning off an async 
> operation from a non-async function:
> 
> Despite these problems, it is essential that the model encompasses this 
> pattern, because it is a practical necessity in Cocoa development. With this 
> proposal, it would look like this:
> 
> @IBAction func buttonDidClick(sender:AnyObject) {
>   // 1
>   beginAsync {
> // 2
> let image = await processImage()
> imageView.image = image
>   }
>   // 3
> Futures
> 
> When discussing futures, the proposal states:
> 
> The exact design for a future type deserves its own proposal, but a proof of 
> concept could look like this:
> 
> Does that sentence imply that the Core Team would welcome a Future 
> implementation into the Standard Library?
> 
> async as a subtype of throws instead of orthogonal to it
> 
> I’ve been thinking a lot about this since the proposal came out and I see a 
> few serious disadvantages at making async a subtype of throws which might 
> benefit from being discussed or/and mentioned in the proposal.
> 
> 1. We loose the automatic documentation try provides for signaling failable 
> functions:
> 
> let image = await downloadImage()
> let processedImage = await processImage(image)
> await present(MyViewController(image: image))
> 
> In my example, downloadImage can fail because of network conditions, 
> processImage can not fail, and present is the UIKit function which presents 
> view controllers and it can’t fail either. But that’s not obvious from 
> reading the code. We’ve lost information.
> 
> 2. Supporting try? and try! adds a lot of confusion:
> 
> As was mentioned by Karim Nassar is another post, if await infers try, then 
> there seems to be no good solution for supporting try? and try!:
> 
> Using await? and await! seems slightly conter-intuitive because we are 
> further mixing the concepts of coroutines/asynchronous operations with error 
> handling.
> Adding try? and try! (like suggested Chris Lattner) feels like it makes point 
> (1) by having both explicit try?/! and implicit try through await.
> 
> 3. Philosophical discussion
> 
> If async calls don’t return futures because coroutines are a generally useful 
> language features beyond the domain of async/await, doesn’t making async 
> imply throws also muddy the concept of coroutines where failable coroutine 
> operations don’t make much sense?
> 
> David.
> ___
> 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] [Concurrency] Async/Await

[David Hart via swift-evolution]

Sorry for the shameless bump :-/ but I’d love to get some answers so I can 
better understand the proposal and participate in the discussions.

> On 21 Aug 2017, at 07:58, David Hart via swift-evolution 
>  wrote:
> 
> Hello,
> 
> Thanks for the great work on the async/await proposal! After reading it, I 
> have a few questions and comments about it, so I’m creating this thread to 
> concentrate on that topic (instead of Actors).
> 
> Generators
> 
> The proposal mentions in Problem 6 of the Motivation how generators can help 
> write sequences:
> 
> In contrast, languages that have generators allow you to write something more 
> close to this:
> 
> func getSequence() -> AnySequence {
> let seq = sequence {
> for i in 1...10 {
> yield(i*i)
> }
> }
> return AnySequence(seq)
> }
> 
> This feels very similar to me from C# where the yield keyword is used to 
> support the generator feature. But I fail to see how the coroutines as 
> described in this proposal resolve this problem. Can someone explain?
> 
> beginAsync
> 
> The documentation of the beginAsync and suspendAsync functions state:
> 
> // NB: Names subject to bikeshedding. These are low-level primitives that most
> // users should not need to interact with directly, so namespacing them
> // and/or giving them verbose names unlikely to collide or pollute code
> // completion (and possibly not even exposing them outside the stdlib to begin
> // with) would be a good idea.
> 
> But I don’t understand how they can be kept private to the standard library 
> when they are used for the important pattern of spawning off an async 
> operation from a non-async function:
> 
> Despite these problems, it is essential that the model encompasses this 
> pattern, because it is a practical necessity in Cocoa development. With this 
> proposal, it would look like this:
> 
> @IBAction func buttonDidClick(sender:AnyObject) {
>   // 1
>   beginAsync {
> // 2
> let image = await processImage()
> imageView.image = image
>   }
>   // 3
> Futures
> 
> When discussing futures, the proposal states:
> 
> The exact design for a future type deserves its own proposal, but a proof of 
> concept could look like this:
> 
> Does that sentence imply that the Core Team would welcome a Future 
> implementation into the Standard Library?
> 
> async as a subtype of throws instead of orthogonal to it
> 
> I’ve been thinking a lot about this since the proposal came out and I see a 
> few serious disadvantages at making async a subtype of throws which might 
> benefit from being discussed or/and mentioned in the proposal.
> 
> 1. We loose the automatic documentation try provides for signaling failable 
> functions:
> 
> let image = await downloadImage()
> let processedImage = await processImage(image)
> await present(MyViewController(image: image))
> 
> In my example, downloadImage can fail because of network conditions, 
> processImage can not fail, and present is the UIKit function which presents 
> view controllers and it can’t fail either. But that’s not obvious from 
> reading the code. We’ve lost information.
> 
> 2. Supporting try? and try! adds a lot of confusion:
> 
> As was mentioned by Karim Nassar is another post, if await infers try, then 
> there seems to be no good solution for supporting try? and try!:
> 
> Using await? and await! seems slightly conter-intuitive because we are 
> further mixing the concepts of coroutines/asynchronous operations with error 
> handling.
> Adding try? and try! (like suggested Chris Lattner) feels like it makes point 
> (1) by having both explicit try?/! and implicit try through await.
> 
> 3. Philosophical discussion
> 
> If async calls don’t return futures because coroutines are a generally useful 
> language features beyond the domain of async/await, doesn’t making async 
> imply throws also muddy the concept of coroutines where failable coroutine 
> operations don’t make much sense?
> 
> David.
> ___
> 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] (core library) modern URL types

[Félix Cloutier via swift-evolution]

It could be problematic to initialize, however. You would need to know Scheme 
in URL ahead of initialization time for at least two reasons: first 
because value types aren't polymorphic, and second because the size of a type 
can depend on its generic parameters.

(If we have a good solution for both, then that would be great, yes.)

Félix

> Le 21 août 2017 à 09:28, Robert Bennett  a écrit :
> 
> If value-based generics become a thing, then you’ll be able to specify a URL 
> type with URL<.file> which would pretty much solve this problem.
> 
> On Aug 21, 2017, at 11:24 AM, Félix Cloutier via swift-evolution 
> > wrote:
> 
>> There's no question that there's a lot in common between file: URLs and 
>> other URLs, but that hardly makes URLs better in the file: case.
>> 
>> I saw the enum. The problem remains that it's a common API principle to 
>> accept the broadest possible input. It's not fundamentally wrong to accept 
>> and resolve common URL types, as there's a ton of things that need to read 
>> documents from the Internet by design. However, if this is the default 
>> facility for file handling too, it invents either:
>> 
>> A responsibility for API users to check that their URL is a file: URL;
>> A responsibility for API authors to provide separate entry points for file 
>> URLs and remote URLs, and a responsibility for API users to use the right 
>> one.
>> 
>> It would also add a category of errors to common filesystem operations: 
>> "can't do this because the URL is not a file: URL", and a category of 
>> questions that we arguably shouldn't need to ask ourselves. For instance, 
>> what is the correct result of glob()ing a file: URL pattern with a hash or a 
>> query string, should each element include that hash/query string too?
>> 
>> Félix
>> 
>>> Le 20 août 2017 à 23:33, Taylor Swift >> > a écrit :
>>> 
>>> I think that’s more a problem that lies in Foundation methods that take 
>>> URLs rather than the URLs themselves. A URL is a useful abstraction because 
>>> it contains a lot of common functionality between local file paths and 
>>> internet resources. For example, relative URI reference resolution. APIs 
>>> which take URLs as arguments should be responsible for ensuring that the 
>>> URL’s schema is a `file:`. The new URL type I’m writing actually makes the 
>>> scheme an enum with cases `.file`, `.http`, `.https`, `.ftp`, and `.data` 
>>> to ease checking this.
>>> 
>>> On Mon, Aug 21, 2017 at 2:23 AM, Félix Cloutier >> > wrote:
>>> I'm not convinced that URLs are the appropriate abstraction for a file 
>>> system path. For the record, I'm not a fan of existing Foundation methods 
>>> that create objects from an URL. There is a useful and fundamental 
>>> difference between a local path and a remote path, and conflating the two 
>>> has been a security pain point in many languages and frameworks that allow 
>>> it. Examples include remote file inclusion in PHP and malicious doctypes in 
>>> XML. Windows also had its share of issues with UNC paths.
>>> 
>>> Even when loading an arbitrary URL looks innocuous, many de-anonymizing 
>>> hacks work by causing a program to access an URL controlled by an attacker 
>>> to make it disclose the user's IP address or some other identifier.
>>> 
>>> IMO, this justifies that there should be separate types to handle local and 
>>> remote resources, so that at least developers have to be explicit about 
>>> allowing remote resources. This makes a new URL type less necessary towards 
>>> supporting file I/O.
>>> 
>>> Félix
>>> 
 Le 20 août 2017 à 21:37, Taylor Swift via swift-evolution 
 > a écrit :
 
 Okay so a few days ago there was a discussion 
 
  about getting pure swift file system support into Foundation or another 
 core library, and in my opinion, doing this requires a total overhaul of 
 the `URL` type (which is currently little more than a wrapper for NSURL), 
 so I’ve just started a pure Swift URL library project at 
 >.
 
 The library’s parsing and validation core (~1K loc pure swift) is already 
 in place and functional; the goal is to eventually support all of the 
 Foundation URL functionality.
 
 The new `URL` type is implemented as a value type with utf8 storage backed 
 by an array buffer. The URLs are just 56 bytes long each, so they should 
 be able to fit into cache lines. (NSURL by comparison is over 128 bytes in 
 size; it’s only saved by the fact that the thing is passed as a reference 
 type.)
 
 As I said, this is still really early on 

Re: [swift-evolution] SE-184 Improved Pointers

[Andrew Trick via swift-evolution]

> On Aug 20, 2017, at 6:03 PM, Taylor Swift  wrote:
> 
> New draft of the proposal is up here: 
>   
> >
> 
> Important changes start here 
> .

I have more feedback for you after discussing with Ben and Michael.

Under the section "Background". The retaining/releasing counts are confusing 
because we normally talk about "+0/+1" with respect to a single value. Here 
you're summing the reference count effect across different source and 
destination values. I think you can drop the -1/+0/+1 from the cell labels and 
just label the headers as "Source-Copy(+1) vs. Source-Move(+0)" and 
"Dest-Initializing(+0)" vs. "Dest-Destroying(-1)".

Ben noticed that we still don't have `UnsafeMutableBufferPointer.deallocate()`. 
Please add that as well.

I think you should also add the default `alignedTo:Int = 
MemoryLayout.alignment` to `UnsafeRawMutablePointer`. It is effectively 
part of Swift's memory model... [Background: We're providing a language level 
default guarantee of word-aligned storage. We don't want to expose the 
platform's default alignment. There is no such thing as a "maximal" alignment 
for all imported primitive types. We expect allocators to typically provide 
16-byte alignment, but when developers are relying on that for correctness, we 
want it to be explicit. Developers usually rely on word alignment so there's no 
value in making that explicit.]

The source breaking changes can be marked deprecated for now, but can only be 
marked unavailable in Swift 5 mode or later.

We anticipate adding a ContiguouslyStored protocol "soon", which could be used 
to reduce the amount of overloading on the buffer `initialize`/`assign` APIs. 
But we need a lot more time to iterate on that design and it doesn't appear 
that migrating to it would be source breaking w.r.t. your proposal.

I think we would be receptive to a "non-Optional baseAddress" proposal now if 
you or anyone else wants to pitch that. I know Dave Abrahams had a working 
implementation at some point. That would weaken some of the incentive to 
continue adding more convenience to buffer slices.

Sorry to bring this up again, but I was not able to defend the addition of 
`UnsafeMutableBufferPointer.deinitialize()`. It is incorrect for the typical 
use case and doesn't appear to solve any important use case. The *only* fully 
initializing method is `initialize(repeating:)`, but that will usually be used 
for trivial values, which should not be deinitialized. It's preferable for the 
user to explicitly deinitialize just the segments that they know were 
initialized, which can be done on the base pointer. The only benefit in having 
a `deinitialize` on the buffer is to communicate to users who see the 
`initialize` API for the first time that it is their responsibility to 
deinitialize if the type requires it. To that end, we could add a 
`deinitialize(at:count:)` method, communicating the symmetry with 
`initialize(at:from:). Naturally `index + count <= self.count`.

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

Re: [swift-evolution] SE-184 Improved Pointers

[Taylor Swift via swift-evolution]

ps the implementation in pr 11464
 has been updated with
documentation comments and changes in the latest version of the proposal

On Mon, Aug 21, 2017 at 9:19 PM, Taylor Swift  wrote:

>
>
> On Mon, Aug 21, 2017 at 6:11 PM, Michael Ilseman 
> wrote:
>
>>
>> On Aug 21, 2017, at 2:07 PM, Andrew Trick via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>
>> On Aug 20, 2017, at 6:03 PM, Taylor Swift  wrote:
>>
>> New draft of the proposal is up here: > wift-evolution/blob/patch-3/proposals/0184-improved-pointers.md>
>>
>> Important changes start here
>> 
>> .
>>
>>
>> This should be brought to the attention of swift-evolution:
>>
>> The old `deallocate(capacity:)` method should be marked
>> as `unavailable` since it currently encourages dangerously incorrect code.
>> This avoids misleading future users, forces current users to address this
>> potentially catastrophic memory bug, and leaves the possibility open for us
>> to add a `deallocate(capacity:)` method in the future, or perhaps even
>> a `reallocate(toCapacity:)` method.
>>
>>
>> I can’t defend breaking existing source without having seen real code
>> that was actually written incorrectly. I don’t see the downside of using
>> the same deprecation strategy as the other changes. I expect code that was
>> already written to be correct and future code to not call the deprecated
>> API.
>>
>>
>> It would have to be deprecated in Swift 4 mode. For beyond-4 mode, are
>> you arguing it should remain deprecated or can it become obsoleted?
>>
>
> I mean I just thought that it would be best to get rid of this as quickly
> and harshly as possible because a lot of people might think their code was
> correct when in fact it wasn’t (the example in the document is biased to
> segfault but if the lengths are smaller, a segfault might not occur, even
> though invalid access is still being done.)
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] SE-184 Improved Pointers

[Taylor Swift via swift-evolution]

On Mon, Aug 21, 2017 at 6:11 PM, Michael Ilseman  wrote:

>
> On Aug 21, 2017, at 2:07 PM, Andrew Trick via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On Aug 20, 2017, at 6:03 PM, Taylor Swift  wrote:
>
> New draft of the proposal is up here:  swift-evolution/blob/patch-3/proposals/0184-improved-pointers.md>
>
> Important changes start here
> 
> .
>
>
> This should be brought to the attention of swift-evolution:
>
> The old `deallocate(capacity:)` method should be marked
> as `unavailable` since it currently encourages dangerously incorrect code.
> This avoids misleading future users, forces current users to address this
> potentially catastrophic memory bug, and leaves the possibility open for us
> to add a `deallocate(capacity:)` method in the future, or perhaps even
> a `reallocate(toCapacity:)` method.
>
>
> I can’t defend breaking existing source without having seen real code that
> was actually written incorrectly. I don’t see the downside of using the
> same deprecation strategy as the other changes. I expect code that was
> already written to be correct and future code to not call the deprecated
> API.
>
>
> It would have to be deprecated in Swift 4 mode. For beyond-4 mode, are you
> arguing it should remain deprecated or can it become obsoleted?
>

I mean I just thought that it would be best to get rid of this as quickly
and harshly as possible because a lot of people might think their code was
correct when in fact it wasn’t (the example in the document is biased to
segfault but if the lengths are smaller, a segfault might not occur, even
though invalid access is still being done.)
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] SE-184 Improved Pointers

[Andrew Trick via swift-evolution]

> On Aug 21, 2017, at 3:11 PM, Michael Ilseman  wrote:
> 
>> 
>> I can’t defend breaking existing source without having seen real code that 
>> was actually written incorrectly. I don’t see the downside of using the same 
>> deprecation strategy as the other changes. I expect code that was already 
>> written to be correct and future code to not call the deprecated API.
>> 
> 
> It would have to be deprecated in Swift 4 mode. For beyond-4 mode, are you 
> arguing it should remain deprecated or can it become obsoleted?

We can defer that decision. We could conceivably obsolete 
`deallocate(capacity:)` in beyond-4, but keep the rest of the changes as 
deprecated until beyond-beyond-swift-4.

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

Re: [swift-evolution] SE-184 Improved Pointers

[Michael Ilseman via swift-evolution]

> On Aug 21, 2017, at 2:07 PM, Andrew Trick via swift-evolution 
>  wrote:
> 
> 
>> On Aug 20, 2017, at 6:03 PM, Taylor Swift > > wrote:
>> 
>> New draft of the proposal is up here: 
>> >  
>> >
>> 
>> Important changes start here 
>> .
> 
> This should be brought to the attention of swift-evolution:
> 
>> The old `deallocate(capacity:)` method should be marked as `unavailable` 
>> since it currently encourages dangerously incorrect code. This avoids 
>> misleading future users, forces current users to address this potentially 
>> catastrophic memory bug, and leaves the possibility open for us to add a 
>> `deallocate(capacity:)` method in the future, or perhaps even a 
>> `reallocate(toCapacity:)` method.
> 
> I can’t defend breaking existing source without having seen real code that 
> was actually written incorrectly. I don’t see the downside of using the same 
> deprecation strategy as the other changes. I expect code that was already 
> written to be correct and future code to not call the deprecated API.
> 

It would have to be deprecated in Swift 4 mode. For beyond-4 mode, are you 
arguing it should remain deprecated or can it become obsoleted?

> -Andy
> 
>> On Sun, Aug 20, 2017 at 1:40 PM, Kelvin Ma > > wrote:
>> actually never mind that, UnsafeMutablePointer should be the only type to 
>> not support at: arguments since offsetting them is easy with +.
>> 
>> On Aug 20, 2017, at 12:12 AM, Taylor Swift via swift-evolution 
>> > wrote:
>> 
>>> 
>>> 
>>> On Sat, Aug 19, 2017 at 10:28 PM, Andrew Trick >> > wrote:
>>> 
 On Aug 19, 2017, at 6:42 PM, Taylor Swift > wrote:
 
 
 
 On Sat, Aug 19, 2017 at 9:31 PM, Andrew Trick > wrote:
 
> On Aug 19, 2017, at 6:16 PM, Taylor Swift  > wrote:
> 
> What you’re describing is basically an earlier version of the proposal 
> which had a slightly weaker precondition (source >= destination) than 
> yours (source == destination). That one basically ignored the Sequence 
> methods at the expense of greater API surface area.
 
 The Sequence methods don’t provide the simpler, more convenient form of 
 initialization/deinitialization that I thought you wanted. I see two 
 reasonable options.
 
 1. Don’t provide any new buffer initialization/deinitialization 
 convenience. i.e. drop UsafeMutableBufferPointer moveInitialize, 
 moveAssign, and deinitialize from your proposal.
 
 2. Provide the full set of convenience methods: initialize, assign, 
 moveInitialize, and moveAssign assuming self.count==source.count. And 
 provide deinitialize() to be used only in conjunction with those new 
 initializers.
 
 The question is really whether those new methods are going to 
 significantly simplify your code. If not, #1 is the conservative choice. 
 Don't provide convenience which could be misused. Put off solving that 
 problem until we can design a new move-only buffer type that tracks 
 partially initialized state.
 
 -Andy 
 
 
 I’m not sure the answer is to just omit methods from 
 UnsafeMutableBufferPointer since most of the original complaints 
 circulated around having to un-nil baseAddress to do anything with them.
>>> 
>>> I know un-nil’ing baseAddress is horrible, but I don’t think working around 
>>> that is an important goal yet. Eventually there will be a much safer, more 
>>> convenient mechanism for manual allocation that doesn’t involve “pointers". 
>>> I also considered adding API surface to UnsafeMutableBufferPointer.Slice, 
>>> but that’s beyond what we should do now and may also become irrelevant when 
>>> we have a more sophisticated buffer type. 
>>> 
 What if only unary methods should be added to UnsafeMutableBufferPointer 
 without count:, meaning:
 
 initialize(repeating:)
>>> 
>>> I actually have no problem with this one... except that it could be 
>>> confused with UnsafeMutablePointer.initialize(repeating:), but I’ll ignore 
>>> that since we already discussed it.
>>> 
 assign(repeating:)
 deinitialize()
>>> 
>>> These are fine only if we have use cases that warrant them AND those use 
>>> cases are expected to fully initialize the buffer, either via 
>>> initialize(repeating:) or 

Re: [swift-evolution] SE-184 Improved Pointers

[Andrew Trick via swift-evolution]

> On Aug 20, 2017, at 6:03 PM, Taylor Swift  wrote:
> 
> New draft of the proposal is up here: 
>   
> >
> 
> Important changes start here 
> .

This should be brought to the attention of swift-evolution:

> The old `deallocate(capacity:)` method should be marked as `unavailable` 
> since it currently encourages dangerously incorrect code. This avoids 
> misleading future users, forces current users to address this potentially 
> catastrophic memory bug, and leaves the possibility open for us to add a 
> `deallocate(capacity:)` method in the future, or perhaps even a 
> `reallocate(toCapacity:)` method.

I can’t defend breaking existing source without having seen real code that was 
actually written incorrectly. I don’t see the downside of using the same 
deprecation strategy as the other changes. I expect code that was already 
written to be correct and future code to not call the deprecated API.

-Andy

> On Sun, Aug 20, 2017 at 1:40 PM, Kelvin Ma  > wrote:
> actually never mind that, UnsafeMutablePointer should be the only type to not 
> support at: arguments since offsetting them is easy with +.
> 
> On Aug 20, 2017, at 12:12 AM, Taylor Swift via swift-evolution 
> > wrote:
> 
>> 
>> 
>> On Sat, Aug 19, 2017 at 10:28 PM, Andrew Trick > > wrote:
>> 
>>> On Aug 19, 2017, at 6:42 PM, Taylor Swift >> > wrote:
>>> 
>>> 
>>> 
>>> On Sat, Aug 19, 2017 at 9:31 PM, Andrew Trick >> > wrote:
>>> 
 On Aug 19, 2017, at 6:16 PM, Taylor Swift > wrote:
 
 What you’re describing is basically an earlier version of the proposal 
 which had a slightly weaker precondition (source >= destination) than 
 yours (source == destination). That one basically ignored the Sequence 
 methods at the expense of greater API surface area.
>>> 
>>> The Sequence methods don’t provide the simpler, more convenient form of 
>>> initialization/deinitialization that I thought you wanted. I see two 
>>> reasonable options.
>>> 
>>> 1. Don’t provide any new buffer initialization/deinitialization 
>>> convenience. i.e. drop UsafeMutableBufferPointer moveInitialize, 
>>> moveAssign, and deinitialize from your proposal.
>>> 
>>> 2. Provide the full set of convenience methods: initialize, assign, 
>>> moveInitialize, and moveAssign assuming self.count==source.count. And 
>>> provide deinitialize() to be used only in conjunction with those new 
>>> initializers.
>>> 
>>> The question is really whether those new methods are going to significantly 
>>> simplify your code. If not, #1 is the conservative choice. Don't provide 
>>> convenience which could be misused. Put off solving that problem until we 
>>> can design a new move-only buffer type that tracks partially initialized 
>>> state.
>>> 
>>> -Andy 
>>> 
>>> 
>>> I’m not sure the answer is to just omit methods from 
>>> UnsafeMutableBufferPointer since most of the original complaints circulated 
>>> around having to un-nil baseAddress to do anything with them.
>> 
>> I know un-nil’ing baseAddress is horrible, but I don’t think working around 
>> that is an important goal yet. Eventually there will be a much safer, more 
>> convenient mechanism for manual allocation that doesn’t involve “pointers". 
>> I also considered adding API surface to UnsafeMutableBufferPointer.Slice, 
>> but that’s beyond what we should do now and may also become irrelevant when 
>> we have a more sophisticated buffer type. 
>> 
>>> What if only unary methods should be added to UnsafeMutableBufferPointer 
>>> without count:, meaning:
>>> 
>>> initialize(repeating:)
>> 
>> I actually have no problem with this one... except that it could be confused 
>> with UnsafeMutablePointer.initialize(repeating:), but I’ll ignore that since 
>> we already discussed it.
>> 
>>> assign(repeating:)
>>> deinitialize()
>> 
>> These are fine only if we have use cases that warrant them AND those use 
>> cases are expected to fully initialize the buffer, either via 
>> initialize(repeating:) or initialize(from: buffer) with 
>> precondition(source.count==self.count). They don’t really make sense for the 
>> use case that I’m familiar with. Without clear motivating code patterns, 
>> they aren’t worth the risk. “API Completeness” doesn’t have intrinsic value.
>> 
>> An example use for assign(repeating:) would be to zero out an image buffer.
>>  
>> 
>>> and the other methods should take both an 

Re: [swift-evolution] [Concurrency] async/await + actors

[Brent Royal-Gordon via swift-evolution]

> On Aug 21, 2017, at 12:41 PM, Wallacy via swift-evolution 
>  wrote:
> 
> Based on these same concerns, how to do this using async/await ?
> 
> func process() -> Void) {
> loadWebResource("bigData.txt") { dataResource in
> //
> }
> printf("BigData Scheduled to load")
> loadWebResource("smallData.txt") { dataResource in
> //
> }
> printf("SmallData Scheduled to load")
> 
> }


You would use something like the `Future` type mentioned in the proposal:

func process() {
let bigDataFuture = Future { await 
loadWebResource("bigData.txt") }
print("BigData scheduled to load")

let smallDataFuture = Future { await 
loadWebResource("smallData.txt") }
print("SmallData scheduled to load")

let bigDataResource = await bigDataFuture.get()
let smallDataResource = await smallDataFuture.get()
// or whatever; you could probably chain off the futures to 
handle whichever happens first first.
...
}

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [Concurrency] async/await + actors

[Karim Nassar via swift-evolution]

Thought about it in more depth, and I’m now firmly in the camp of: 
‘throws’/‘try' and ‘async’/‘await' should be orthogonal features. I think the 
slight call-site reduction in typed characters ('try await’ vs ‘await’) is 
heavily outweighed by the loss of clarity on all the edge cases.

—Karim

> On Aug 21, 2017, at 1:56 PM, John McCall  wrote:
> 
>> 
>> On Aug 20, 2017, at 3:56 PM, Yuta Koshizawa > > wrote:
>> 
>> 2017-08-21 2:20 GMT+09:00 John McCall via swift-evolution 
>> >:
>>> On Aug 19, 2017, at 7:17 PM, Chris Lattner via swift-evolution 
>>> > wrote:
 On Aug 19, 2017, at 8:14 AM, Karim Nassar via swift-evolution 
 > wrote:
 
 This looks fantastic. Can’t wait (heh) for async/await to land, and the 
 Actors pattern looks really compelling.
 
 One thought that occurred to me reading through the section of the 
 "async/await" proposal on whether async implies throws:
 
 If ‘async' implies ‘throws' and therefore ‘await' implies ‘try’, if we 
 want to suppress the catch block with ?/!, does that mean we do it on the 
 ‘await’ ? 
 
 guard let foo = await? getAFoo() else {  …  }
>>> 
>>> Interesting question, I’d lean towards “no, we don’t want await? and 
>>> await!”.  My sense is that the try? and try! forms are only occasionally 
>>> used, and await? implies heavily that the optional behavior has something 
>>> to do with the async, not with the try.  I think it would be ok to have to 
>>> write “try? await foo()” in the case that you’d want the thrown error to 
>>> turn into an optional.  That would be nice and explicit.
>> 
>> try? and try! are quite common from what I've seen.
>> 
>> As analogous to `throws` and `try`, I think we have an option that `await!` 
>> means blocking.
>> 
>> First, if we introduce something like `do/catch` for `async/await`, I think 
>> it should be for blocking. For example:
>> 
>> ```
>> do {
>>   return await foo()
>> } block
>> ```
>> 
>> It is consistent with `do/try/catch` because it should allow to return a 
>> value from inside `do` blocks for an analogy of `throws/try`.
>> 
>> ```
>> // `throws/try`
>> func foo() -> Int {
>>   do {
>> return try bar()
>>   } catch {
>> ...
>>   }
>> }
>> 
>> // `async/await`
>> func foo() -> Int {
>>   do {
>> return await bar()
>>   } block
>> }
>> ```
>> 
>> And `try!` is similar to `do/try/catch`.
>> 
>> ```
>> // `try!`
>> let x = try! foo()
>> // uses `x` here
>> 
>> // `do/try/catch`
>> do {
>>   let x = try foo()
>>   // uses `x` here
>> } catch {
>>   fatalError()
>> }
>> ```
>> 
>> If `try!` is a sugar of `do/try/catch`, it also seems natural that `await!` 
>> is a sugar of `do/await/block`. However, currently all `!` in Swift are 
>> related to a logic failure. So I think using `!` for blocking is not so 
>> natural in point of view of symbology.
>> 
>> Anyway, I think it is valuable to think about what `do` blocks for 
>> `async/await` mean. It is also interesting that thinking about combinations 
>> of `catch` and `block` for `async throws` functions: e.g. If only `block`, 
>> the enclosing function should be `throws`.
> 
> Personally, I think these sources of confusion are a good reason to keep the 
> feature separate.
> 
> The idea of using await! to block a thread is interesting but, as you say, 
> does not fit with the general meaning of ! for logic errors.  I think it's 
> fine to just have an API to block waiting for an async operation, and we can 
> choose the name carefully to call out the danger of deadlocks.
> 
> John.
> 
>> 
>> That aside, I think `try!` is not so occasional and is so important. Static 
>> typing has limitations. For example, even if we has a text field which 
>> allows to input only numbers, we still get an input value as a string and 
>> parsing it may fail on its type though it actually never fails. If we did 
>> not have easy ways to convert such a simple domain error or a recoverable 
>> error to a logic failure, people would start ignoring them as we has seen in 
>> Java by `catch(Exception e) {}`. Now we have `JSONDecoder` and we will see 
>> much more `try!` for bundled JSON files in apps or generated JSONs by code, 
>> for which decoding fails as a logic failure.
>> 
>> --
>> Yuta

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

Re: [swift-evolution] [Concurrency] async/await + actors

[Wallacy via swift-evolution]

Based on these same concerns, how to do this using async/await ?

func process() -> Void) {

loadWebResource("bigData.txt") { dataResource in
  //
}

printf("BigData Scheduled to load")
loadWebResource("smallData.txt") { dataResource in
  //
}
printf("SmallData Scheduled to load")

}


Small data usually will finish first using GCD, but using async/await apear
to be no way to schedule other things (on other Queue maybe) in the same
function. I now this is about parallelism, but this is something that we
will lose about GCD.

I know the parallelism is not the focus, but is something important for the
people migration from GCD.

Maybe:

yield loadWebResource("bigData.txt") // has a void return.

yield loadWebResource("smallData.txt") // has a void return.


I don't know if yield is the right keyword here but i think is important
some way to "not" wait.

Em seg, 21 de ago de 2017 às 15:04, Adam Kemp via swift-evolution <
swift-evolution@swift.org> escreveu:

> On Aug 18, 2017, at 8:38 PM, Chris Lattner  wrote:
>
> On Aug 18, 2017, at 2:09 PM, Adam Kemp  wrote:
>
> Maybe I’m still missing something, but how does this help when you are
> interacting only with Swift code? If I were to write an asynchronous method
> in Swift then how could I do the same thing that you propose that the
> Objective-C importer do? That is, how do I write my function such that it
> calls back on the same queue?
>
>
> You’re right: if you’re calling something written in Swift, the ObjC
> importer isn’t going to help you.
>
> However, if you’re writing an async function in Swift, then it is
> reasonable for us to say what the convention is and expect you to follow
> it.  Async/await doesn’t itself help you implement an async operation: it
> would be turtles all the way down… until you get to GCD, which is where you
> do the async thing.
>
> As such, as part of rolling out async/await in Swift, I’d expect that GCD
> would introduce new API or design patterns to support doing the right thing
> here.  That is TBD as far as the proposal goes, because it doesn’t go into
> runtime issues.
>
>
> The point I’m trying to make is that this is so important that I don’t
> think it’s wise to leave it up to possible future library improvements, and
> especially not to convention. Consider this example again from your
> proposal:
>
> @IBAction func buttonDidClick(sender:AnyObject) {
> doSomethingOnMainThread();
> beginAsync {
> let image = await processImage()
> imageView.image = image
> }
> doSomethingElseOnMainThread();
> }
>
> The line that assigns the image to the image view is very likely running
> on the wrong thread. That code looks simple, but it is not safe. You would
> have to insert a line like your other examples to ensure it’s on the right
> thread:
>
> @IBAction func buttonDidClick(sender:AnyObject) {
> doSomethingOnMainThread();
> beginAsync {
>
> let image = await processImage()
>
> await DispatchQueue.main.asyncCoroutine()
> imageView.image = image
> }
> doSomethingElseOnMainThread();
> }
>
>
> You would have to litter your code with that kind of stuff just in case
> you’re on the wrong thread because there’s no way to tell where you’ll end
> up after the await. In fact, this feature would make it much easier to end
> up calling back on different queues in different circumstances because it
> makes queue hopping invisible. From another example:
>
> func processImageData1() async -> Image {
>
>   let dataResource  = await loadWebResource("dataprofile.txt")
>
>   let imageResource = await loadWebResource("imagedata.dat")
>   let imageTmp  = await decodeImage(dataResource, imageResource)
>   let imageResult   =  await dewarpAndCleanupImage(imageTmp)
>   return imageResult
> }
>
>
> Which queue does a caller end up in? Whichever queue that last awaited
> call gives you. This function does nothing to try to ensure that you always
> end up on the same queue. If someone changes the code by adding or removing
> one of those await calls then the final callback queue would change. If
> there were conditionals in there that changed the code flow at runtime then
> you could end up calling back on different queues depending on some runtime
> state.
>
> IMO this would make doing safe async programming actually more difficult
> to get right. It would be tedious and error prone. This simplified
> async/await model may work well for JavaScript, which generally doesn’t
> have shared mutable state across threads, but it seems dangerous in a
> language that does.
>
> This isn’t a fair transformation though, and isn’t related to whether
> futures is part of the library or language.  The simplification you got
> here is by making IBAction’s implicitly async.  I don’t see that that is
> possible, since they have a very specific calling convention (which returns
> void) and are invoked by 

Re: [swift-evolution] pitch: Unified libc import (again)

[Philippe Hausler via swift-evolution]

> On Aug 18, 2017, at 5:42 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> On Fri, Aug 18, 2017 at 7:39 PM, Taylor Swift  > wrote:
> 
> 
> On Fri, Aug 18, 2017 at 8:09 PM, Xiaodi Wu  > wrote:
> On Fri, Aug 18, 2017 at 6:55 PM, Greg Parker  > wrote:
> 
>> On Aug 17, 2017, at 5:16 PM, Xiaodi Wu via swift-evolution 
>> > wrote:
>> 
>> On Thu, Aug 17, 2017 at 6:46 PM, Taylor Swift > > wrote:
>> I don’t think the “is this library functionality or standard library 
>> functionality” argument is worth having, but if stdout and stdin are 
>> first-class citizens in the Swift world, so should stderr.
>> 
>> As for bringing Foundation into the discussion, you can’t really talk about 
>> Foundation without also talking about the mountains of problems that come 
>> with the monolith pattern. But that’s a completely different conversation to 
>> be had.
>> 
>> I'm not sure what you're getting at here, but I don't believe you've 
>> addressed my question, which is: it's been firmly decided that I/O belongs 
>> in Foundation, and Foundation does in fact offer such facilities--what is 
>> missing from those facilities, and how can we fill it out?
> 
> Lots of I/O functionality is missing from Foundation. Foundation's design 
> from time immemorial is that generally only relatively simple and high-level 
> operations are available in Foundation itself, and if you want to do 
> complicated or non-portable things then you are expected to drop down to 
> POSIX or other C interfaces. That design works less well in Swift than it did 
> in Objective-C because Swift's interface with C, especially low-level C, is 
> often ugly.
> 
> Simple example: there is no way to access file information directly via 
> NSFileHandle. You need to call NSFileHandle.fileDescriptor and pass that to  
> fstat() or fcntl(). The NSFileHandle API in general is sparse and wholly 
> inadequate for sophisticated I/O.
> 
> So that's a good starting point for the discussion.
> 
> What, in your opinion, should be the way forward in addressing this 
> situation? Is there a realistic chance of writing a single comprehensive, 
> cross-platform API that makes possible currently "complicated or non-portable 
> things" on both macOS/iOS/tvOS/watchOS and Linux, and potentially Windows? If 
> so, does that fit within the general category of filling out the currently 
> sparse Foundation APIs or would that be a matter for a separate library? In 
> the alternative, is it the right solution to make dropping down to POSIX 
> marginally easier by re-exporting C APIs under a unified name, without 
> attempting a single cross-platform API?
> 
> 
> 
> For what it’s worth, CoreFoundation appears to support windows environments, 
> at least for things like path manipulation. However atm it’s not very 
> relevant as Swift doesn’t run on Windows rn.
> 
> If I recall, the CoreFoundation code for Windows is from a long-abandoned 
> port that no longer works, to the point that it is thought unsuitable as a 
> basis for a modern port.


I don’t think abandoned is the right term per-se. But the branch of 
CoreFoundation that is used for the CF inside of swift-corelibs-foundation has 
moved in a different direction than the one being used for the Windows support 
(might be better to think of it as a fork that diverged). I would definitely 
agree that anything of an update for windows support should definitely reach 
out and work together to see what we can and should update. But as it stands - 
I don’t think that is fully operational at the current point in time (modulo 
perhaps Cygwin; which recently had some contributors working on that front).

If a contributor wants to revitalize the windows portion I would be very 
willing to aide in that endeavor.

> ___
> 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] [Concurrency] async/await + actors

[Adam Kemp via swift-evolution]

> On Aug 18, 2017, at 8:38 PM, Chris Lattner  > wrote:
> 
> On Aug 18, 2017, at 2:09 PM, Adam Kemp  > wrote:
>> Maybe I’m still missing something, but how does this help when you are 
>> interacting only with Swift code? If I were to write an asynchronous method 
>> in Swift then how could I do the same thing that you propose that the 
>> Objective-C importer do? That is, how do I write my function such that it 
>> calls back on the same queue?
> 
> You’re right: if you’re calling something written in Swift, the ObjC importer 
> isn’t going to help you.
> 
> However, if you’re writing an async function in Swift, then it is reasonable 
> for us to say what the convention is and expect you to follow it.  
> Async/await doesn’t itself help you implement an async operation: it would be 
> turtles all the way down… until you get to GCD, which is where you do the 
> async thing.
> 
> As such, as part of rolling out async/await in Swift, I’d expect that GCD 
> would introduce new API or design patterns to support doing the right thing 
> here.  That is TBD as far as the proposal goes, because it doesn’t go into 
> runtime issues.

The point I’m trying to make is that this is so important that I don’t think 
it’s wise to leave it up to possible future library improvements, and 
especially not to convention. Consider this example again from your proposal:

@IBAction func buttonDidClick(sender:AnyObject) {  
doSomethingOnMainThread();
beginAsync {
let image = await processImage()
imageView.image = image
}
doSomethingElseOnMainThread();
}

The line that assigns the image to the image view is very likely running on the 
wrong thread. That code looks simple, but it is not safe. You would have to 
insert a line like your other examples to ensure it’s on the right thread:

@IBAction func buttonDidClick(sender:AnyObject) {  
doSomethingOnMainThread();
beginAsync {
let image = await processImage()
await DispatchQueue.main.asyncCoroutine()
imageView.image = image
}
doSomethingElseOnMainThread();
}

You would have to litter your code with that kind of stuff just in case you’re 
on the wrong thread because there’s no way to tell where you’ll end up after 
the await. In fact, this feature would make it much easier to end up calling 
back on different queues in different circumstances because it makes queue 
hopping invisible. From another example:

func processImageData1() async -> Image {
  let dataResource  = await loadWebResource("dataprofile.txt")
  let imageResource = await loadWebResource("imagedata.dat")
  let imageTmp  = await decodeImage(dataResource, imageResource)
  let imageResult   =  await dewarpAndCleanupImage(imageTmp)
  return imageResult
}

Which queue does a caller end up in? Whichever queue that last awaited call 
gives you. This function does nothing to try to ensure that you always end up 
on the same queue. If someone changes the code by adding or removing one of 
those await calls then the final callback queue would change. If there were 
conditionals in there that changed the code flow at runtime then you could end 
up calling back on different queues depending on some runtime state.

IMO this would make doing safe async programming actually more difficult to get 
right. It would be tedious and error prone. This simplified async/await model 
may work well for JavaScript, which generally doesn’t have shared mutable state 
across threads, but it seems dangerous in a language that does.

> This isn’t a fair transformation though, and isn’t related to whether futures 
> is part of the library or language.  The simplification you got here is by 
> making IBAction’s implicitly async.  I don’t see that that is possible, since 
> they have a very specific calling convention (which returns void) and are 
> invoked by objc_msgSend.  OTOH, if it were possible to do this, it would be 
> possible to do it with the proposal as outlined.

I didn’t mean to imply that all IBActions implicitly async. I just allowed for 
an entire method to be async without being awaitable. In C# an async void 
function is a “fire and forget” function. It executes in the context of the 
caller’s thread/stack up until the first await, at which point it returns to 
the caller like normal. The continuation just happens without the caller 
knowing about it. The method signature is the same, and they are callable by 
code that is unaware of async/await. C# supports async void functions 
specifically for the event handler use case (and it is generally discouraged 
for all other use cases).

Your proposal already has async void methods, but they are awaitable. You still 
need some ability to call an async method from a non-async method. The way that 
you solved that is a special function (beginAsync), which as I described 
earlier has some issues with readability. 

Re: [swift-evolution] [Concurrency] async/await + actors

[John McCall via swift-evolution]

> On Aug 20, 2017, at 3:56 PM, Yuta Koshizawa  wrote:
> 
> 2017-08-21 2:20 GMT+09:00 John McCall via swift-evolution 
> >:
>> On Aug 19, 2017, at 7:17 PM, Chris Lattner via swift-evolution 
>> > wrote:
>>> On Aug 19, 2017, at 8:14 AM, Karim Nassar via swift-evolution 
>>> > wrote:
>>> 
>>> This looks fantastic. Can’t wait (heh) for async/await to land, and the 
>>> Actors pattern looks really compelling.
>>> 
>>> One thought that occurred to me reading through the section of the 
>>> "async/await" proposal on whether async implies throws:
>>> 
>>> If ‘async' implies ‘throws' and therefore ‘await' implies ‘try’, if we want 
>>> to suppress the catch block with ?/!, does that mean we do it on the 
>>> ‘await’ ? 
>>> 
>>> guard let foo = await? getAFoo() else {  …  }
>> 
>> Interesting question, I’d lean towards “no, we don’t want await? and 
>> await!”.  My sense is that the try? and try! forms are only occasionally 
>> used, and await? implies heavily that the optional behavior has something to 
>> do with the async, not with the try.  I think it would be ok to have to 
>> write “try? await foo()” in the case that you’d want the thrown error to 
>> turn into an optional.  That would be nice and explicit.
> 
> try? and try! are quite common from what I've seen.
> 
> As analogous to `throws` and `try`, I think we have an option that `await!` 
> means blocking.
> 
> First, if we introduce something like `do/catch` for `async/await`, I think 
> it should be for blocking. For example:
> 
> ```
> do {
>   return await foo()
> } block
> ```
> 
> It is consistent with `do/try/catch` because it should allow to return a 
> value from inside `do` blocks for an analogy of `throws/try`.
> 
> ```
> // `throws/try`
> func foo() -> Int {
>   do {
> return try bar()
>   } catch {
> ...
>   }
> }
> 
> // `async/await`
> func foo() -> Int {
>   do {
> return await bar()
>   } block
> }
> ```
> 
> And `try!` is similar to `do/try/catch`.
> 
> ```
> // `try!`
> let x = try! foo()
> // uses `x` here
> 
> // `do/try/catch`
> do {
>   let x = try foo()
>   // uses `x` here
> } catch {
>   fatalError()
> }
> ```
> 
> If `try!` is a sugar of `do/try/catch`, it also seems natural that `await!` 
> is a sugar of `do/await/block`. However, currently all `!` in Swift are 
> related to a logic failure. So I think using `!` for blocking is not so 
> natural in point of view of symbology.
> 
> Anyway, I think it is valuable to think about what `do` blocks for 
> `async/await` mean. It is also interesting that thinking about combinations 
> of `catch` and `block` for `async throws` functions: e.g. If only `block`, 
> the enclosing function should be `throws`.

Personally, I think these sources of confusion are a good reason to keep the 
feature separate.

The idea of using await! to block a thread is interesting but, as you say, does 
not fit with the general meaning of ! for logic errors.  I think it's fine to 
just have an API to block waiting for an async operation, and we can choose the 
name carefully to call out the danger of deadlocks.

John.

> 
> That aside, I think `try!` is not so occasional and is so important. Static 
> typing has limitations. For example, even if we has a text field which allows 
> to input only numbers, we still get an input value as a string and parsing it 
> may fail on its type though it actually never fails. If we did not have easy 
> ways to convert such a simple domain error or a recoverable error to a logic 
> failure, people would start ignoring them as we has seen in Java by 
> `catch(Exception e) {}`. Now we have `JSONDecoder` and we will see much more 
> `try!` for bundled JSON files in apps or generated JSONs by code, for which 
> decoding fails as a logic failure.
> 
> --
> Yuta

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

Re: [swift-evolution] (core library) modern URL types

[Taylor Swift via swift-evolution]

that might be true but I’d need to hear from more people to justify
creating two very similar URI types. Technically `file:` is just a string
that the file system interpreter gives meaning to; the scheme of a URL can
be any alphanumeric string. For example you could write a file manager
which interprets "foo:" as a local address, or ignore the scheme entirely.

On Mon, Aug 21, 2017 at 11:23 AM, Félix Cloutier 
wrote:

> There's no question that there's a lot in common between file: URLs and
> other URLs, but that hardly makes URLs better in the file: case.
>
> I saw the enum. The problem remains that it's a common API principle to
> accept the broadest possible input. It's not fundamentally wrong to accept
> and resolve common URL types, as there's a ton of things that need to read
> documents from the Internet by design. However, if this is the default
> facility for file handling too, it invents either:
>
>
>- A responsibility for API users to check that their URL is a file:
>URL;
>- A responsibility for API authors to provide separate entry points
>for file URLs and remote URLs, and a responsibility for API users to use
>the right one.
>
>
> It would also add a category of errors to common filesystem operations:
> "can't do this because the URL is not a file: URL", and a category of
> questions that we arguably shouldn't need to ask ourselves. For instance,
> what is the correct result of glob()ing a file: URL pattern with a hash or
> a query string, should each element include that hash/query string too?
>
> Félix
>
> Le 20 août 2017 à 23:33, Taylor Swift  a écrit :
>
> I think that’s more a problem that lies in Foundation methods that take
> URLs rather than the URLs themselves. A URL is a useful abstraction because
> it contains a lot of common functionality between local file paths and
> internet resources. For example, relative URI reference resolution. APIs
> which take URLs as arguments should be responsible for ensuring that the
> URL’s schema is a `file:`. The new URL type I’m writing actually makes
> the scheme an enum with cases `.file`, `.http`, `.https`, `.ftp`, and `
> .data` to ease checking this.
>
> On Mon, Aug 21, 2017 at 2:23 AM, Félix Cloutier 
> wrote:
>
>> I'm not convinced that URLs are the appropriate abstraction for a file
>> system path. For the record, I'm not a fan of existing Foundation methods
>> that create objects from an URL. There is a useful and fundamental
>> difference between a local path and a remote path, and conflating the two
>> has been a security pain point in many languages and frameworks that allow
>> it. Examples include remote file inclusion in PHP and malicious doctypes in
>> XML. Windows also had its share of issues with UNC paths.
>>
>> Even when loading an arbitrary URL looks innocuous, many de-anonymizing
>> hacks work by causing a program to access an URL controlled by an attacker
>> to make it disclose the user's IP address or some other identifier.
>>
>> IMO, this justifies that there should be separate types to handle local
>> and remote resources, so that at least developers have to be explicit about
>> allowing remote resources. This makes a new URL type less necessary towards
>> supporting file I/O.
>>
>> Félix
>>
>> Le 20 août 2017 à 21:37, Taylor Swift via swift-evolution <
>> swift-evolution@swift.org> a écrit :
>>
>> Okay so a few days ago there was a discussion
>> 
>> about getting pure swift file system support into Foundation or another
>> core library, and in my opinion, doing this requires a total overhaul of
>> the `URL` type (which is currently little more than a wrapper for
>> NSURL), so I’ve just started a pure Swift URL library project at <
>> https://github.com/kelvin13/url>.
>>
>> The library’s parsing and validation core (~1K loc pure swift) is already
>> in place and functional; the goal is to eventually support all of the
>> Foundation URL functionality.
>>
>> The new `URL` type is implemented as a value type with utf8 storage
>> backed by an array buffer. The URLs are just 56 bytes long each, so they
>> should be able to fit into cache lines. (NSURL by comparison is over 128
>> bytes in size; it’s only saved by the fact that the thing is passed as a
>> reference type.)
>>
>> As I said, this is still really early on and not a mature library at all
>> but everyone is invited to observe, provide feedback, or contribute!
>> ___
>> 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] [Concurrency] async/await + actors

[Philippe Hausler via swift-evolution]

I have read over the proposal and already asked a few questions ahead of the 
email chain and I have some follow up points that are perhaps worth 
consideration.

First off, I think that async/await is a great concept! From personally using a 
similar concept in C#, I think it can be an approachable yet powerful tool to 
resolve a decent number of problems with threading. It is worth stating, 
however, that it does NOT solve all problems with threading, or at least, not 
on its own.

One thing I have in mind is that Swift, of course, does exist in a vacuum. It, 
by nature, is being used for writing iOS, watchOS and macOS applications to be 
shipped on those platforms. On those platforms, libdispatch is often used for 
things like completion handlers and similar (or indirectly used via 
NSOperationQueue). Of course there are a few of those devices that only have 
one core or are thermally constrained under load. It is then imperative that 
applications (at least under the hood) utilize appropriate quality of service 
to ensure that certain workloads do not get scheduled as much as others. For 
example: if an application is synchronizing some sort of state over the 
network, it may be the best choice to run that work at a low 
quality-of-service. In this example, if a specific piece of work is then 
blocked by the work that is running at a low quality-of-service, it needs to 
temporarily override that low quality-of-service to match the blocked work. I 
think that any concurrency model we consider should be able to work 
constructively with a situation like this, and take QoS into account.

For sake of argument, though: let's presume that completion handlers are always 
going to be appropriately scheduled for their quality-of-service. So why is the 
override important to think about? Well... in the cases of single core, or 
other cases where a ton of work in limiting the number of cores available, 
there can be a problem known as a priority inversion. If no override is made, 
the low priority work can be starved by the scheduling of a waiter. This 
results in a deadlock. Now you might of course think: "oh hey, that's 
DispatchSemaphore's responsibility, or pthread_condition_t" etc... 
Unfortunately semaphores or conditions do not have the appropriate information 
to convey this. To offer a solution to this problem, the start of the 
asynchronous work needs to be recorded for the threads involved to the end of 
that asynchronous work, then at the beginning of the waiting section an 
override needs to be created against those asynchronous threads and the 
override is ended at the point that it is done waiting.

In short, effectively just waiting on completion handler will cause severe 
performance problems - to resolve this it seems like we absolutely need to have 
more entry points to do the correct promotions of QoS. 

What do you think is the best way of approaching a resolution for this 
potential pitfall?

> On Aug 17, 2017, at 3:24 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> Hi all,
> 
> As Ted mentioned in his email, it is great to finally kick off discussions 
> for what concurrency should look like in Swift.  This will surely be an epic 
> multi-year journey, but it is more important to find the right design than to 
> get there fast.
> 
> I’ve been advocating for a specific model involving async/await and actors 
> for many years now.  Handwaving only goes so far, so some folks asked me to 
> write them down to make the discussion more helpful and concrete.  While I 
> hope these ideas help push the discussion on concurrency forward, this isn’t 
> in any way meant to cut off other directions: in fact I hope it helps give 
> proponents of other designs a model to follow: a discussion giving extensive 
> rationale, combined with the long term story arc to show that the features 
> fit together.
> 
> Anyway, here is the document, I hope it is useful, and I’d love to hear 
> comments and suggestions for improvement:
> https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9f782
> 
> -Chris
> 
> ___
> 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] (core library) modern URL types

[Charles Srstka via swift-evolution]

> On Aug 21, 2017, at 11:29 AM, Robert Bennett via swift-evolution 
>  wrote:
> 
> If value-based generics become a thing, then you’ll be able to specify a URL 
> type with URL<.file> which would pretty much solve this problem.


And then you could make APIs that are specific to certain schemes, and maybe 
even have file references working again.

extension URL where Scheme == .file {
var path: String { … } // non-optional
}

extension URL where Scheme == .fileReference {
var path: String? { … } // optional
}

Charles

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

Re: [swift-evolution] (core library) modern URL types

[Robert Bennett via swift-evolution]

If value-based generics become a thing, then you’ll be able to specify a URL 
type with URL<.file> which would pretty much solve this problem.

> On Aug 21, 2017, at 11:24 AM, Félix Cloutier via swift-evolution 
>  wrote:
> 
> There's no question that there's a lot in common between file: URLs and other 
> URLs, but that hardly makes URLs better in the file: case.
> 
> I saw the enum. The problem remains that it's a common API principle to 
> accept the broadest possible input. It's not fundamentally wrong to accept 
> and resolve common URL types, as there's a ton of things that need to read 
> documents from the Internet by design. However, if this is the default 
> facility for file handling too, it invents either:
> 
> A responsibility for API users to check that their URL is a file: URL;
> A responsibility for API authors to provide separate entry points for file 
> URLs and remote URLs, and a responsibility for API users to use the right one.
> 
> It would also add a category of errors to common filesystem operations: 
> "can't do this because the URL is not a file: URL", and a category of 
> questions that we arguably shouldn't need to ask ourselves. For instance, 
> what is the correct result of glob()ing a file: URL pattern with a hash or a 
> query string, should each element include that hash/query string too?
> 
> Félix
> 
>> Le 20 août 2017 à 23:33, Taylor Swift  a écrit :
>> 
>> I think that’s more a problem that lies in Foundation methods that take URLs 
>> rather than the URLs themselves. A URL is a useful abstraction because it 
>> contains a lot of common functionality between local file paths and internet 
>> resources. For example, relative URI reference resolution. APIs which take 
>> URLs as arguments should be responsible for ensuring that the URL’s schema 
>> is a `file:`. The new URL type I’m writing actually makes the scheme an enum 
>> with cases `.file`, `.http`, `.https`, `.ftp`, and `.data` to ease checking 
>> this.
>> 
>>> On Mon, Aug 21, 2017 at 2:23 AM, Félix Cloutier  
>>> wrote:
>>> I'm not convinced that URLs are the appropriate abstraction for a file 
>>> system path. For the record, I'm not a fan of existing Foundation methods 
>>> that create objects from an URL. There is a useful and fundamental 
>>> difference between a local path and a remote path, and conflating the two 
>>> has been a security pain point in many languages and frameworks that allow 
>>> it. Examples include remote file inclusion in PHP and malicious doctypes in 
>>> XML. Windows also had its share of issues with UNC paths.
>>> 
>>> Even when loading an arbitrary URL looks innocuous, many de-anonymizing 
>>> hacks work by causing a program to access an URL controlled by an attacker 
>>> to make it disclose the user's IP address or some other identifier.
>>> 
>>> IMO, this justifies that there should be separate types to handle local and 
>>> remote resources, so that at least developers have to be explicit about 
>>> allowing remote resources. This makes a new URL type less necessary towards 
>>> supporting file I/O.
>>> 
>>> Félix
>>> 
 Le 20 août 2017 à 21:37, Taylor Swift via swift-evolution 
  a écrit :
 
 Okay so a few days ago there was a discussion about getting pure swift 
 file system support into Foundation or another core library, and in my 
 opinion, doing this requires a total overhaul of the `URL` type (which is 
 currently little more than a wrapper for NSURL), so I’ve just started a 
 pure Swift URL library project at .
 
 The library’s parsing and validation core (~1K loc pure swift) is already 
 in place and functional; the goal is to eventually support all of the 
 Foundation URL functionality.
 
 The new `URL` type is implemented as a value type with utf8 storage backed 
 by an array buffer. The URLs are just 56 bytes long each, so they should 
 be able to fit into cache lines. (NSURL by comparison is over 128 bytes in 
 size; it’s only saved by the fact that the thing is passed as a reference 
 type.)
 
 As I said, this is still really early on and not a mature library at all 
 but everyone is invited to observe, provide feedback, or contribute!
 ___
 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] Constrained Protocol Aliases

[Douglas Gregor via swift-evolution]

> On Aug 21, 2017, at 5:51 AM, David Hart  wrote:
> 
> 
>> On 21 Aug 2017, at 13:36, Adrian Zubarev > > wrote:
>> 
>> It’s part of Generalized Existentials, but does not make it complete. I 
>> think it would be worth adding more and more functionality to existentials 
>> every year. We started first with reshaping the syntax. This year we added 
>> support for classes. I think next year would be good to have where clause 
>> support for typealiases. 
>> 
>> I understand the complexity of that particular feature, and it’s a no-go for 
>> me to help on the implementation, but I’m willing to drive the discussion 
>> and the proposal forward with other co-authors. :)
>> 
>> Hasn’t it been said that the implementation must be at least a 
>> *proof-of-concept* if the complexity is very high?
>> 
> I’d love to have this feature. But I’m not sure even a partway proposal will 
> get to review with the laser-focus on ABI Stability + Concurrency. I don’t 
> want to spend time co-authoring a proposal if it is going to be out of scope 
> anyway. Perhaps Doug (CC) can give us some ideas.

The main issue is the implementation: it’s a nontrivial feature with impact on 
the AST, type checker, SIL, IR generation, type metadata, and runtime. On the 
other hand, it’s one of these features that’s 95% testable refactoring: one can 
plumb the notion of “generalized existential” through the whole compiler as a 
generalization of the existing existential types. The core abstraction needed 
to capture the requirements on the existential (GenericSignature) is already 
there in the compiler for generics, and much of the task is to generalize (as 
appropriate) and use that machinery for existentials.

It’s not an easy feature, but there are many capable people who could do it, 
and of course we’ll be happy to give guidance/review over on swift-dev if 
someone would like to work on it. The refactoring I mentioned could be 
developed on master (incrementally) as a general improvement to the compiler, 
so the implementation of the feature itself is a small, more 
syntactically-focused separate piece.
>> And my second question is: Wouldn’t the existence of this feature reshape 
>> some parts of the standard library, isn’t that affecting some major goals of 
>> Swift 5?
>> 
> Yes. But that also true of many other language feature. But the Standard 
> Library still needs to be set in stone at some point or another.

Generalized existentials would affect some parts of the standard library (e.g., 
they’d be a better way to implement AnyCollection et al), but generalized 
existentials are not a game-changer for the design.
>> It would be nice if someone from the core team can clarify if the where 
>> clause is out of scope for Swift 5 or not.
>> 
> Agreed.

It’s not “out of scope”, but everything hinges on the implementation task.

- Doug

> 
>> 
>> Am 21. August 2017 um 12:51:48, David Hart (da...@hartbit.com 
>> ) schrieb:
>> 
>>> 
 On 21 Aug 2017, at 11:41, Adrian Zubarev > wrote:
 
 Yes, `where` clause is welcome to typealises (including generic ones) and 
 existentials in general. I would love to help on such proposal. I think 
 David Hart is also interested in this one. (cc)
>>> 
>>> Yes, this basically seems like Generalized Existentials to me and is 
>>> mentioned in the Generics Manifesto 
>>> . 
>>> It’s a feature I hold very dear but:
>>> 
>>> It’s a very difficult feature to implement and I think Doug Gregor is the 
>>> only/best person to do it
>>> I think its pretty much out of scope for Swift 5 (it’s not required for ABI 
>>> Stability)
>>> 
>>> As a result, I’d be very surprised if this topic got any discussion or 
>>> implementation time during the Swift 5 timeframe.
 Am 21. August 2017 um 11:38:14, Gor Gyolchanyan via swift-evolution 
 (swift-evolution@swift.org ) schrieb:
 
> Hello, Swift community!
> 
> I'd like to start a discussion about a possibility of constrained 
> protocol aliases. The declaration would look like this:
> 
> typealias BinaryProtocol = RandomAccessCollection & MutablCollection & 
> RangeReplaceableCollection where Binary.Index == Int, Binary.Element == 
> Bool
> 
> The syntax and semantics of this declaration are exactly the same as an 
> analogous associatedtype declaration inside a protocol.
> In the example above, the type BinaryProtocol represents a logical array 
> of bits and is a generic-only protocol that is usable in any context 
> where an integer-indexed mutable range-replaceable random-access 
> collection is expected.
> Now, it can be used in a very concise and elegant way:
> 
> 

Re: [swift-evolution] Constrained Protocol Aliases

[Matthew Johnson via swift-evolution]

> On Aug 21, 2017, at 10:31 AM, Adrian Zubarev 
>  wrote:
> 
> 
> Hi Matthew thank you for remembering us about that draft. I’ll re-read it 
> soon. At the a quick glance I noticed the extent use of the `where` clause. 
> Wouldn’t make sense to simplify the main proposal and just focus on the 
> `where` clause for typealises only? It’s already a complex feature on its 
> own. Permitting the `where` clause in different places can sill be added 
> later in the future.

At first glance, it looks to me like the typealias would need to refer to a 
generalized existential anyway and if we can do that through a typealias we 
should probably be able to do it directly as well.  That said, if it simplifies 
the implementation in some way it might make sense as a first step.  Whether or 
not that would be the case is something I can’t speak to with any confidence.

> 
> Am 21. August 2017 um 15:10:34, Matthew Johnson (matt...@anandabits.com 
> ) schrieb:
> 
>> If anyone is thinking about spending time on this topic I recommend 
>> beginning by reviewing the prior work that was done by Austin Zheng.  He has 
>> a proposal draft for enhanced existential that is very thorough.  Even if 
>> you're not planning to propose everything that's included in his draft it 
>> would be a good idea to be familiar with it.  Here's the link: 
>> https://github.com/austinzheng/swift-evolution/blob/az-existentials/proposals/-enhanced-existentials.md
>>  
>> .
>> 
>> Sent from my iPad
>> 
>> On Aug 21, 2017, at 6:36 AM, Adrian Zubarev via swift-evolution 
>> > wrote:
>> 
>>> It’s part of Generalized Existentials, but does not make it complete. I 
>>> think it would be worth adding more and more functionality to existentials 
>>> every year. We started first with reshaping the syntax. This year we added 
>>> support for classes. I think next year would be good to have where clause 
>>> support for typealiases.
>>> 
>>> I understand the complexity of that particular feature, and it’s a no-go 
>>> for me to help on the implementation, but I’m willing to drive the 
>>> discussion and the proposal forward with other co-authors. :)
>>> 
>>> Hasn’t it been said that the implementation must be at least a 
>>> *proof-of-concept* if the complexity is very high?
>>> 
>>> And my second question is: Wouldn’t the existence of this feature reshape 
>>> some parts of the standard library, isn’t that affecting some major goals 
>>> of Swift 5?
>>> 
>>> It would be nice if someone from the core team can clarify if the where 
>>> clause is out of scope for Swift 5 or not.
>>> 
>>> 
>>> 
>>> 
>>> Am 21. August 2017 um 12:51:48, David Hart (da...@hartbit.com 
>>> ) schrieb:
>>> 
 
> On 21 Aug 2017, at 11:41, Adrian Zubarev  > wrote:
> 
> Yes, `where` clause is welcome to typealises (including generic ones) and 
> existentials in general. I would love to help on such proposal. I think 
> David Hart is also interested in this one. (cc)
 
 Yes, this basically seems like Generalized Existentials to me and is 
 mentioned in the Generics Manifesto 
 . 
 It’s a feature I hold very dear but:
 
 It’s a very difficult feature to implement and I think Doug Gregor is the 
 only/best person to do it
 I think its pretty much out of scope for Swift 5 (it’s not required for 
 ABI Stability)
 
 As a result, I’d be very surprised if this topic got any discussion or 
 implementation time during the Swift 5 timeframe.
> Am 21. August 2017 um 11:38:14, Gor Gyolchanyan via swift-evolution 
> (swift-evolution@swift.org ) schrieb:
> 
>> Hello, Swift community!
>> 
>> I'd like to start a discussion about a possibility of constrained 
>> protocol aliases. The declaration would look like this:
>> 
>> typealias BinaryProtocol = RandomAccessCollection & MutablCollection & 
>> RangeReplaceableCollection where Binary.Index == Int, Binary.Element == 
>> Bool
>> 
>> The syntax and semantics of this declaration are exactly the same as an 
>> analogous associatedtype declaration inside a protocol.
>> In the example above, the type BinaryProtocol represents a logical array 
>> of bits and is a generic-only protocol that is usable in any context 
>> where an integer-indexed mutable range-replaceable random-access 
>> collection is expected.
>> Now, it can be used in a very concise and elegant way:
>> 
>> public protocol BinaryInitializable {
>> init(binary: Binary) where Binary: 

Re: [swift-evolution] Constrained Protocol Aliases

[Adrian Zubarev via swift-evolution]

Hi Matthew thank you for remembering us about that draft. I’ll re-read it soon. 
At the a quick glance I noticed the extent use of the `where` clause. Wouldn’t 
make sense to simplify the main proposal and just focus on the `where` clause 
for typealises only? It’s already a complex feature on its own. Permitting the 
`where` clause in different places can sill be added later in the future.

Am 21. August 2017 um 15:10:34, Matthew Johnson (matt...@anandabits.com) 
schrieb:

If anyone is thinking about spending time on this topic I recommend beginning 
by reviewing the prior work that was done by Austin Zheng.  He has a proposal 
draft for enhanced existential that is very thorough.  Even if you're not 
planning to propose everything that's included in his draft it would be a good 
idea to be familiar with it.  Here's the link: 
https://github.com/austinzheng/swift-evolution/blob/az-existentials/proposals/-enhanced-existentials.md.

Sent from my iPad

On Aug 21, 2017, at 6:36 AM, Adrian Zubarev via swift-evolution 
 wrote:

It’s part of Generalized Existentials, but does not make it complete. I think 
it would be worth adding more and more functionality to existentials every 
year. We started first with reshaping the syntax. This year we added support 
for classes. I think next year would be good to have where clause support for 
typealiases.

I understand the complexity of that particular feature, and it’s a no-go for me 
to help on the implementation, but I’m willing to drive the discussion and the 
proposal forward with other co-authors. :)

Hasn’t it been said that the implementation must be at least a 
*proof-of-concept* if the complexity is very high?

And my second question is: Wouldn’t the existence of this feature reshape some 
parts of the standard library, isn’t that affecting some major goals of Swift 5?

It would be nice if someone from the core team can clarify if the where clause 
is out of scope for Swift 5 or not.




Am 21. August 2017 um 12:51:48, David Hart (da...@hartbit.com) schrieb:


On 21 Aug 2017, at 11:41, Adrian Zubarev  
wrote:

Yes, `where` clause is welcome to typealises (including generic ones) and 
existentials in general. I would love to help on such proposal. I think David 
Hart is also interested in this one. (cc)

Yes, this basically seems like Generalized Existentials to me and is mentioned 
in the Generics Manifesto. It’s a feature I hold very dear but:

It’s a very difficult feature to implement and I think Doug Gregor is the 
only/best person to do it
I think its pretty much out of scope for Swift 5 (it’s not required for ABI 
Stability)

As a result, I’d be very surprised if this topic got any discussion or 
implementation time during the Swift 5 timeframe.
Am 21. August 2017 um 11:38:14, Gor Gyolchanyan via swift-evolution 
(swift-evolution@swift.org) schrieb:

Hello, Swift community!

I'd like to start a discussion about a possibility of constrained protocol 
aliases. The declaration would look like this:

typealias BinaryProtocol = RandomAccessCollection & MutablCollection & 
RangeReplaceableCollection where Binary.Index == Int, Binary.Element == Bool

The syntax and semantics of this declaration are exactly the same as an 
analogous associatedtype declaration inside a protocol.
In the example above, the type BinaryProtocol represents a logical array of 
bits and is a generic-only protocol that is usable in any context where an 
integer-indexed mutable range-replaceable random-access collection is expected.
Now, it can be used in a very concise and elegant way:

public protocol BinaryInitializable {
init(binary: Binary) where Binary: BinaryProtocol
}

which would otherwise look very verbose and inelegant:

public protocol BinaryInitializable {
init(binary: Binary) where Binary: RandomAccessCollection & 
MutablCollection & RangeReplaceableCollection, Binary.Index == Int, 
Binary.Element == Bool
}

Considering that smaller sets of constraints could be aliased to their own 
protocol and then composited into more complex aliases, this feature would 
dramatically improve readability and maintainability of code that uses complex 
constraints, that currently leads to arcane mess:

struct Mirror {
/// ...
init(_ subject: Subject, 
children: C, displayStyle: Mirror.DisplayStyle? = default, 
ancestorRepresentation: Mirror.AncestorRepresentation = default)
/// ...
}


/// A 

Re: [swift-evolution] Constrained Protocol Aliases

[Adrian Zubarev via swift-evolution]

Well I didn’t meant to say to spend time for something that will not even make 
into a review. If we can have some clarification from the core team, we still 
can decide if we’d tackle it or not. ;)




Am 21. August 2017 um 14:51:06, David Hart (da...@hartbit.com) schrieb:


On 21 Aug 2017, at 13:36, Adrian Zubarev  
wrote:

It’s part of Generalized Existentials, but does not make it complete. I think 
it would be worth adding more and more functionality to existentials every 
year. We started first with reshaping the syntax. This year we added support 
for classes. I think next year would be good to have where clause support for 
typealiases. 

I understand the complexity of that particular feature, and it’s a no-go for me 
to help on the implementation, but I’m willing to drive the discussion and the 
proposal forward with other co-authors. :)

Hasn’t it been said that the implementation must be at least a 
*proof-of-concept* if the complexity is very high?

I’d love to have this feature. But I’m not sure even a partway proposal will 
get to review with the laser-focus on ABI Stability + Concurrency. I don’t want 
to spend time co-authoring a proposal if it is going to be out of scope anyway. 
Perhaps Doug (CC) can give us some ideas.
And my second question is: Wouldn’t the existence of this feature reshape some 
parts of the standard library, isn’t that affecting some major goals of Swift 5?

Yes. But that also true of many other language feature. But the Standard 
Library still needs to be set in stone at some point or another.
It would be nice if someone from the core team can clarify if the where clause 
is out of scope for Swift 5 or not.

Agreed.


Am 21. August 2017 um 12:51:48, David Hart (da...@hartbit.com) schrieb:


On 21 Aug 2017, at 11:41, Adrian Zubarev  
wrote:

Yes, `where` clause is welcome to typealises (including generic ones) and 
existentials in general. I would love to help on such proposal. I think David 
Hart is also interested in this one. (cc)

Yes, this basically seems like Generalized Existentials to me and is mentioned 
in the Generics Manifesto. It’s a feature I hold very dear but:

It’s a very difficult feature to implement and I think Doug Gregor is the 
only/best person to do it
I think its pretty much out of scope for Swift 5 (it’s not required for ABI 
Stability)

As a result, I’d be very surprised if this topic got any discussion or 
implementation time during the Swift 5 timeframe.
Am 21. August 2017 um 11:38:14, Gor Gyolchanyan via swift-evolution 
(swift-evolution@swift.org) schrieb:

Hello, Swift community!

I'd like to start a discussion about a possibility of constrained protocol 
aliases. The declaration would look like this:

typealias BinaryProtocol = RandomAccessCollection & MutablCollection & 
RangeReplaceableCollection where Binary.Index == Int, Binary.Element == Bool

The syntax and semantics of this declaration are exactly the same as an 
analogous associatedtype declaration inside a protocol.
In the example above, the type BinaryProtocol represents a logical array of 
bits and is a generic-only protocol that is usable in any context where an 
integer-indexed mutable range-replaceable random-access collection is expected.
Now, it can be used in a very concise and elegant way:

public protocol BinaryInitializable {
init(binary: Binary) where Binary: BinaryProtocol
}

which would otherwise look very verbose and inelegant:

public protocol BinaryInitializable {
init(binary: Binary) where Binary: RandomAccessCollection & 
MutablCollection & RangeReplaceableCollection, Binary.Index == Int, 
Binary.Element == Bool
}

Considering that smaller sets of constraints could be aliased to their own 
protocol and then composited into more complex aliases, this feature would 
dramatically improve readability and maintainability of code that uses complex 
constraints, that currently leads to arcane mess:

struct Mirror {
/// ...
init(_ subject: Subject, 
children: C, displayStyle: Mirror.DisplayStyle? = default, 
ancestorRepresentation: Mirror.AncestorRepresentation = default)
/// ...
}


/// A collection that is its own sub-sequence
typealias RecursivelySliceableCollection = Collection where
RecursivelySliceableCollection.SubSequence: Collection,
RecursivelySliceableCollection.SubSequence.Element == 
RecursivelySliceableCollection.Element

Re: [swift-evolution] (core library) modern URL types

[Félix Cloutier via swift-evolution]

There's no question that there's a lot in common between file: URLs and other 
URLs, but that hardly makes URLs better in the file: case.

I saw the enum. The problem remains that it's a common API principle to accept 
the broadest possible input. It's not fundamentally wrong to accept and resolve 
common URL types, as there's a ton of things that need to read documents from 
the Internet by design. However, if this is the default facility for file 
handling too, it invents either:

A responsibility for API users to check that their URL is a file: URL;
A responsibility for API authors to provide separate entry points for file URLs 
and remote URLs, and a responsibility for API users to use the right one.

It would also add a category of errors to common filesystem operations: "can't 
do this because the URL is not a file: URL", and a category of questions that 
we arguably shouldn't need to ask ourselves. For instance, what is the correct 
result of glob()ing a file: URL pattern with a hash or a query string, should 
each element include that hash/query string too?

Félix

> Le 20 août 2017 à 23:33, Taylor Swift  a écrit :
> 
> I think that’s more a problem that lies in Foundation methods that take URLs 
> rather than the URLs themselves. A URL is a useful abstraction because it 
> contains a lot of common functionality between local file paths and internet 
> resources. For example, relative URI reference resolution. APIs which take 
> URLs as arguments should be responsible for ensuring that the URL’s schema is 
> a `file:`. The new URL type I’m writing actually makes the scheme an enum 
> with cases `.file`, `.http`, `.https`, `.ftp`, and `.data` to ease checking 
> this.
> 
> On Mon, Aug 21, 2017 at 2:23 AM, Félix Cloutier  > wrote:
> I'm not convinced that URLs are the appropriate abstraction for a file system 
> path. For the record, I'm not a fan of existing Foundation methods that 
> create objects from an URL. There is a useful and fundamental difference 
> between a local path and a remote path, and conflating the two has been a 
> security pain point in many languages and frameworks that allow it. Examples 
> include remote file inclusion in PHP and malicious doctypes in XML. Windows 
> also had its share of issues with UNC paths.
> 
> Even when loading an arbitrary URL looks innocuous, many de-anonymizing hacks 
> work by causing a program to access an URL controlled by an attacker to make 
> it disclose the user's IP address or some other identifier.
> 
> IMO, this justifies that there should be separate types to handle local and 
> remote resources, so that at least developers have to be explicit about 
> allowing remote resources. This makes a new URL type less necessary towards 
> supporting file I/O.
> 
> Félix
> 
>> Le 20 août 2017 à 21:37, Taylor Swift via swift-evolution 
>> > a écrit :
>> 
>> Okay so a few days ago there was a discussion 
>> 
>>  about getting pure swift file system support into Foundation or another 
>> core library, and in my opinion, doing this requires a total overhaul of the 
>> `URL` type (which is currently little more than a wrapper for NSURL), so 
>> I’ve just started a pure Swift URL library project at 
>> >.
>> 
>> The library’s parsing and validation core (~1K loc pure swift) is already in 
>> place and functional; the goal is to eventually support all of the 
>> Foundation URL functionality.
>> 
>> The new `URL` type is implemented as a value type with utf8 storage backed 
>> by an array buffer. The URLs are just 56 bytes long each, so they should be 
>> able to fit into cache lines. (NSURL by comparison is over 128 bytes in 
>> size; it’s only saved by the fact that the thing is passed as a reference 
>> type.)
>> 
>> As I said, this is still really early on and not a mature library at all but 
>> everyone is invited to observe, provide feedback, or contribute!
>> ___
>> 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] Constrained Protocol Aliases

[Tony Allevato via swift-evolution]

On Mon, Aug 21, 2017 at 5:51 AM David Hart via swift-evolution <
swift-evolution@swift.org> wrote:

> On 21 Aug 2017, at 13:36, Adrian Zubarev 
> wrote:
>
> It’s part of Generalized Existentials, but does not make it complete. I
> think it would be worth adding more and more functionality to existentials
> every year. We started first with reshaping the syntax. This year we added
> support for classes. I think next year would be good to have where clause
> support for typealiases.
>
> I understand the complexity of that particular feature, and it’s a no-go
> for me to help on the implementation, but I’m willing to drive the
> discussion and the proposal forward with other co-authors. :)
>
> Hasn’t it been said that the implementation must be at least a
> *proof-of-concept* if the complexity is very high?
>
> I’d love to have this feature. But I’m not sure even a partway proposal
> will get to review with the laser-focus on ABI Stability + Concurrency. I
> don’t want to spend time co-authoring a proposal if it is going to be out
> of scope anyway. Perhaps Doug (CC) can give us some ideas.
>

For what it's worth, the updated README on swift-evolution says:

"Beyond ABI stability (which focuses mostly on getting a bunch of low-level
implementation details of the language finalized), in Swift 5 the evolution
process welcomes additions that improve the overall usability of the
language and standard library"

So it sounds like they're willing to consider proposals outside of
ABI+concurrency—and though I can't speak for the core team's motivation, it
seems like requiring an implementation before formal review means that
proposals beyond their primary focus have a greater chance of making it
into the language than they did before.


> And my second question is: Wouldn’t the existence of this feature reshape
> some parts of the standard library, isn’t that affecting some major goals
> of Swift 5?
>
> Yes. But that also true of many other language feature. But the Standard
> Library still needs to be set in stone at some point or another.
>
> It would be nice if someone from the core team can clarify if the where clause
> is out of scope for Swift 5 or not.
>
> Agreed.
>
>
> Am 21. August 2017 um 12:51:48, David Hart (da...@hartbit.com) schrieb:
>
>
> On 21 Aug 2017, at 11:41, Adrian Zubarev 
> wrote:
>
> Yes, `where` clause is welcome to typealises (including generic ones) and
> existentials in general. I would love to help on such proposal. I think
> David Hart is also interested in this one. (cc)
>
>
> Yes, this basically seems like *Generalized Existentials* to me and is
> mentioned in the Generics Manifesto
> .
> It’s a feature I hold very dear but:
>
>
>- It’s a very difficult feature to implement and I think Doug Gregor
>is the only/best person to do it
>- I think its pretty much out of scope for Swift 5 (it’s not required
>for ABI Stability)
>
>
> As a result, I’d be very surprised if this topic got any discussion or
> implementation time during the Swift 5 timeframe.
>
> Am 21. August 2017 um 11:38:14, Gor Gyolchanyan via swift-evolution (
> swift-evolution@swift.org) schrieb:
>
> Hello, Swift community!
>
> I'd like to start a discussion about a possibility of constrained protocol
> aliases. The declaration would look like this:
>
> typealias BinaryProtocol = RandomAccessCollection & MutablCollection &
> RangeReplaceableCollection where Binary.Index == Int, Binary.Element ==
> Bool
>
> The syntax and semantics of this declaration are exactly the same as an
> analogous associatedtype declaration inside a protocol.
> In the example above, the type BinaryProtocol represents a logical array
> of bits and is a generic-only protocol that is usable in any context where
> an integer-indexed mutable range-replaceable random-access collection is
> expected.
> Now, it can be used in a very concise and elegant way:
>
> public protocol BinaryInitializable {
> init(binary: Binary) where Binary: BinaryProtocol
> }
>
> which would otherwise look very verbose and inelegant:
>
> public protocol BinaryInitializable {
> init(binary: Binary) where Binary: RandomAccessCollection &
> MutablCollection & RangeReplaceableCollection, Binary.Index == Int, Binary
> .Element == Bool
> }
>
> Considering that smaller sets of constraints could be aliased to their own
> protocol and then composited into more complex aliases, this feature would
> dramatically improve readability and maintainability of code that uses
> complex constraints, that currently leads to arcane mess:
>
> struct Mirror {
>
>- /// ...
>- initSubSequence : Collection, C.Indices.Index == C.Index, C.Indices.
>SubSequence == C.Indices, C.Iterator.Element == Mirror.Child, C.
>SubSequence.Index == C.Index, C.SubSequence.Indices : Collection, 

Re: [swift-evolution] Constrained Protocol Aliases

[Matthew Johnson via swift-evolution]

If anyone is thinking about spending time on this topic I recommend beginning 
by reviewing the prior work that was done by Austin Zheng.  He has a proposal 
draft for enhanced existential that is very thorough.  Even if you're not 
planning to propose everything that's included in his draft it would be a good 
idea to be familiar with it.  Here's the link: 
https://github.com/austinzheng/swift-evolution/blob/az-existentials/proposals/-enhanced-existentials.md.

Sent from my iPad

> On Aug 21, 2017, at 6:36 AM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> It’s part of Generalized Existentials, but does not make it complete. I think 
> it would be worth adding more and more functionality to existentials every 
> year. We started first with reshaping the syntax. This year we added support 
> for classes. I think next year would be good to have where clause support for 
> typealiases.
> 
> I understand the complexity of that particular feature, and it’s a no-go for 
> me to help on the implementation, but I’m willing to drive the discussion and 
> the proposal forward with other co-authors. :)
> 
> Hasn’t it been said that the implementation must be at least a 
> *proof-of-concept* if the complexity is very high?
> 
> And my second question is: Wouldn’t the existence of this feature reshape 
> some parts of the standard library, isn’t that affecting some major goals of 
> Swift 5?
> 
> It would be nice if someone from the core team can clarify if the where 
> clause is out of scope for Swift 5 or not.
> 
> 
> 
> 
> Am 21. August 2017 um 12:51:48, David Hart (da...@hartbit.com) schrieb:
> 
>> 
>>> On 21 Aug 2017, at 11:41, Adrian Zubarev  
>>> wrote:
>>> 
>>> Yes, `where` clause is welcome to typealises (including generic ones) and 
>>> existentials in general. I would love to help on such proposal. I think 
>>> David Hart is also interested in this one. (cc)
>> 
>> Yes, this basically seems like Generalized Existentials to me and is 
>> mentioned in the Generics Manifesto. It’s a feature I hold very dear but:
>> 
>> It’s a very difficult feature to implement and I think Doug Gregor is the 
>> only/best person to do it
>> I think its pretty much out of scope for Swift 5 (it’s not required for ABI 
>> Stability)
>> 
>> As a result, I’d be very surprised if this topic got any discussion or 
>> implementation time during the Swift 5 timeframe.
>>> Am 21. August 2017 um 11:38:14, Gor Gyolchanyan via swift-evolution 
>>> (swift-evolution@swift.org) schrieb:
>>> 
 Hello, Swift community!
 
 I'd like to start a discussion about a possibility of constrained protocol 
 aliases. The declaration would look like this:
 
 typealias BinaryProtocol = RandomAccessCollection & MutablCollection & 
 RangeReplaceableCollection where Binary.Index == Int, Binary.Element == 
 Bool
 
 The syntax and semantics of this declaration are exactly the same as an 
 analogous associatedtype declaration inside a protocol.
 In the example above, the type BinaryProtocol represents a logical array 
 of bits and is a generic-only protocol that is usable in any context where 
 an integer-indexed mutable range-replaceable random-access collection is 
 expected.
 Now, it can be used in a very concise and elegant way:
 
 public protocol BinaryInitializable {
 init(binary: Binary) where Binary: BinaryProtocol
 }
 
 which would otherwise look very verbose and inelegant:
 
 public protocol BinaryInitializable {
 init(binary: Binary) where Binary: RandomAccessCollection & 
 MutablCollection & RangeReplaceableCollection, Binary.Index == Int, 
 Binary.Element == Bool
 }
 
 Considering that smaller sets of constraints could be aliased to their own 
 protocol and then composited into more complex aliases, this feature would 
 dramatically improve readability and maintainability of code that uses 
 complex constraints, that currently leads to arcane mess:
 
 struct Mirror {
 /// ...
 init(_ subject: Subject, 
 children: C, displayStyle: Mirror.DisplayStyle? = default, 
 ancestorRepresentation: Mirror.AncestorRepresentation = default)
 /// ...
 }
 
 
 /// A collection that is its own sub-sequence
 typealias RecursivelySliceableCollection = 

Re: [swift-evolution] Constrained Protocol Aliases

[David Hart via swift-evolution]

> On 21 Aug 2017, at 13:36, Adrian Zubarev  
> wrote:
> 
> It’s part of Generalized Existentials, but does not make it complete. I think 
> it would be worth adding more and more functionality to existentials every 
> year. We started first with reshaping the syntax. This year we added support 
> for classes. I think next year would be good to have where clause support for 
> typealiases. 
> 
> I understand the complexity of that particular feature, and it’s a no-go for 
> me to help on the implementation, but I’m willing to drive the discussion and 
> the proposal forward with other co-authors. :)
> 
> Hasn’t it been said that the implementation must be at least a 
> *proof-of-concept* if the complexity is very high?
> 
I’d love to have this feature. But I’m not sure even a partway proposal will 
get to review with the laser-focus on ABI Stability + Concurrency. I don’t want 
to spend time co-authoring a proposal if it is going to be out of scope anyway. 
Perhaps Doug (CC) can give us some ideas.
> And my second question is: Wouldn’t the existence of this feature reshape 
> some parts of the standard library, isn’t that affecting some major goals of 
> Swift 5?
> 
Yes. But that also true of many other language feature. But the Standard 
Library still needs to be set in stone at some point or another.
> It would be nice if someone from the core team can clarify if the where 
> clause is out of scope for Swift 5 or not.
> 
Agreed.

> 
> Am 21. August 2017 um 12:51:48, David Hart (da...@hartbit.com 
> ) schrieb:
> 
>> 
>>> On 21 Aug 2017, at 11:41, Adrian Zubarev >> > wrote:
>>> 
>>> Yes, `where` clause is welcome to typealises (including generic ones) and 
>>> existentials in general. I would love to help on such proposal. I think 
>>> David Hart is also interested in this one. (cc)
>> 
>> Yes, this basically seems like Generalized Existentials to me and is 
>> mentioned in the Generics Manifesto 
>> . It’s 
>> a feature I hold very dear but:
>> 
>> It’s a very difficult feature to implement and I think Doug Gregor is the 
>> only/best person to do it
>> I think its pretty much out of scope for Swift 5 (it’s not required for ABI 
>> Stability)
>> 
>> As a result, I’d be very surprised if this topic got any discussion or 
>> implementation time during the Swift 5 timeframe.
>>> Am 21. August 2017 um 11:38:14, Gor Gyolchanyan via swift-evolution 
>>> (swift-evolution@swift.org ) schrieb:
>>> 
 Hello, Swift community!
 
 I'd like to start a discussion about a possibility of constrained protocol 
 aliases. The declaration would look like this:
 
 typealias BinaryProtocol = RandomAccessCollection & MutablCollection & 
 RangeReplaceableCollection where Binary.Index == Int, Binary.Element == 
 Bool
 
 The syntax and semantics of this declaration are exactly the same as an 
 analogous associatedtype declaration inside a protocol.
 In the example above, the type BinaryProtocol represents a logical array 
 of bits and is a generic-only protocol that is usable in any context where 
 an integer-indexed mutable range-replaceable random-access collection is 
 expected.
 Now, it can be used in a very concise and elegant way:
 
 public protocol BinaryInitializable {
 init(binary: Binary) where Binary: BinaryProtocol
 }
 
 which would otherwise look very verbose and inelegant:
 
 public protocol BinaryInitializable {
 init(binary: Binary) where Binary: RandomAccessCollection & 
 MutablCollection & RangeReplaceableCollection, Binary.Index == Int, 
 Binary.Element == Bool
 }
 
 Considering that smaller sets of constraints could be aliased to their own 
 protocol and then composited into more complex aliases, this feature would 
 dramatically improve readability and maintainability of code that uses 
 complex constraints, that currently leads to arcane mess:
 
 struct Mirror {
 /// ...
 init(_ subject: Subject, 
 children: C, displayStyle: Mirror.DisplayStyle? = default, 
 ancestorRepresentation: Mirror.AncestorRepresentation = default)
 /// ...
 }
 
 

Re: [swift-evolution] Constrained Protocol Aliases

[Adrian Zubarev via swift-evolution]

It’s part of Generalized Existentials, but does not make it complete. I think 
it would be worth adding more and more functionality to existentials every 
year. We started first with reshaping the syntax. This year we added support 
for classes. I think next year would be good to have where clause support for 
typealiases.

I understand the complexity of that particular feature, and it’s a no-go for me 
to help on the implementation, but I’m willing to drive the discussion and the 
proposal forward with other co-authors. :)

Hasn’t it been said that the implementation must be at least a 
*proof-of-concept* if the complexity is very high?

And my second question is: Wouldn’t the existence of this feature reshape some 
parts of the standard library, isn’t that affecting some major goals of Swift 5?

It would be nice if someone from the core team can clarify if the where clause 
is out of scope for Swift 5 or not.




Am 21. August 2017 um 12:51:48, David Hart (da...@hartbit.com) schrieb:


On 21 Aug 2017, at 11:41, Adrian Zubarev  
wrote:

Yes, `where` clause is welcome to typealises (including generic ones) and 
existentials in general. I would love to help on such proposal. I think David 
Hart is also interested in this one. (cc)

Yes, this basically seems like Generalized Existentials to me and is mentioned 
in the Generics Manifesto. It’s a feature I hold very dear but:

It’s a very difficult feature to implement and I think Doug Gregor is the 
only/best person to do it
I think its pretty much out of scope for Swift 5 (it’s not required for ABI 
Stability)

As a result, I’d be very surprised if this topic got any discussion or 
implementation time during the Swift 5 timeframe.
Am 21. August 2017 um 11:38:14, Gor Gyolchanyan via swift-evolution 
(swift-evolution@swift.org) schrieb:

Hello, Swift community!

I'd like to start a discussion about a possibility of constrained protocol 
aliases. The declaration would look like this:

typealias BinaryProtocol = RandomAccessCollection & MutablCollection & 
RangeReplaceableCollection where Binary.Index == Int, Binary.Element == Bool

The syntax and semantics of this declaration are exactly the same as an 
analogous associatedtype declaration inside a protocol.
In the example above, the type BinaryProtocol represents a logical array of 
bits and is a generic-only protocol that is usable in any context where an 
integer-indexed mutable range-replaceable random-access collection is expected.
Now, it can be used in a very concise and elegant way:

public protocol BinaryInitializable {
init(binary: Binary) where Binary: BinaryProtocol
}

which would otherwise look very verbose and inelegant:

public protocol BinaryInitializable {
init(binary: Binary) where Binary: RandomAccessCollection & 
MutablCollection & RangeReplaceableCollection, Binary.Index == Int, 
Binary.Element == Bool
}

Considering that smaller sets of constraints could be aliased to their own 
protocol and then composited into more complex aliases, this feature would 
dramatically improve readability and maintainability of code that uses complex 
constraints, that currently leads to arcane mess:

struct Mirror {
/// ...
init(_ subject: Subject, 
children: C, displayStyle: Mirror.DisplayStyle? = default, 
ancestorRepresentation: Mirror.AncestorRepresentation = default)
/// ...
}


/// A collection that is its own sub-sequence
typealias RecursivelySliceableCollection = Collection where
RecursivelySliceableCollection.SubSequence: Collection,
RecursivelySliceableCollection.SubSequence.Element == 
RecursivelySliceableCollection.Element
RecursivelySliceableCollection.SubSequence.Indices == 
RecursivelySliceableCollection.Indices,
RecursivelySliceableCollection.SubSequence.SubSequence == 
RecursivelySliceableCollection.SubSequence

/// A collection that is its own index collection
typealias RecursivelyIndexableCollection = Collection where
RecursivelyIndexableCollection.Indices == RecursivelySliceableCollection,
RecursivelyIndexableCollection.Indices.Index == 
RecursivelyIndexableCollection.Index,

struct Mirror {
/// ...
init(_ subject: 
Subject, children: C, displayStyle: Mirror.DisplayStyle? = default, 
ancestorRepresentation: Mirror.AncestorRepresentation = default)
/// ...
}

Even considering that the proposal SE-0157 

Re: [swift-evolution] Constrained Protocol Aliases

[David Hart via swift-evolution]

> On 21 Aug 2017, at 11:41, Adrian Zubarev  
> wrote:
> 
> Yes, `where` clause is welcome to typealises (including generic ones) and 
> existentials in general. I would love to help on such proposal. I think David 
> Hart is also interested in this one. (cc)

Yes, this basically seems like Generalized Existentials to me and is mentioned 
in the Generics Manifesto 
. It’s a 
feature I hold very dear but:

It’s a very difficult feature to implement and I think Doug Gregor is the 
only/best person to do it
I think its pretty much out of scope for Swift 5 (it’s not required for ABI 
Stability)

As a result, I’d be very surprised if this topic got any discussion or 
implementation time during the Swift 5 timeframe.
> Am 21. August 2017 um 11:38:14, Gor Gyolchanyan via swift-evolution 
> (swift-evolution@swift.org ) schrieb:
> 
>> Hello, Swift community!
>> 
>> I'd like to start a discussion about a possibility of constrained protocol 
>> aliases. The declaration would look like this:
>> 
>> typealias BinaryProtocol = RandomAccessCollection & MutablCollection & 
>> RangeReplaceableCollection where Binary.Index == Int, Binary.Element == Bool
>> 
>> The syntax and semantics of this declaration are exactly the same as an 
>> analogous associatedtype declaration inside a protocol.
>> In the example above, the type BinaryProtocol represents a logical array of 
>> bits and is a generic-only protocol that is usable in any context where an 
>> integer-indexed mutable range-replaceable random-access collection is 
>> expected.
>> Now, it can be used in a very concise and elegant way:
>> 
>> public protocol BinaryInitializable {
>> init(binary: Binary) where Binary: BinaryProtocol
>> }
>> 
>> which would otherwise look very verbose and inelegant:
>> 
>> public protocol BinaryInitializable {
>> init(binary: Binary) where Binary: RandomAccessCollection & 
>> MutablCollection & RangeReplaceableCollection, Binary.Index == Int, 
>> Binary.Element == Bool
>> }
>> 
>> Considering that smaller sets of constraints could be aliased to their own 
>> protocol and then composited into more complex aliases, this feature would 
>> dramatically improve readability and maintainability of code that uses 
>> complex constraints, that currently leads to arcane mess:
>> 
>> struct Mirror {
>> /// ...
>> init> : Collection, C.Indices.Index == C.Index, C.Indices.SubSequence == 
>> C.Indices, C.Iterator.Element == Mirror.Child, C.SubSequence.Index == 
>> C.Index, C.SubSequence.Indices : Collection, C.SubSequence.SubSequence == 
>> C.SubSequence, C.Indices.Iterator.Element == C.Index, 
>> C.SubSequence.Indices.Index == C.Index, C.SubSequence.Indices.SubSequence == 
>> C.SubSequence.Indices, C.SubSequence.Iterator.Element == Mirror.Child, 
>> C.SubSequence.Indices.Iterator.Element == C.Index>(_ subject: Subject, 
>> children: C, displayStyle: Mirror.DisplayStyle? = default, 
>> ancestorRepresentation: Mirror.AncestorRepresentation = default)
>> /// ...
>> }
>> 
>> 
>> /// A collection that is its own sub-sequence
>> typealias RecursivelySliceableCollection = Collection where
>> RecursivelySliceableCollection.SubSequence: Collection,
>> RecursivelySliceableCollection.SubSequence.Element == 
>> RecursivelySliceableCollection.Element
>> RecursivelySliceableCollection.SubSequence.Indices == 
>> RecursivelySliceableCollection.Indices,
>> RecursivelySliceableCollection.SubSequence.SubSequence == 
>> RecursivelySliceableCollection.SubSequence
>> 
>> /// A collection that is its own index collection
>> typealias RecursivelyIndexableCollection = Collection where
>> RecursivelyIndexableCollection.Indices == RecursivelySliceableCollection,
>> RecursivelyIndexableCollection.Indices.Index == 
>> RecursivelyIndexableCollection.Index,
>> 
>> struct Mirror {
>> /// ...
>> init> RecursivelyIndexableCollection, where  C.Element == Mirror.Child>(_ subject: 
>> Subject, children: C, displayStyle: Mirror.DisplayStyle? = default, 
>> ancestorRepresentation: Mirror.AncestorRepresentation = default)
>> /// ...
>> }
>> 
>> Even considering that the proposal SE-0157 
>> (https://github.com/apple/swift-evolution/blob/master/proposals/0157-recursive-protocol-constraints.md
>>  
>> )
>>  is going to make this specific use case a non-issue, the principle applies 
>> to all cases where there are commonly used complex constraints that don't 
>> necessarily involve recursive constraints.
>> 
>> Specializing Generic-Only Protocols For Non-Generic Use
>> 
>> An additional feature that would prove to be very useful would be to make a 
>> constrained protocol alias be a non-generic-only protocol if the constraints 
>> of the 

Re: [swift-evolution] Constrained Protocol Aliases

[Gor Gyolchanyan via swift-evolution]

I'm not very familiar with the Swift compiler codebase and it would take me 
more time to implement this than someone that has already contributed before. 
Considering that since Swift 5 proposals are required to include a pull request 
with an implementation, it would be much faster if someone with better 
knowledge of the compiler codebase would help me with the implementation, so a 
formal proposal could be made.

So... If someone wants to pitch in and help implement this, I'd be very 
grateful! 

I do want to get around to study the compiler's code inside-and-out, but that's 
an asynchronous process.

> On Aug 21, 2017, at 12:41 PM, Adrian Zubarev 
>  wrote:
> 
> Yes, `where` clause is welcome to typealises (including generic ones) and 
> existentials in general. I would love to help on such proposal. I think David 
> Hart is also interested in this one. (cc)
> 
> 
> Am 21. August 2017 um 11:38:14, Gor Gyolchanyan via swift-evolution 
> (swift-evolution@swift.org ) schrieb:
> 
>> Hello, Swift community!
>> 
>> I'd like to start a discussion about a possibility of constrained protocol 
>> aliases. The declaration would look like this:
>> 
>> typealias BinaryProtocol = RandomAccessCollection & MutablCollection & 
>> RangeReplaceableCollection where Binary.Index == Int, Binary.Element == Bool
>> 
>> The syntax and semantics of this declaration are exactly the same as an 
>> analogous associatedtype declaration inside a protocol.
>> In the example above, the type BinaryProtocol represents a logical array of 
>> bits and is a generic-only protocol that is usable in any context where an 
>> integer-indexed mutable range-replaceable random-access collection is 
>> expected.
>> Now, it can be used in a very concise and elegant way:
>> 
>> public protocol BinaryInitializable {
>> init(binary: Binary) where Binary: BinaryProtocol
>> }
>> 
>> which would otherwise look very verbose and inelegant:
>> 
>> public protocol BinaryInitializable {
>> init(binary: Binary) where Binary: RandomAccessCollection & 
>> MutablCollection & RangeReplaceableCollection, Binary.Index == Int, 
>> Binary.Element == Bool
>> }
>> 
>> Considering that smaller sets of constraints could be aliased to their own 
>> protocol and then composited into more complex aliases, this feature would 
>> dramatically improve readability and maintainability of code that uses 
>> complex constraints, that currently leads to arcane mess:
>> 
>> struct Mirror {
>> /// ...
>> init> : Collection, C.Indices.Index == C.Index, C.Indices.SubSequence == 
>> C.Indices, C.Iterator.Element == Mirror.Child, C.SubSequence.Index == 
>> C.Index, C.SubSequence.Indices : Collection, C.SubSequence.SubSequence == 
>> C.SubSequence, C.Indices.Iterator.Element == C.Index, 
>> C.SubSequence.Indices.Index == C.Index, C.SubSequence.Indices.SubSequence == 
>> C.SubSequence.Indices, C.SubSequence.Iterator.Element == Mirror.Child, 
>> C.SubSequence.Indices.Iterator.Element == C.Index>(_ subject: Subject, 
>> children: C, displayStyle: Mirror.DisplayStyle? = default, 
>> ancestorRepresentation: Mirror.AncestorRepresentation = default)
>> /// ...
>> }
>> 
>> 
>> /// A collection that is its own sub-sequence
>> typealias RecursivelySliceableCollection = Collection where
>> RecursivelySliceableCollection.SubSequence: Collection,
>> RecursivelySliceableCollection.SubSequence.Element == 
>> RecursivelySliceableCollection.Element
>> RecursivelySliceableCollection.SubSequence.Indices == 
>> RecursivelySliceableCollection.Indices,
>> RecursivelySliceableCollection.SubSequence.SubSequence == 
>> RecursivelySliceableCollection.SubSequence
>> 
>> /// A collection that is its own index collection
>> typealias RecursivelyIndexableCollection = Collection where
>> RecursivelyIndexableCollection.Indices == RecursivelySliceableCollection,
>> RecursivelyIndexableCollection.Indices.Index == 
>> RecursivelyIndexableCollection.Index,
>> 
>> struct Mirror {
>> /// ...
>> init> RecursivelyIndexableCollection, where  C.Element == Mirror.Child>(_ subject: 
>> Subject, children: C, displayStyle: Mirror.DisplayStyle? = default, 
>> ancestorRepresentation: Mirror.AncestorRepresentation = default)
>> /// ...
>> }
>> 
>> Even considering that the proposal SE-0157 
>> (https://github.com/apple/swift-evolution/blob/master/proposals/0157-recursive-protocol-constraints.md
>>  
>> )
>>  is going to make this specific use case a non-issue, the principle applies 
>> to all cases where there are commonly used complex constraints that don't 
>> necessarily involve recursive constraints.
>> 
>> Specializing Generic-Only Protocols For Non-Generic Use
>> 
>> An additional feature that would prove to be very useful would be to make a 

Re: [swift-evolution] Constrained Protocol Aliases

[Adrian Zubarev via swift-evolution]

Yes, `where` clause is welcome to typealises (including generic ones) and 
existentials in general. I would love to help on such proposal. I think David 
Hart is also interested in this one. (cc)


Am 21. August 2017 um 11:38:14, Gor Gyolchanyan via swift-evolution 
(swift-evolution@swift.org) schrieb:

Hello, Swift community!

I'd like to start a discussion about a possibility of constrained protocol 
aliases. The declaration would look like this:

typealias BinaryProtocol = RandomAccessCollection & MutablCollection & 
RangeReplaceableCollection where Binary.Index == Int, Binary.Element == Bool

The syntax and semantics of this declaration are exactly the same as an 
analogous associatedtype declaration inside a protocol.
In the example above, the type BinaryProtocol represents a logical array of 
bits and is a generic-only protocol that is usable in any context where an 
integer-indexed mutable range-replaceable random-access collection is expected.
Now, it can be used in a very concise and elegant way:

public protocol BinaryInitializable {
init(binary: Binary) where Binary: BinaryProtocol
}

which would otherwise look very verbose and inelegant:

public protocol BinaryInitializable {
init(binary: Binary) where Binary: RandomAccessCollection & 
MutablCollection & RangeReplaceableCollection, Binary.Index == Int, 
Binary.Element == Bool
}

Considering that smaller sets of constraints could be aliased to their own 
protocol and then composited into more complex aliases, this feature would 
dramatically improve readability and maintainability of code that uses complex 
constraints, that currently leads to arcane mess:

struct Mirror {
/// ...
init(_ subject: Subject, 
children: C, displayStyle: Mirror.DisplayStyle? = default, 
ancestorRepresentation: Mirror.AncestorRepresentation = default)
/// ...
}


/// A collection that is its own sub-sequence
typealias RecursivelySliceableCollection = Collection where
RecursivelySliceableCollection.SubSequence: Collection,
RecursivelySliceableCollection.SubSequence.Element == 
RecursivelySliceableCollection.Element
RecursivelySliceableCollection.SubSequence.Indices == 
RecursivelySliceableCollection.Indices,
RecursivelySliceableCollection.SubSequence.SubSequence == 
RecursivelySliceableCollection.SubSequence

/// A collection that is its own index collection
typealias RecursivelyIndexableCollection = Collection where
RecursivelyIndexableCollection.Indices == RecursivelySliceableCollection,
RecursivelyIndexableCollection.Indices.Index == 
RecursivelyIndexableCollection.Index,

struct Mirror {
/// ...
init(_ subject: 
Subject, children: C, displayStyle: Mirror.DisplayStyle? = default, 
ancestorRepresentation: Mirror.AncestorRepresentation = default)
/// ...
}

Even considering that the proposal SE-0157 
(https://github.com/apple/swift-evolution/blob/master/proposals/0157-recursive-protocol-constraints.md)
 is going to make this specific use case a non-issue, the principle applies to 
all cases where there are commonly used complex constraints that don't 
necessarily involve recursive constraints.

Specializing Generic-Only Protocols For Non-Generic Use

An additional feature that would prove to be very useful would be to make a 
constrained protocol alias be a non-generic-only protocol if the constraints of 
the alias declaration specify a same-type requirement for all its associated 
types, while defaulted associated types would also count.
Example:

protocol Consumer {
associatedtype Consumable
mutating func consume(_ consumable: Consumable) throws
}

var consumer0: Consumer // error: Consumer is only usable in a generic context

typealias CharacterConsumer = Consumer where  CharacterConsumer.Consumable == 
Character

var consumer1: CharacterConsumer // OK

The current workaround would be to declare a new protocol with protocol 
inheritance clauses and a where clause, but the major downside is that it 
introduces a completely new protocol that is not compatible with any context 
that expects the underlying protocols and their constraints.

Regards,
Gor Gyolchanyan.

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

[swift-evolution] Constrained Protocol Aliases

[Gor Gyolchanyan via swift-evolution]

Hello, Swift community!

I'd like to start a discussion about a possibility of constrained protocol 
aliases. The declaration would look like this:

typealias BinaryProtocol = RandomAccessCollection & MutablCollection & 
RangeReplaceableCollection where Binary.Index == Int, Binary.Element == Bool

The syntax and semantics of this declaration are exactly the same as an 
analogous associatedtype declaration inside a protocol.
In the example above, the type BinaryProtocol represents a logical array of 
bits and is a generic-only protocol that is usable in any context where an 
integer-indexed mutable range-replaceable random-access collection is expected.
Now, it can be used in a very concise and elegant way:

public protocol BinaryInitializable {
init(binary: Binary) where Binary: BinaryProtocol
}

which would otherwise look very verbose and inelegant:

public protocol BinaryInitializable {
init(binary: Binary) where Binary: RandomAccessCollection & 
MutablCollection & RangeReplaceableCollection, Binary.Index == Int, 
Binary.Element == Bool
}

Considering that smaller sets of constraints could be aliased to their own 
protocol and then composited into more complex aliases, this feature would 
dramatically improve readability and maintainability of code that uses complex 
constraints, that currently leads to arcane mess:

struct Mirror {
/// ...
init(_ subject: Subject, 
children: C, displayStyle: Mirror.DisplayStyle? = default, 
ancestorRepresentation: Mirror.AncestorRepresentation = default)
/// ...
}


/// A collection that is its own sub-sequence
typealias RecursivelySliceableCollection = Collection where
RecursivelySliceableCollection.SubSequence: Collection,
RecursivelySliceableCollection.SubSequence.Element == 
RecursivelySliceableCollection.Element
RecursivelySliceableCollection.SubSequence.Indices == 
RecursivelySliceableCollection.Indices,
RecursivelySliceableCollection.SubSequence.SubSequence == 
RecursivelySliceableCollection.SubSequence

/// A collection that is its own index collection
typealias RecursivelyIndexableCollection = Collection where
RecursivelyIndexableCollection.Indices == 
RecursivelySliceableCollection,
RecursivelyIndexableCollection.Indices.Index == 
RecursivelyIndexableCollection.Index,

struct Mirror {
/// ...
init(_ subject: 
Subject, children: C, displayStyle: Mirror.DisplayStyle? = default, 
ancestorRepresentation: Mirror.AncestorRepresentation = default)
/// ...
}

Even considering that the proposal SE-0157 
(https://github.com/apple/swift-evolution/blob/master/proposals/0157-recursive-protocol-constraints.md)
 is going to make this specific use case a non-issue, the principle applies to 
all cases where there are commonly used complex constraints that don't 
necessarily involve recursive constraints.

Specializing Generic-Only Protocols For Non-Generic Use

An additional feature that would prove to be very useful would be to make a 
constrained protocol alias be a non-generic-only protocol if the constraints of 
the alias declaration specify a same-type requirement for all its associated 
types, while defaulted associated types would also count.
Example:

protocol Consumer {
associatedtype Consumable
mutating func consume(_ consumable: Consumable) throws
}

var consumer0: Consumer // error: Consumer is only usable in a generic context

typealias CharacterConsumer = Consumer where  CharacterConsumer.Consumable == 
Character

var consumer1: CharacterConsumer // OK

The current workaround would be to declare a new protocol with protocol 
inheritance clauses and a where clause, but the major downside is that it 
introduces a completely new protocol that is not compatible with any context 
that expects the underlying protocols and their constraints.

Regards,
Gor Gyolchanyan.

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

Re: [swift-evolution] (core library) modern URL types

[Taylor Swift via swift-evolution]

I think that’s more a problem that lies in Foundation methods that take
URLs rather than the URLs themselves. A URL is a useful abstraction because
it contains a lot of common functionality between local file paths and
internet resources. For example, relative URI reference resolution. APIs
which take URLs as arguments should be responsible for ensuring that the
URL’s schema is a `file:`. The new URL type I’m writing actually makes the
scheme an enum with cases `.file`, `.http`, `.https`, `.ftp`, and `.data`
to ease checking this.

On Mon, Aug 21, 2017 at 2:23 AM, Félix Cloutier 
wrote:

> I'm not convinced that URLs are the appropriate abstraction for a file
> system path. For the record, I'm not a fan of existing Foundation methods
> that create objects from an URL. There is a useful and fundamental
> difference between a local path and a remote path, and conflating the two
> has been a security pain point in many languages and frameworks that allow
> it. Examples include remote file inclusion in PHP and malicious doctypes in
> XML. Windows also had its share of issues with UNC paths.
>
> Even when loading an arbitrary URL looks innocuous, many de-anonymizing
> hacks work by causing a program to access an URL controlled by an attacker
> to make it disclose the user's IP address or some other identifier.
>
> IMO, this justifies that there should be separate types to handle local
> and remote resources, so that at least developers have to be explicit about
> allowing remote resources. This makes a new URL type less necessary towards
> supporting file I/O.
>
> Félix
>
> Le 20 août 2017 à 21:37, Taylor Swift via swift-evolution <
> swift-evolution@swift.org> a écrit :
>
> Okay so a few days ago there was a discussion
> 
> about getting pure swift file system support into Foundation or another
> core library, and in my opinion, doing this requires a total overhaul of
> the `URL` type (which is currently little more than a wrapper for NSURL),
> so I’ve just started a pure Swift URL library project at <
> https://github.com/kelvin13/url>.
>
> The library’s parsing and validation core (~1K loc pure swift) is already
> in place and functional; the goal is to eventually support all of the
> Foundation URL functionality.
>
> The new `URL` type is implemented as a value type with utf8 storage backed
> by an array buffer. The URLs are just 56 bytes long each, so they should be
> able to fit into cache lines. (NSURL by comparison is over 128 bytes in
> size; it’s only saved by the fact that the thing is passed as a reference
> type.)
>
> As I said, this is still really early on and not a mature library at all
> but everyone is invited to observe, provide feedback, or contribute!
> ___
> 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] (core library) modern URL types

[Félix Cloutier via swift-evolution]

I'm not convinced that URLs are the appropriate abstraction for a file system 
path. For the record, I'm not a fan of existing Foundation methods that create 
objects from an URL. There is a useful and fundamental difference between a 
local path and a remote path, and conflating the two has been a security pain 
point in many languages and frameworks that allow it. Examples include remote 
file inclusion in PHP and malicious doctypes in XML. Windows also had its share 
of issues with UNC paths.

Even when loading an arbitrary URL looks innocuous, many de-anonymizing hacks 
work by causing a program to access an URL controlled by an attacker to make it 
disclose the user's IP address or some other identifier.

IMO, this justifies that there should be separate types to handle local and 
remote resources, so that at least developers have to be explicit about 
allowing remote resources. This makes a new URL type less necessary towards 
supporting file I/O.

Félix

> Le 20 août 2017 à 21:37, Taylor Swift via swift-evolution 
>  a écrit :
> 
> Okay so a few days ago there was a discussion 
> 
>  about getting pure swift file system support into Foundation or another core 
> library, and in my opinion, doing this requires a total overhaul of the `URL` 
> type (which is currently little more than a wrapper for NSURL), so I’ve just 
> started a pure Swift URL library project at  >.
> 
> The library’s parsing and validation core (~1K loc pure swift) is already in 
> place and functional; the goal is to eventually support all of the Foundation 
> URL functionality.
> 
> The new `URL` type is implemented as a value type with utf8 storage backed by 
> an array buffer. The URLs are just 56 bytes long each, so they should be able 
> to fit into cache lines. (NSURL by comparison is over 128 bytes in size; it’s 
> only saved by the fact that the thing is passed as a reference type.)
> 
> As I said, this is still really early on and not a mature library at all but 
> everyone is invited to observe, provide feedback, or contribute!
> ___
> 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] [Accepted] SE-0185 - Synthesizing Equatable and Hashable conformance

[Daryle Walker via swift-evolution]

> On Aug 19, 2017, at 3:29 PM, Haravikk via swift-evolution 
>  wrote:
> 
>> On 19 Aug 2017, at 19:46, Daryle Walker > > wrote:
>> 
>>> On Aug 19, 2017, at 7:06 AM, Haravikk via swift-evolution 
>>> > wrote:
>>> 
>>> Agreed. To be clear though; in spite of my pessimism this is a feature that 
>>> I do want, but I would rather not have it at all than have it implemented 
>>> in a way that hides bugs and sets a horrible precedent for the future.
>> 
>> I tried to make a split thread for this, but would you object to synthesized 
>> conformance if we had to explicitly add a command within the definition 
>> block to trigger the synthesis? If we add strong type-aliases, we could 
>> reuse the directive to copy an interface (method, inner type, property, or 
>> conformed-to protocol) from the underlying type to the current type for 
>> synthesis too. The only problem would be backward compatibility; once added, 
>> we would urge users to explicitly list “publish Equatable” for synthesis, 
>> but what about code that already uses the implicit version (since this 
>> feature will probably be released for at least one Swift version by the time 
>> strong type-aliases happen), do we force users to change their code?
> 
> I would rather no code at all use the implicit version; one of my points is 
> that it's not something that's easily changed after the fact, which is why it 
> needs to be done correctly now.
> 
> I'm open to any method that makes opting in to the synthesised conformance 
> explicit; I still think a specifically named protocol is the simplest, but 
> I'm not married to that as a solution; attributes, keywords etc. are all fine 
> too, whatever is the easiest way to opt-in to the behaviour explicitly 
> without ambiguity. I'm not 100% sure exactly what you mean by "add a command 
> within the definition block", or is an attribute/keyword what you meant?

The syntax to copy an interface from an underlying type to one of its strong 
type-aliases is a new directive within the definition block:

alter MyInt16: Int16, Hashable {
publish Equatable  // Automatically copies definitions from Int16 needed to 
conform to Equatable
var hashValue: Int { /*…*/ }  // A protocol can be completed with a mix of 
published and direct definitions
}

Since we would be introducing an explicit way to declare implementation of a 
conformance (the “publish” directive), we could reuse the directive for 
Equatable/Hashable/Encodable/Decodable definitions in non-strong-aliases and 
make the current implicit definitions obsolete. The problem then would be 
backwards compatibility; could we force users to go from implicit to explicit 
synthesized conformance?

The original point of publishing is to selectively control which parts of the 
underlying type’s interface get copied. Automatically synthesized conformance, 
if it stays after strong type-aliases are introduced, would screw with that 
(unless synthesized conformance is ignored for strong type-aliases; i.e. our 
conformance exception gets a counter exception).

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

Re: [swift-evolution] typed throws

[Brent Royal-Gordon via swift-evolution]

> On Aug 17, 2017, at 11:27 PM, John McCall via swift-evolution 
>  wrote:
> 
> The only practical merit of typed throws I have ever seen someone demonstrate 
> is that it would let them use contextual lookup in a throw or catch.


Let me take this in a slightly different direction.

I largely agree with you that most code shouldn't limit the types of errors it 
can throw. But I still want still want typed throws because I want to address a 
completely different problem: generics. Other than the useful but limited 
abilities of `rethrows`, there is currently no way to sensibly abstract over 
the error behavior of a piece of code. In particular, there's no way for a 
single protocol to support both throwing and non-throwing conformances.

One very straightforward and sensible way to handle this would be to support 
typed `throws` and make `Never` a subtype of `Error`; then you could handle 
error behavior abstraction using generic parameters, associated types, `where` 
clauses, and all those nice things we've already invented and taught people how 
to use. The other alternative is to invent several generics features from whole 
cloth purely to handle `throws`.

If we want to support errors in generics, designing typed `throws` and its 
interactions with the generics system seems a lot easier than designing a novel 
mechanism. Perhaps there are complications I'm not aware of—the thought of 
figuring out how generics are implemented fills me with dread—but naïvely, I 
would guess that the typed-throws-based solution will be easier to implement, 
too. And of course typed `throws` also helps the people who think they want to, 
you know, specify the type that a function throws. And it might help with the 
systems programming challenges we've talked about in this thread. So we can 
solve several different problems with a single feature, even if we think some 
of those problems are kind of niche.

I don't think any of the individual reasons to support typed `throws` are home 
runs, but I think this thread has produced some pretty solid ground balls and a 
couple of well-timed bunts, and that might be enough to get it across home 
plate.

-- 
Brent Royal-Gordon
Architechies

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