Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0176: Enforce Exclusive Access to Memory

[Gmail via swift-evolution]

> On 3 May 2017, at 22:06, John McCall via swift-evolution 
>  wrote:
> 
>> 
>> On May 3, 2017, at 3:56 PM, Florent Bruneau  
>> wrote:
>> 
>> 
>>> Le 3 mai 2017 à 17:23, John McCall  a écrit :
>>> 
 On May 3, 2017, at 3:42 AM, Florent Bruneau via swift-evolution 
  wrote:
> • What is your evaluation of the proposal?
 
 +1. However, it's unclear to me what the dynamic enforcement will look 
 like: will it trap, emit a warning, be catchable in a debugger, ... More 
 details on the developer-facing interface of the dynamic enforcement would 
 be nice.
>>> 
>>> It will trap.  That trap will of course be caught in the debugger, and 
>>> hopefully the debugger will be able to deliver a nice debugging experience 
>>> here.
>>> 
> • Is the problem being addressed significant enough to warrant a change 
> to Swift?
 
 The problem is significant, however I can see two significant downsides. 
 The first is the source-breaking nature of the proposal. Breaking source 
 is a problem by itself, but here I'm afraid the errors reporting won't be 
 easily understandable, because "exclusivity" is kind of an advanced 
 feature that won't be easily grasped by developers.
>>> 
>>> Our hope is that this will trigger very rarely and that we can make sure 
>>> that there's suitable documentation for what it means.
>> 
>> I'm worrying this may trigger more often on beginners' code because 
>> beginners will experiment and write incorrect code more often than 
>> experimented dev who have learned idiomatic code patterns.
> 
> That's generally a very important concern.  I do think it's less likely to 
> apply here because beginners are quite a bit less likely to be experimenting 
> with oddly-nested inout arguments, or inout arguments at all.
> 
> John.

I think it would be fairly important to get a nice and helpful error message if 
the exclusivity is violated, for developers of all skill levels to understand 
what’s happening and to know what to do about it. I don’t know if it’s 
something that’s worth pointing out specifically or not.

/ David

> 
>> 
 My second concern is the performance of the dynamic enforcement. How 
 confident are you that the performance hit of the enforcement will not 
 nullify the gain made by the enabling of more compile-time optimisations?
>>> 
>>> It's a performance trade-off where, unfortunately, the upsides and 
>>> downsides will be seen in very different code.  Dynamic enforcement will 
>>> kick in mostly for code that makes heavy use of mutable class properties, 
>>> e.g. traditional Cocoa programming.  We expect that the optimization 
>>> advantages will mostly be seen in code that makes heavy use of value types, 
>>> especially copy-on-write value types like the standard library's data 
>>> structures.  Of course, traditional Cocoa programming also does use a lot 
>>> of dictionaries and arrays, so it's possible that the advantages will 
>>> offset each other.
>>> 
>>> One direction we're exploring for dynamic enforcement is enabling it only 
>>> in certain builds by default (e.g. debug configurations).  Unlike array 
>>> bounds checks and integer overflows, exclusivity violations are generally 
>>> not data-dependent:  it's usually true that just executing the code in any 
>>> configuration will adequately test for dynamic exclusivity violations.  You 
>>> can get them with races, of course, but the dynamic enforcement mechanisms 
>>> we're looking at will probably not detect cross-thread violations anyway.  
>>> Of course, you can make a reasonable argument that not enabling dynamic 
>>> enforcement checks in production builds would contradict Swift's general 
>>> policy of "safe by default", so this is not a certain thing.  We would very 
>>> much like to hear swift-evolution's thoughts about this.
>> 
>> I would go for disabling the dynamic checks in productions. The rational is 
>> mostly the little gain compared to the performance overhead.
>> 
> • Does this proposal fit well with the feel and direction of Swift?
 
 Yes.
 
> • If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?
> • How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?
 
 Full read. BTW, there is a typo in the "Eliminating non-instantaneous 
 accesses?" section, _Int_appendABunchOfStuff => _Array_appendABunchOfStuff
>>> 
>>> Thank you, this has been fixed.
>>> 
>>> John.
>>> 
 
> More information about the Swift evolution process is available at:
> 
> https://github.com/apple/swift-evolution/blob/master/process.md
> 
> 
> Thanks,
> Ben Cohen
> Review Manager
> 
> ___
> swift-evolution-announce 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0176: Enforce Exclusive Access to Memory

[John McCall via swift-evolution]

> On May 3, 2017, at 3:56 PM, Florent Bruneau  
> wrote:
> 
> 
>> Le 3 mai 2017 à 17:23, John McCall  a écrit :
>> 
>>> On May 3, 2017, at 3:42 AM, Florent Bruneau via swift-evolution 
>>>  wrote:
 • What is your evaluation of the proposal?
>>> 
>>> +1. However, it's unclear to me what the dynamic enforcement will look 
>>> like: will it trap, emit a warning, be catchable in a debugger, ... More 
>>> details on the developer-facing interface of the dynamic enforcement would 
>>> be nice.
>> 
>> It will trap.  That trap will of course be caught in the debugger, and 
>> hopefully the debugger will be able to deliver a nice debugging experience 
>> here.
>> 
 • Is the problem being addressed significant enough to warrant a change to 
 Swift?
>>> 
>>> The problem is significant, however I can see two significant downsides. 
>>> The first is the source-breaking nature of the proposal. Breaking source is 
>>> a problem by itself, but here I'm afraid the errors reporting won't be 
>>> easily understandable, because "exclusivity" is kind of an advanced feature 
>>> that won't be easily grasped by developers.
>> 
>> Our hope is that this will trigger very rarely and that we can make sure 
>> that there's suitable documentation for what it means.
> 
> I'm worrying this may trigger more often on beginners' code because beginners 
> will experiment and write incorrect code more often than experimented dev who 
> have learned idiomatic code patterns.

That's generally a very important concern.  I do think it's less likely to 
apply here because beginners are quite a bit less likely to be experimenting 
with oddly-nested inout arguments, or inout arguments at all.

John.

> 
>>> My second concern is the performance of the dynamic enforcement. How 
>>> confident are you that the performance hit of the enforcement will not 
>>> nullify the gain made by the enabling of more compile-time optimisations?
>> 
>> It's a performance trade-off where, unfortunately, the upsides and downsides 
>> will be seen in very different code.  Dynamic enforcement will kick in 
>> mostly for code that makes heavy use of mutable class properties, e.g. 
>> traditional Cocoa programming.  We expect that the optimization advantages 
>> will mostly be seen in code that makes heavy use of value types, especially 
>> copy-on-write value types like the standard library's data structures.  Of 
>> course, traditional Cocoa programming also does use a lot of dictionaries 
>> and arrays, so it's possible that the advantages will offset each other.
>> 
>> One direction we're exploring for dynamic enforcement is enabling it only in 
>> certain builds by default (e.g. debug configurations).  Unlike array bounds 
>> checks and integer overflows, exclusivity violations are generally not 
>> data-dependent:  it's usually true that just executing the code in any 
>> configuration will adequately test for dynamic exclusivity violations.  You 
>> can get them with races, of course, but the dynamic enforcement mechanisms 
>> we're looking at will probably not detect cross-thread violations anyway.  
>> Of course, you can make a reasonable argument that not enabling dynamic 
>> enforcement checks in production builds would contradict Swift's general 
>> policy of "safe by default", so this is not a certain thing.  We would very 
>> much like to hear swift-evolution's thoughts about this.
> 
> I would go for disabling the dynamic checks in productions. The rational is 
> mostly the little gain compared to the performance overhead.
> 
 • Does this proposal fit well with the feel and direction of Swift?
>>> 
>>> Yes.
>>> 
 • If you have used other languages or libraries with a similar feature, 
 how do you feel that this proposal compares to those?
 • How much effort did you put into your review? A glance, a quick reading, 
 or an in-depth study?
>>> 
>>> Full read. BTW, there is a typo in the "Eliminating non-instantaneous 
>>> accesses?" section, _Int_appendABunchOfStuff => _Array_appendABunchOfStuff
>> 
>> Thank you, this has been fixed.
>> 
>> John.
>> 
>>> 
 More information about the Swift evolution process is available at:
 
 https://github.com/apple/swift-evolution/blob/master/process.md
 
 
 Thanks,
 Ben Cohen
 Review Manager
 
 ___
 swift-evolution-announce mailing list
 swift-evolution-annou...@swift.org
 https://lists.swift.org/mailman/listinfo/swift-evolution-announce
>>> 
>>> -- 
>>> Florent Bruneau
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
> 
> -- 
> Florent Bruneau
> 

___
swift-evolution mailing list
swift-evolution@swift.org

Re: [swift-evolution] Replace throws with Result

[Douglas Gregor via swift-evolution]

> On May 3, 2017, at 3:31 AM, Jaden Geller via swift-evolution 
>  wrote:
> 
> To be frank, there’s no way this is happening. The rationale for Swift’s 
> error handling is documented 
> , and this 
> system was designed and implemented *after* optionals already existed in the 
> language. I don’t think there’s any evidence that this was a horrible 
> decision, especially one that requires a *majorly* source-breaking change to 
> remove.

As a core team member, let me amplify this response a bit: the current 
error-handling system will not be going away, for the reasons Jaden has stated 
above.

Maybe we will grow typed throws at some point; maybe Result will get added to 
the standard library with some nice affordances to map between throwing and 
Result-producing types; but we’re well beyond the point where we can rip out 
major features that have been generally well-received.

- Doug

> – Jaden
> 
>> On May 3, 2017, at 3:06 AM, Jose Manuel Sánchez Peñarroja via 
>> swift-evolution > > wrote:
>> 
>> There is currently a discussion open about throws, but it seems that the 
>> idea would be to add optionals to throws. In my opinion it would be much 
>> better to just get rid of all the throw error system.
>> 
>> I think an *Result* type would provide much better error handling 
>> than the current solution:
>> 
>> - It would work just like Optional. We could use ?, ??, map, all those 
>> concepts that are already in use. A Result would basically be like a missing 
>> value with an error attached. *mapError* could also be added to transform 
>> error types to the appropriate value. 
>> 
>> - We would have a specific error type. Right now throws just returns an 
>> *Error*, which is basically a glorified *Any*. Anything can go in there, and 
>> it's really hard (or impossible) to know if we are dealing with all the 
>> possible options. a Result type would enforce a specific error, so we would 
>> gain type safety and we could be sure we are dealing with all the cases.
>> 
>> - It would simplify everything. We could get rid of *try*, *try?*, *throws*, 
>> *rethrows*, *do … catch*.
>> 
>> - It could be used asynchronously by just passing the *Result* value. Right 
>> now there is a different mechanism for handling async and sync calls. The 
>> sync calls have all the *throws*, *rethrows*, must be taken care with *try* 
>> and *do … catch*, while in a callback you just send the error.
>> 
>> ___
>> 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] [swift-evolution-announce] [Review] SE-0176: Enforce Exclusive Access to Memory

[Florent Bruneau via swift-evolution]

> Le 3 mai 2017 à 17:23, John McCall  a écrit :
> 
>> On May 3, 2017, at 3:42 AM, Florent Bruneau via swift-evolution 
>>  wrote:
>>> • What is your evaluation of the proposal?
>> 
>> +1. However, it's unclear to me what the dynamic enforcement will look like: 
>> will it trap, emit a warning, be catchable in a debugger, ... More details 
>> on the developer-facing interface of the dynamic enforcement would be nice.
> 
> It will trap.  That trap will of course be caught in the debugger, and 
> hopefully the debugger will be able to deliver a nice debugging experience 
> here.
> 
>>> • Is the problem being addressed significant enough to warrant a change to 
>>> Swift?
>> 
>> The problem is significant, however I can see two significant downsides. The 
>> first is the source-breaking nature of the proposal. Breaking source is a 
>> problem by itself, but here I'm afraid the errors reporting won't be easily 
>> understandable, because "exclusivity" is kind of an advanced feature that 
>> won't be easily grasped by developers.
> 
> Our hope is that this will trigger very rarely and that we can make sure that 
> there's suitable documentation for what it means.

I'm worrying this may trigger more often on beginners' code because beginners 
will experiment and write incorrect code more often than experimented dev who 
have learned idiomatic code patterns.

>> My second concern is the performance of the dynamic enforcement. How 
>> confident are you that the performance hit of the enforcement will not 
>> nullify the gain made by the enabling of more compile-time optimisations?
> 
> It's a performance trade-off where, unfortunately, the upsides and downsides 
> will be seen in very different code.  Dynamic enforcement will kick in mostly 
> for code that makes heavy use of mutable class properties, e.g. traditional 
> Cocoa programming.  We expect that the optimization advantages will mostly be 
> seen in code that makes heavy use of value types, especially copy-on-write 
> value types like the standard library's data structures.  Of course, 
> traditional Cocoa programming also does use a lot of dictionaries and arrays, 
> so it's possible that the advantages will offset each other.
> 
> One direction we're exploring for dynamic enforcement is enabling it only in 
> certain builds by default (e.g. debug configurations).  Unlike array bounds 
> checks and integer overflows, exclusivity violations are generally not 
> data-dependent:  it's usually true that just executing the code in any 
> configuration will adequately test for dynamic exclusivity violations.  You 
> can get them with races, of course, but the dynamic enforcement mechanisms 
> we're looking at will probably not detect cross-thread violations anyway.  Of 
> course, you can make a reasonable argument that not enabling dynamic 
> enforcement checks in production builds would contradict Swift's general 
> policy of "safe by default", so this is not a certain thing.  We would very 
> much like to hear swift-evolution's thoughts about this.

I would go for disabling the dynamic checks in productions. The rational is 
mostly the little gain compared to the performance overhead.

>>> • Does this proposal fit well with the feel and direction of Swift?
>> 
>> Yes.
>> 
>>> • If you have used other languages or libraries with a similar feature, how 
>>> do you feel that this proposal compares to those?
>>> • How much effort did you put into your review? A glance, a quick reading, 
>>> or an in-depth study?
>> 
>> Full read. BTW, there is a typo in the "Eliminating non-instantaneous 
>> accesses?" section, _Int_appendABunchOfStuff => _Array_appendABunchOfStuff
> 
> Thank you, this has been fixed.
> 
> John.
> 
>> 
>>> More information about the Swift evolution process is available at:
>>> 
>>> https://github.com/apple/swift-evolution/blob/master/process.md
>>> 
>>> 
>>> Thanks,
>>> Ben Cohen
>>> Review Manager
>>> 
>>> ___
>>> swift-evolution-announce mailing list
>>> swift-evolution-annou...@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution-announce
>> 
>> -- 
>> Florent Bruneau
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 

-- 
Florent Bruneau

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0176: Enforce Exclusive Access to Memory

[John McCall via swift-evolution]

> On May 3, 2017, at 12:05 AM, Paul Cantrell via swift-evolution 
>  wrote:
> I like the spirit of the proposal. It leaves me a bit uneasy because the 
> practical ramifications are difficult to fully anticipate. Here follow some 
> questions / concerns for the proposal authors.
> 
> (Apologies if these were answered somewhere deep in a discussion thread; it’s 
> the end of the semester and I’ve not kept up with the list.)
> 
> • • •
> 
> First, have you done any systematic exploration of how impactful this rule 
> is? The proposal states in several places that it hopes/expects violations 
> will be rare, but is that empirical or speculative?

Initially, it was just well-informed speculation, but we're gathering more and 
more evidence that it's borne out in practice.  Even large code bases have at 
most a couple of static violations, and that's before we've implemented some of 
the refinements around struct properties.

> I tried playing around with the implications, thought I’d found a problematic 
> example by writing an in-place Array.shuffle() method — and then was pleased 
> to realize that the proposal already covered my example with swapAt(). In 
> half an hour, I couldn’t come up with something the proposal disallows that 
> it clearly should allow.
> 
> Still, the implications of a rule like this are difficult to anticipate. It 
> would be interesting to know how many errors it flags in the Swift source 
> compatibility suite, for example. Is that something we could do before going 
> all-in on a fully robust implementation?

That is definitely an experiment we're running.  Unfortunately, we can only 
test for static violations with this, because checking for dynamic violations 
requires execution tests.

> Second, what are the performance implications of dynamic exclusivity 
> enforcement? Introducing overhead to something as basic as variable access 
> seems dicey. Will it kill “C-like” performance for object properties? For 
> closure vars?

It will definitely add overhead to class member access, global variable access, 
and closure access.  Optimization may be able to reduce those overheads; for 
example, we can look at every use of a private property and often quickly prove 
that it is impossible to have an access violation on it.  (That can be extended 
to internal properties in WMO builds; it is impossible for open properties.)

> Will “accesses underway” flags add to the memory footprint of every object & 
> every closure?

We were initially considering the use of "access underway" flags, but 
eventually decided that it made more sense to use a separate global tracking 
system.  Currently this table is thread-local, and we expect it to be small 
enough at any given time that a linear scan will perform acceptably.  (In your 
experiments, you've no doubt observed that it takes some effort to actually get 
an access to be non-instantaneous.)

> You write that your “hope is that…dynamic access-tracking [will be] cheap 
> enough to enable by default;” have you proved this out with a prototype 
> implementation yet?

This is underway.

> Or maybe this check is disabled in optimized builds, and I’m fussing over 
> nothing?

That is something we're considering.  To quote from a different reply (that I 
just made, you haven't missed anything):

One direction we're exploring for dynamic enforcement is enabling it only in 
certain builds by default (e.g. debug configurations).  Unlike array bounds 
checks and integer overflows, exclusivity violations are generally not 
data-dependent:  it's usually true that just executing the code in any 
configuration will adequately test for dynamic exclusivity violations.  You can 
get them with races, of course, but the dynamic enforcement mechanisms we're 
looking at will probably not detect cross-thread violations anyway.  Of course, 
you can make a reasonable argument that not enabling dynamic enforcement checks 
in production builds would contradict Swift's general policy of "safe by 
default", so this is not a certain thing.  We would very much like to hear 
swift-evolution's thoughts about this.

John.

> 
> Cheers,
> 
> Paul
> 
> 
>> On May 2, 2017, at 3:07 PM, Ben Cohen > > wrote:
>> 
>> Hello Swift community,
>> 
>> The review of SE-0176: "Enforce Exclusive Access to Memory" begins now and 
>> runs through May 8, 2017.
>> 
>> The proposal is available here:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0176-enforce-exclusive-access-to-memory.md
>>  
>> 
>> Reviews are an important part of the Swift evolution process. All reviews 
>> should be sent to the swift-evolution mailing list at:
>> 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
>> or, if you would like to keep 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0176: Enforce Exclusive Access to Memory

[John McCall via swift-evolution]

> On May 3, 2017, at 3:42 AM, Florent Bruneau via swift-evolution 
>  wrote:
>> • What is your evaluation of the proposal?
> 
> +1. However, it's unclear to me what the dynamic enforcement will look like: 
> will it trap, emit a warning, be catchable in a debugger, ... More details on 
> the developer-facing interface of the dynamic enforcement would be nice.

It will trap.  That trap will of course be caught in the debugger, and 
hopefully the debugger will be able to deliver a nice debugging experience here.

>> • Is the problem being addressed significant enough to warrant a change to 
>> Swift?
> 
> The problem is significant, however I can see two significant downsides. The 
> first is the source-breaking nature of the proposal. Breaking source is a 
> problem by itself, but here I'm afraid the errors reporting won't be easily 
> understandable, because "exclusivity" is kind of an advanced feature that 
> won't be easily grasped by developers.

Our hope is that this will trigger very rarely and that we can make sure that 
there's suitable documentation for what it means.

> My second concern is the performance of the dynamic enforcement. How 
> confident are you that the performance hit of the enforcement will not 
> nullify the gain made by the enabling of more compile-time optimisations?

It's a performance trade-off where, unfortunately, the upsides and downsides 
will be seen in very different code.  Dynamic enforcement will kick in mostly 
for code that makes heavy use of mutable class properties, e.g. traditional 
Cocoa programming.  We expect that the optimization advantages will mostly be 
seen in code that makes heavy use of value types, especially copy-on-write 
value types like the standard library's data structures.  Of course, 
traditional Cocoa programming also does use a lot of dictionaries and arrays, 
so it's possible that the advantages will offset each other.

One direction we're exploring for dynamic enforcement is enabling it only in 
certain builds by default (e.g. debug configurations).  Unlike array bounds 
checks and integer overflows, exclusivity violations are generally not 
data-dependent:  it's usually true that just executing the code in any 
configuration will adequately test for dynamic exclusivity violations.  You can 
get them with races, of course, but the dynamic enforcement mechanisms we're 
looking at will probably not detect cross-thread violations anyway.  Of course, 
you can make a reasonable argument that not enabling dynamic enforcement checks 
in production builds would contradict Swift's general policy of "safe by 
default", so this is not a certain thing.  We would very much like to hear 
swift-evolution's thoughts about this.

>> • Does this proposal fit well with the feel and direction of Swift?
> 
> Yes.
> 
>> • If you have used other languages or libraries with a similar feature, how 
>> do you feel that this proposal compares to those?
>> • How much effort did you put into your review? A glance, a quick reading, 
>> or an in-depth study?
> 
> Full read. BTW, there is a typo in the "Eliminating non-instantaneous 
> accesses?" section, _Int_appendABunchOfStuff => _Array_appendABunchOfStuff

Thank you, this has been fixed.

John.

> 
>> More information about the Swift evolution process is available at:
>> 
>> https://github.com/apple/swift-evolution/blob/master/process.md
>> 
>> 
>> Thanks,
>> Ben Cohen
>> Review Manager
>> 
>> ___
>> swift-evolution-announce mailing list
>> swift-evolution-annou...@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution-announce
> 
> -- 
> Florent Bruneau
> 
> ___
> 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] Replace throws with Result

[Jean-Daniel via swift-evolution]

> Le 3 mai 2017 à 16:12, Jose Manuel Sánchez Peñarroja via swift-evolution 
>  a écrit :
> 
>> At what cost ? Today, the error handling is barely zero-cost thanks to the 
>> swift calling convention. Having a generic return type will not only prevent 
>> calling convention optimization, but it will also add cost to all the return 
>> types as they will have to embed a discriminator.
> 
> 
> I guess I’m thinking more in terms of usage and elegancy than performance. I 
> don’t know which implications this might have.
> 
>> Is it really a benefit ? Working with functions that returns an optional 
>> (and can throw) will be far more complex as we will have to deal with 2 
>> levels of unwrapping, one for the error, and a second one for the returned 
>> value.
> 
> 
> I think it would make very little sense to return a Result Optional>. Just like it doesn’t make much sense to return a 
> Optional. It could still happen at some point, but the optional 
> could be upgraded to Result and then everything flattened.

Why that ? How I am supposed to fetch a nullable value from a database for 
instance and make a distinction between the value exists but is null and there 
where an error while accessing the data ? 

How should I represent such API if Result is not the 
way to go ?

>> All error handling pattern have a intrinsic complexity. I don’t see how 
>> having to call mapError after each call will make thing easier.
> 
> In my opinion it’s easier to learn how optional works, and then use that 
> knowledge for Result, instead of learning 2 different patterns for similar 
> things. Optional can be used for computations where the error is obvious 
> (like Array.first), and Result when more information is needed. Also, Result 
> is not something very original. There are already some implementations of 
> this for Swift, and it is widely used in Haskell (Either) and other languages 
> for dealing with errors.

Not a very convincing argument as Haskell is a niche language compare to the 
languages that use try/catch/throw like Java, C++, C#, …

> To be honest I never thought this would happen, as it involves a lot of 
> breaking changes, but I expected to have a little discussion to see how 
> feasible it would be in the long run.


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

Re: [swift-evolution] Replace throws with Result

[Jose Manuel Sánchez Peñarroja via swift-evolution]

> At what cost ? Today, the error handling is barely zero-cost thanks to the 
> swift calling convention. Having a generic return type will not only prevent 
> calling convention optimization, but it will also add cost to all the return 
> types as they will have to embed a discriminator.


I guess I’m thinking more in terms of usage and elegancy than performance. I 
don’t know which implications this might have.

> Is it really a benefit ? Working with functions that returns an optional (and 
> can throw) will be far more complex as we will have to deal with 2 levels of 
> unwrapping, one for the error, and a second one for the returned value.


I think it would make very little sense to return a Result. Just like it doesn’t make much sense to return a 
Optional. It could still happen at some point, but the optional 
could be upgraded to Result and then everything flattened.

> All error handling pattern have a intrinsic complexity. I don’t see how 
> having to call mapError after each call will make thing easier.

In my opinion it’s easier to learn how optional works, and then use that 
knowledge for Result, instead of learning 2 different patterns for similar 
things. Optional can be used for computations where the error is obvious (like 
Array.first), and Result when more information is needed. Also, Result is not 
something very original. There are already some implementations of this for 
Swift, and it is widely used in Haskell (Either) and other languages for 
dealing with errors.

To be honest I never thought this would happen, as it involves a lot of 
breaking changes, but I expected to have a little discussion to see how 
feasible it would be in the long run.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Replace throws with Result

[Jean-Daniel via swift-evolution]

> Le 3 mai 2017 à 12:06, Jose Manuel Sánchez Peñarroja via swift-evolution 
>  a écrit :
> 
> There is currently a discussion open about throws, but it seems that the idea 
> would be to add optionals to throws. In my opinion it would be much better to 
> just get rid of all the throw error system.
> 
> I think an *Result* type would provide much better error handling 
> than the current solution:
> 

At what cost ? Today, the error handling is barely zero-cost thanks to the 
swift calling convention. Having a generic return type will not only prevent 
calling convention optimization, but it will also add cost to all the return 
types as they will have to embed a discriminator.

> - It would work just like Optional. We could use ?, ??, map, all those 
> concepts that are already in use. A Result would basically be like a missing 
> value with an error attached. *mapError* could also be added to transform 
> error types to the appropriate value. 

Is it really a benefit ? Working with functions that returns an optional (and 
can throw) will be far more complex as we will have to deal with 2 levels of 
unwrapping, one for the error, and a second one for the returned value.

> - We would have a specific error type. Right now throws just returns an 
> *Error*, which is basically a glorified *Any*. Anything can go in there, and 
> it's really hard (or impossible) to know if we are dealing with all the 
> possible options. a Result type would enforce a specific error, so we would 
> gain type safety and we could be sure we are dealing with all the cases.

This issue can be resolved with typed throw. No need to break all existing code 
and rewrite the error handling for that.

> - It would simplify everything. We could get rid of *try*, *try?*, *throws*, 
> *rethrows*, *do … catch*.

All error handling pattern have a intrinsic complexity. I don’t see how having 
to call mapError after each call will make thing easier.

> - It could be used asynchronously by just passing the *Result* value. Right 
> now there is a different mechanism for handling async and sync calls. The 
> sync calls have all the *throws*, *rethrows*, must be taken care with *try* 
> and *do … catch*, while in a callback you just send the error.

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

Re: [swift-evolution] Proposal: Split extensions into implementing methods and adding static functions Was: [swift-evolution-announce] [Review] SE-0164: Remove final support in protocol extensions

[David Waite via swift-evolution]

> On May 3, 2017, at 2:09 AM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>> On May 3, 2017, at 12:25 AM, Xiaodi Wu via swift-evolution 
>> > wrote:
>> 
>> I definitely agree that it's a feature that _can_ be used unwisely, but the 
>> fact remains that it _is_ used pervasively in the standard library, and 
>> deliberately
> 
> 
> I'm not so sure that's true. Which standard library protocols intentionally 
> depend upon certain parts to not be overridable? Are they so pervasive that 
> we wouldn't prefer to just mark those members that need it with a `final` 
> keyword? If John McCall woke up tomorrow with some genius idea of how to make 
> extension methods overridable with zero overhead, would we choose to keep the 
> current design? 

Extension methods are not explicitly part of the protocol requirements, so 
having them overridable by default based on a type having a method or property 
with a matching signature is basically duck typing.

A hypothetical example, but if swift didn't define "filter(_)" as part of 
Sequence, it might mean that an extension adds filter with the predicate 
indicating that the value is included, while my custom sequence defined a 
filter method where true from the predicate means the value should be 'filtered 
out'. Both methods would wind up having identical signatures. Generic 
algorithms written under the concept that 'filter', added by an extension, is 
now part of the 'Sequence' contract, would be quite confused that sometimes the 
behavior of their algorithm reverses.

That method implementations which are not part of the protocol definition 
define functionality around use of a protocol rather than extending the 
protocol requirements can be confusing, but to me it has always seemed correct. 
To have those methods be part of the protocol requirements is changing the 
protocol requirements.

I tried pitching a proposal a few months ago which attempted not to change the 
rules but to have the code declare intent and compiler warn if the declared 
intent seemed wrong. I was surprised it got very little interest. Right now, we 
have an issue where overriding a class method gives you a nice error if you 
fat-finger part of the signature, but implementing a protocol with extensions 
providing default implementations does nothing (either when declaring the 
protocol extension or implementing the protocol within your type)

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

Re: [swift-evolution] Replace throws with Result

[Jaden Geller via swift-evolution]

To be frank, there’s no way this is happening. The rationale for Swift’s error 
handling is documented 
, and this 
system was designed and implemented *after* optionals already existed in the 
language. I don’t think there’s any evidence that this was a horrible decision, 
especially one that requires a *majorly* source-breaking change to remove.

– Jaden

> On May 3, 2017, at 3:06 AM, Jose Manuel Sánchez Peñarroja via swift-evolution 
>  wrote:
> 
> There is currently a discussion open about throws, but it seems that the idea 
> would be to add optionals to throws. In my opinion it would be much better to 
> just get rid of all the throw error system.
> 
> I think an *Result* type would provide much better error handling 
> than the current solution:
> 
> - It would work just like Optional. We could use ?, ??, map, all those 
> concepts that are already in use. A Result would basically be like a missing 
> value with an error attached. *mapError* could also be added to transform 
> error types to the appropriate value. 
> 
> - We would have a specific error type. Right now throws just returns an 
> *Error*, which is basically a glorified *Any*. Anything can go in there, and 
> it's really hard (or impossible) to know if we are dealing with all the 
> possible options. a Result type would enforce a specific error, so we would 
> gain type safety and we could be sure we are dealing with all the cases.
> 
> - It would simplify everything. We could get rid of *try*, *try?*, *throws*, 
> *rethrows*, *do … catch*.
> 
> - It could be used asynchronously by just passing the *Result* value. Right 
> now there is a different mechanism for handling async and sync calls. The 
> sync calls have all the *throws*, *rethrows*, must be taken care with *try* 
> and *do … catch*, while in a callback you just send the error.
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] Proposal: Split extensions into implementing methods and adding static functions Was: [swift-evolution-announce] [Review] SE-0164: Remove final support in protocol extensions

[Xiaodi Wu via swift-evolution]

I should add, the reason final is inapt in this situation is at least
twofold.

The first is, of course, that this makes it impossible to guarantee source
compatibility and offer additional functionality in a protocol extension,
since any such addition would break unknowable amounts of existing code.
Consider if we wanted to add a commonly requested convenience function to
Collection in the standard library. Since it is so commonly useful and
doesn't currently exist in the standard library, it is very likely that
numerous people have written their own extensions for one or more concrete
types (say, Array). It would therefore not be possible to add this to the
standard library as an extension on Collection unless (a) we pick a silly
name that we know no one would call this function, which is
counterintuitive, as ideally we want to pick an obvious name that everyone
would call this function; or (b) we make it a protocol requirement with a
default implementation, which is both not what it really is (conceptually,
it's not something that all things need to do in order to be a bona fide
collection, for which we can give just a placeholder default; rather, it's
a neat thing that all bona fide collections can do, and we are implementing
the specific neat thing and not a placeholder to be refined later) and it
would run into the second issue.

The second issue to do with why final is inapt relates to the fact that
protocols are not hierarchically inherited but are meant to be composable
without the problems of multiple inheritance. For instance, the following
is possible--and should be:

```
protocol P {
}

extension P {
func f() {
print("42")
}
}

protocol Q {
}

extension Q {
func f() {
print("43")
}
}

struct S : P, Q {
}

let s = S()

(s as P).f()
(s as Q).f()
```

If f were either final or a protocol requirement, barriers would arise due
to clashing definitions. Again, this has source compatibility implications.
It also places limits on the composability and evolution of protocols where
today there aren't any.


On Wed, May 3, 2017 at 04:00 Xiaodi Wu  wrote:

> Well, the revised integer protocols that were just approved do just that:
> some functions are defaults and others cannot be overridden. Smart shifts,
> for example, are deliberately not customization points. This is also the
> case for Equatable: you get to define ==, but != is not a protocol
> requirement and cannot be overridden. A very long list of algorithms on
> Sequence and Collection are also implemented in this way (contains,
> elementsEqual, enumerated, first, flatMap, lexicographicallyPrecedes, min,
> max, reduce, reversed, sorted...). So, at least equatables, numbers,
> sequences, and collections depend on this design--I'd call that pervasive.
> And these are just the protocols I've worked with in the last two days; I
> haven't even looked at the documentation for others.
>
> It serves a real purpose. As has been said before, protocols are not mere
> bags of syntax. However, the compiler cannot enforce arbitrary semantic
> requirements. This feature allows protocols to guarantee the semantics of
> particular members. It is how you can know with complete certainty while
> writing a generic algorithm that a == b implies !(a != b) for all equatable
> values. Conceptually, protocol extension methods are exactly what their
> name suggests: they are definitive implementations of generic algorithms
> that make use of the guarantees of a protocol; they are not placeholder
> implementations of a requirement that constitutes a part of the protocol
> itself. How else would you provide functionality that extends a protocol as
> you would a type?
>
> And no, we wouldn't prefer to just mark all of those members as "final".
> That was just settled in SE-0164; once upon a time, it was required to do
> so, but that was actually tried and backed out, and now the last vestiges
> of that legacy have literally just been slated for removal with community
> approval.
>
>
> On Wed, May 3, 2017 at 03:09 Brent Royal-Gordon 
> wrote:
>
>> On May 3, 2017, at 12:25 AM, Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> I definitely agree that it's a feature that _can_ be used unwisely, but
>> the fact remains that it _is_ used pervasively in the standard library, and
>> deliberately
>>
>>
>> I'm not so sure that's true. Which standard library protocols
>> intentionally depend upon certain parts to not be overridable? Are they so
>> pervasive that we wouldn't prefer to just mark those members that need it
>> with a `final` keyword? If John McCall woke up tomorrow with some genius
>> idea of how to make extension methods overridable with zero overhead, would
>> we choose to keep the current design?
>>
>> That's not to say the proposal at hand is a good idea, but I think you're
>> overselling the current design.
>>
>> --
>> Brent Royal-Gordon
>> Architechies
>>
>>

[swift-evolution] Replace throws with Result

[Jose Manuel Sánchez Peñarroja via swift-evolution]

There is currently a discussion open about throws, but it seems that the idea 
would be to add optionals to throws. In my opinion it would be much better to 
just get rid of all the throw error system.

I think an *Result* type would provide much better error handling 
than the current solution:

- It would work just like Optional. We could use ?, ??, map, all those concepts 
that are already in use. A Result would basically be like a missing value with 
an error attached. *mapError* could also be added to transform error types to 
the appropriate value. 

- We would have a specific error type. Right now throws just returns an 
*Error*, which is basically a glorified *Any*. Anything can go in there, and 
it's really hard (or impossible) to know if we are dealing with all the 
possible options. a Result type would enforce a specific error, so we would 
gain type safety and we could be sure we are dealing with all the cases.

- It would simplify everything. We could get rid of *try*, *try?*, *throws*, 
*rethrows*, *do … catch*.

- It could be used asynchronously by just passing the *Result* value. Right now 
there is a different mechanism for handling async and sync calls. The sync 
calls have all the *throws*, *rethrows*, must be taken care with *try* and *do 
… catch*, while in a callback you just send the error.

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0174: Change `filter` to return an associated type

[Anders Ha via swift-evolution]

> On 3 May 2017, at 5:32 PM, Anders Ha via swift-evolution 
>  wrote:
> 
> So a bit of correction: generic protocol had been dismissed in the Generic 
> Manifesto specifically for sequences and collections, because it would permit 
> multiple conformances of a certain type to the same protocol with different 
> types of elements, and it is considered wrong.
> 
> `Self` in a protocol refers not to the unbound generic type, but to the 
> specialized one, e.g. `Array` where T is bound, instead of `Array`. For 
> your code snippets to work, the compiler would need to explicitly 
> “unspecialize” the specialised `Self` and parameterise it with a different 
> type. This notion is called higher-kinded types.
> 
> https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#higher-kinded-types
> 
> For example, using the potential syntax in the manifesto:
> 
>extension RangeReplaceableCollection {
>func filter(_ isIncluded: (Element) -> Bool) -> Filtered 
> where Filtered ~= Self, Filtered.Element == Element
>func map(_ transform: (Element) -> Mapped.Element) -> Mapped 
> where Mapped ~= Self
>}
> 
> Let’s say `Self` is `Set`, the compiler would need to be instructed to 
> “unspecialize” it and parameterise it again, so that it still knows the 
> resulting collection statically. Then at this point, yes, it can be 
> statically dispatched.
> 
> But for now, higher-kinded types do not seem to be on the radar at all. So to 
> achieve the same result, there are only two options:
> 
> 1. Type-erased wrappers, e.g. `AnyCollection`, or generalised existential, 
> e.g. `Collection where .Element == T`. This means dynamic dispatch.
> 2. Associated type, i.e. the proposal.
> 
> Another important constraint you’ve missed is that only 
> `RangeReplaceableCollection` implies the collection can be explicitly 
> constructed. So a default of `[Element]` is necessary.

Perhaps I should rephrase this for clarity:

Another important constraint missed is that `Sequence` and derived protocols do 
not imply constructibility and manipulability. These capabilities belong to 
standalone protocols like `RangeReplaceableCollection` and  `SetAlgebra`.

So a default of `[Element]` for `Sequence.filter` is inevitable, even with we 
have higher-kinded types.

> 
> Regards
> Anders
> 
>> On 3 May 2017, at 4:57 PM, Howard Lovatt  wrote:
>> 
>> @Anders,
>> 
>> I think you can eliminate the dynamic dispatch for a struct. Using the 
>> generic parameterised syntax rather than the where clause syntax (because it 
>> is more compact and clearer):
>> 
>>protocol Sequence {
>>func filter(_ isIncluded: (T) -> Bool) -> Self // Note: returns 
>> Self
>>...
>>}
>>extension Sequence {
>>func filter(_ isIncluded: (T) -> Bool) -> Self { // Note: returns 
>> Self
>>var result = Self
>>for element in self {
>>if isIncluded(element) { result.append(element) }
>>}
>>return result
>>}
>>...
>>}
>>struct Set: Sequence { ... } // Inherits filter from extension
>> 
>> For struct `Set` `Self` is `Set` (obviously, that is what Self 
>> means), therefore the compiler can for both code and type checking purposes 
>> generate:
>> 
>>struct Set: Sequence {
>>func filter(_ isIncluded: (T) -> Bool) -> Set { // Note: returns 
>> Set
>>var result = Set
>>for element in self {
>>if isIncluded(element) { result.append(element) }
>>}
>>return result
>>}
>>...
>>}
>> 
>> This is an intermediate step for the compiler since `Set` is still generic, 
>> in `T`. When a specific `Set` is instantiated, e.g. `let s = Set`, the 
>> compiler can generate both for code and type checking purposes:
>> 
>>struct Set: Sequence {
>>func filter(_ isIncluded: (Int) -> Bool) -> Set { // Note: 
>> returns Set
>>var result = Set
>>for element in self {
>>if isIncluded(element) { result.append(element) }
>>}
>>return result
>>}
>>...
>>}
>> 
>> When you call `s.filter` there is no dynamic dispatch because `filter` is 
>> final within a struct and the compiler also knows that this version of 
>> `filter` returns a `Set` and therefore no dynamic dispatch on the 
>> returned value if in a chain of calls either.
>> 
>> Have I made a mistake in the above?
>> 
>>  -- Howard.
>> 
>> On 3 May 2017 at 17:27, Anders Ha  wrote:
>> Returning `Self` requires higher kinded type. Note that parameterized 
>> protocols are not the same as higher kinded types, since for the former 
>> generic protocol parameters are already bound at conformance of the static 
>> `Self` like associated types, while the later is about having a generic 
>> static `Self`.
>> 
>> IOW you cannot do `Self` statically without higher 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0174: Change `filter` to return an associated type

[Anders Ha via swift-evolution]

So a bit of correction: generic protocol had been dismissed in the Generic 
Manifesto specifically for sequences and collections, because it would permit 
multiple conformances of a certain type to the same protocol with different 
types of elements, and it is considered wrong.

`Self` in a protocol refers not to the unbound generic type, but to the 
specialized one, e.g. `Array` where T is bound, instead of `Array`. For your 
code snippets to work, the compiler would need to explicitly “unspecialize” the 
specialised `Self` and parameterise it with a different type. This notion is 
called higher-kinded types.

https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#higher-kinded-types

For example, using the potential syntax in the manifesto:

extension RangeReplaceableCollection {
func filter(_ isIncluded: (Element) -> Bool) -> Filtered 
where Filtered ~= Self, Filtered.Element == Element
func map(_ transform: (Element) -> Mapped.Element) -> Mapped 
where Mapped ~= Self
}
 
Let’s say `Self` is `Set`, the compiler would need to be instructed to 
“unspecialize” it and parameterise it again, so that it still knows the 
resulting collection statically. Then at this point, yes, it can be statically 
dispatched.

But for now, higher-kinded types do not seem to be on the radar at all. So to 
achieve the same result, there are only two options:

1. Type-erased wrappers, e.g. `AnyCollection`, or generalised existential, 
e.g. `Collection where .Element == T`. This means dynamic dispatch.
2. Associated type, i.e. the proposal.

Another important constraint you’ve missed is that only 
`RangeReplaceableCollection` implies the collection can be explicitly 
constructed. So a default of `[Element]` is necessary.

Regards
Anders

> On 3 May 2017, at 4:57 PM, Howard Lovatt  wrote:
> 
> @Anders,
> 
> I think you can eliminate the dynamic dispatch for a struct. Using the 
> generic parameterised syntax rather than the where clause syntax (because it 
> is more compact and clearer):
> 
> protocol Sequence {
> func filter(_ isIncluded: (T) -> Bool) -> Self // Note: returns 
> Self
> ...
> }
> extension Sequence {
> func filter(_ isIncluded: (T) -> Bool) -> Self { // Note: returns 
> Self
> var result = Self
> for element in self {
> if isIncluded(element) { result.append(element) }
> }
> return result
> }
> ...
> }
> struct Set: Sequence { ... } // Inherits filter from extension
> 
> For struct `Set` `Self` is `Set` (obviously, that is what Self 
> means), therefore the compiler can for both code and type checking purposes 
> generate:
> 
> struct Set: Sequence {
> func filter(_ isIncluded: (T) -> Bool) -> Set { // Note: returns 
> Set
> var result = Set
> for element in self {
> if isIncluded(element) { result.append(element) }
> }
> return result
> }
> ...
> }
> 
> This is an intermediate step for the compiler since `Set` is still generic, 
> in `T`. When a specific `Set` is instantiated, e.g. `let s = Set`, the 
> compiler can generate both for code and type checking purposes:
> 
> struct Set: Sequence {
> func filter(_ isIncluded: (Int) -> Bool) -> Set { // Note: 
> returns Set
> var result = Set
> for element in self {
> if isIncluded(element) { result.append(element) }
> }
> return result
> }
> ...
> }
> 
> When you call `s.filter` there is no dynamic dispatch because `filter` is 
> final within a struct and the compiler also knows that this version of 
> `filter` returns a `Set` and therefore no dynamic dispatch on the 
> returned value if in a chain of calls either.
> 
> Have I made a mistake in the above?
> 
>   -- Howard.
> 
> On 3 May 2017 at 17:27, Anders Ha  wrote:
> Returning `Self` requires higher kinded type. Note that parameterized 
> protocols are not the same as higher kinded types, since for the former 
> generic protocol parameters are already bound at conformance of the static 
> `Self` like associated types, while the later is about having a generic 
> static `Self`.
> 
> IOW you cannot do `Self` statically without higher kinded type. The best 
> you can get is generalized existential, e.g. `filter` returning a `Collection 
> where .Element == T` or `Collection` if protocols can be parameterized.
> 
> The compiler cannot eliminate virtual dispatching for existentials, because 
> this is what existential is by definition — knowing how to manipulate it at 
> static time, but not the type which varies at runtime. All non-class 
> existentials are dispatched through their associated protocol witness tables.
> 
> Regards
> Anders
> 
> On 3 May 2017, at 09:05, Howard Lovatt  wrote:
> 
>> My 

Re: [swift-evolution] Proposal: Split extensions into implementing methods and adding static functions Was: [swift-evolution-announce] [Review] SE-0164: Remove final support in protocol extensions

[Xiaodi Wu via swift-evolution]

Well, the revised integer protocols that were just approved do just that:
some functions are defaults and others cannot be overridden. Smart shifts,
for example, are deliberately not customization points. This is also the
case for Equatable: you get to define ==, but != is not a protocol
requirement and cannot be overridden. A very long list of algorithms on
Sequence and Collection are also implemented in this way (contains,
elementsEqual, enumerated, first, flatMap, lexicographicallyPrecedes, min,
max, reduce, reversed, sorted...). So, at least equatables, numbers,
sequences, and collections depend on this design--I'd call that pervasive.
And these are just the protocols I've worked with in the last two days; I
haven't even looked at the documentation for others.

It serves a real purpose. As has been said before, protocols are not mere
bags of syntax. However, the compiler cannot enforce arbitrary semantic
requirements. This feature allows protocols to guarantee the semantics of
particular members. It is how you can know with complete certainty while
writing a generic algorithm that a == b implies !(a != b) for all equatable
values. Conceptually, protocol extension methods are exactly what their
name suggests: they are definitive implementations of generic algorithms
that make use of the guarantees of a protocol; they are not placeholder
implementations of a requirement that constitutes a part of the protocol
itself. How else would you provide functionality that extends a protocol as
you would a type?

And no, we wouldn't prefer to just mark all of those members as "final".
That was just settled in SE-0164; once upon a time, it was required to do
so, but that was actually tried and backed out, and now the last vestiges
of that legacy have literally just been slated for removal with community
approval.


On Wed, May 3, 2017 at 03:09 Brent Royal-Gordon 
wrote:

> On May 3, 2017, at 12:25 AM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I definitely agree that it's a feature that _can_ be used unwisely, but
> the fact remains that it _is_ used pervasively in the standard library, and
> deliberately
>
>
> I'm not so sure that's true. Which standard library protocols
> intentionally depend upon certain parts to not be overridable? Are they so
> pervasive that we wouldn't prefer to just mark those members that need it
> with a `final` keyword? If John McCall woke up tomorrow with some genius
> idea of how to make extension methods overridable with zero overhead, would
> we choose to keep the current design?
>
> That's not to say the proposal at hand is a good idea, but I think you're
> overselling the current design.
>
> --
> Brent Royal-Gordon
> Architechies
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0174: Change `filter` to return an associated type

[Howard Lovatt via swift-evolution]

@Anders,

I think you can eliminate the dynamic dispatch for a struct. Using the
generic parameterised syntax rather than the where clause syntax (because
it is more compact and clearer):

protocol Sequence {
func filter(_ isIncluded: (T) -> Bool) -> Self // Note: returns
Self
...
}
extension Sequence {
func filter(_ isIncluded: (T) -> Bool) -> Self { // Note:
returns Self
var result = Self
for element in self {
if isIncluded(element) { result.append(element) }
}
return result
}
...
}
struct Set: Sequence { ... } // Inherits filter from extension

For struct `Set` `Self` is `Set` (obviously, that is what Self
means), therefore the compiler can for both code and type checking purposes
generate:

struct Set: Sequence {
func filter(_ isIncluded: (T) -> Bool) -> Set { // Note: returns
Set
var result = Set
for element in self {
if isIncluded(element) { result.append(element) }
}
return result
}
...
}

This is an intermediate step for the compiler since `Set` is still generic,
in `T`. When a specific `Set` is instantiated, e.g. `let s = Set`, the
compiler can generate both for code and type checking purposes:

struct Set: Sequence {
func filter(_ isIncluded: (Int) -> Bool) -> Set { // Note:
returns Set
var result = Set
for element in self {
if isIncluded(element) { result.append(element) }
}
return result
}
...
}

When you call `s.filter` there is no dynamic dispatch because `filter` is
final within a struct and the compiler also knows that this version of
`filter` returns a `Set` and therefore no dynamic dispatch on the
returned value if in a chain of calls either.

Have I made a mistake in the above?

  -- Howard.

On 3 May 2017 at 17:27, Anders Ha  wrote:

> Returning `Self` requires higher kinded type. Note that parameterized
> protocols are not the same as higher kinded types, since for the former
> generic protocol parameters are already bound at conformance of the static
> `Self` like associated types, while the later is about having a generic
> static `Self`.
>
> IOW you cannot do `Self` statically without higher kinded type. The
> best you can get is generalized existential, e.g. `filter` returning a 
> `Collection
> where .Element == T` or `Collection` if protocols can be parameterized.
>
> The compiler cannot eliminate virtual dispatching for existentials,
> because this is what existential is by definition — knowing how to
> manipulate it at static time, but not the type which varies at runtime. All
> non-class existentials are dispatched through their associated protocol
> witness tables.
>
> Regards
> Anders
>
> On 3 May 2017, at 09:05, Howard Lovatt  wrote:
>
> My experience with languages that have generalised existential is that
> they are superior in many circumstances; not just for collections, e.g. I
> gave the example of the comparison protocol.
>
> I don't think methods called on a returned generalised existential have
> to be called via a Vtable. If the return type is Self then the compiler
> can eliminate the Vtable for selfs that are value types. For selfs that are
> classes it would still have to use a Vtable though, because classes always
> use Vtables! In most cases the return type will be Self and in most
> cases the Self will be a value type, so I would argue that in most cases a
> Vtable won't be used.
>
> -- Howard.
>
> On 2 May 2017, at 8:57 pm, Anders Ha  wrote:
>
> I would like to add that generalized existential is not really a better
> solution than letting the collection optionally and statically supply one.
> It consequentially forces all calls to the filtered collections
> virtual/dynamic.
>
> Higher kinded type would ideally help, but we all know it is not coming
> anytime soon, or perhaps ever.
>
> Regards
> Anders
>
> On 2 May 2017, at 08:41, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Howard, this is also mentioned in the generics manifesto under "Opening
> existentials," and it's received plentiful discussion and will surely
> receive more as these issues become addressed in future proposals. Let's
> not divert the conversation here about map and filter.
> On Mon, May 1, 2017 at 19:36 Howard Lovatt 
> wrote:
>
>> Yes, I know the change I suggested involves making generalised
>> existentials. I am suggesting not making *any* changes until such effort
>> is available. I understand that this would be after Swift 4. I think the
>> wait would be worthwhile.
>>
>> As an aside: Currently one of the big issues with generalised
>> existentials in Swift is with Self (which you can think of as a form of
>> generic argument). Currently:
>>
>> protocol 

Re: [swift-evolution] Proposal: Split extensions into implementing methods and adding static functions Was: [swift-evolution-announce] [Review] SE-0164: Remove final support in protocol extensions

[Howard Lovatt via swift-evolution]

@Brent,

What aspects of the current proposal do you have reservations about?

  -- Howard.

On 3 May 2017 at 18:09, Brent Royal-Gordon  wrote:

> On May 3, 2017, at 12:25 AM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I definitely agree that it's a feature that _can_ be used unwisely, but
> the fact remains that it _is_ used pervasively in the standard library, and
> deliberately
>
>
> I'm not so sure that's true. Which standard library protocols
> intentionally depend upon certain parts to not be overridable? Are they so
> pervasive that we wouldn't prefer to just mark those members that need it
> with a `final` keyword? If John McCall woke up tomorrow with some genius
> idea of how to make extension methods overridable with zero overhead, would
> we choose to keep the current design?
>
> That's not to say the proposal at hand is a good idea, but I think you're
> overselling the current design.
>
> --
> Brent Royal-Gordon
> Architechies
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Proposal: Split extensions into implementing methods and adding static functions Was: [swift-evolution-announce] [Review] SE-0164: Remove final support in protocol extensions

[Brent Royal-Gordon via swift-evolution]

> On May 3, 2017, at 12:25 AM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> I definitely agree that it's a feature that _can_ be used unwisely, but the 
> fact remains that it _is_ used pervasively in the standard library, and 
> deliberately


I'm not so sure that's true. Which standard library protocols intentionally 
depend upon certain parts to not be overridable? Are they so pervasive that we 
wouldn't prefer to just mark those members that need it with a `final` keyword? 
If John McCall woke up tomorrow with some genius idea of how to make extension 
methods overridable with zero overhead, would we choose to keep the current 
design? 

That's not to say the proposal at hand is a good idea, but I think you're 
overselling the current design.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0176: Enforce Exclusive Access to Memory

[Florent Bruneau via swift-evolution]

> • What is your evaluation of the proposal?

+1. However, it's unclear to me what the dynamic enforcement will look like: 
will it trap, emit a warning, be catchable in a debugger, ... More details on 
the developer-facing interface of the dynamic enforcement would be nice.

> • Is the problem being addressed significant enough to warrant a change to 
> Swift?

The problem is significant, however I can see two significant downsides. The 
first is the source-breaking nature of the proposal. Breaking source is a 
problem by itself, but here I'm afraid the errors reporting won't be easily 
understandable, because "exclusivity" is kind of an advanced feature that won't 
be easily grasped by developers.

My second concern is the performance of the dynamic enforcement. How confident 
are you that the performance hit of the enforcement will not nullify the gain 
made by the enabling of more compile-time optimisations?

> • Does this proposal fit well with the feel and direction of Swift?

Yes.

> • If you have used other languages or libraries with a similar feature, how 
> do you feel that this proposal compares to those?
> • How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?

Full read. BTW, there is a typo in the "Eliminating non-instantaneous 
accesses?" section, _Int_appendABunchOfStuff => _Array_appendABunchOfStuff

> More information about the Swift evolution process is available at:
> 
> https://github.com/apple/swift-evolution/blob/master/process.md
> 
> 
> Thanks,
> Ben Cohen
> Review Manager
> 
> ___
> swift-evolution-announce mailing list
> swift-evolution-annou...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution-announce

-- 
Florent Bruneau

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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0174: Change `filter` to return an associated type

[Anders Ha via swift-evolution]

Returning `Self` requires higher kinded type. Note that parameterized 
protocols are not the same as higher kinded types, since for the former generic 
protocol parameters are already bound at conformance of the static `Self` like 
associated types, while the later is about having a generic static `Self`.

IOW you cannot do `Self` statically without higher kinded type. The best you 
can get is generalized existential, e.g. `filter` returning a `Collection where 
.Element == T` or `Collection` if protocols can be parameterized.

The compiler cannot eliminate virtual dispatching for existentials, because 
this is what existential is by definition — knowing how to manipulate it at 
static time, but not the type which varies at runtime. All non-class 
existentials are dispatched through their associated protocol witness tables.

Regards
Anders

> On 3 May 2017, at 09:05, Howard Lovatt  wrote:
> 
> My experience with languages that have generalised existential is that they 
> are superior in many circumstances; not just for collections, e.g. I gave the 
> example of the comparison protocol. 
> 
> I don't think methods called on a returned generalised existential have to be 
> called via a Vtable. If the return type is Self then the compiler can 
> eliminate the Vtable for selfs that are value types. For selfs that are 
> classes it would still have to use a Vtable though, because classes always 
> use Vtables! In most cases the return type will be Self and in most cases 
> the Self will be a value type, so I would argue that in most cases a Vtable 
> won't be used. 
> 
> -- Howard.
> 
>> On 2 May 2017, at 8:57 pm, Anders Ha  wrote:
>> 
>> I would like to add that generalized existential is not really a better 
>> solution than letting the collection optionally and statically supply one. 
>> It consequentially forces all calls to the filtered collections 
>> virtual/dynamic.
>> 
>> Higher kinded type would ideally help, but we all know it is not coming 
>> anytime soon, or perhaps ever. 
>> 
>> Regards
>> Anders
>> 
>>> On 2 May 2017, at 08:41, Xiaodi Wu via swift-evolution 
>>>  wrote:
>>> 
>>> Howard, this is also mentioned in the generics manifesto under "Opening 
>>> existentials," and it's received plentiful discussion and will surely 
>>> receive more as these issues become addressed in future proposals. Let's 
>>> not divert the conversation here about map and filter.
 On Mon, May 1, 2017 at 19:36 Howard Lovatt  wrote:
 Yes, I know the change I suggested involves making generalised 
 existentials. I am suggesting not making *any* changes until such effort 
 is available. I understand that this would be after Swift 4. I think the 
 wait would be worthwhile.
 
 As an aside: Currently one of the big issues with generalised existentials 
 in Swift is with Self (which you can think of as a form of generic 
 argument). Currently:
 
 protocol Equatable {
 static func ==(lhs: Self, rhs: Self) -> Bool
 ...
 }
 struct Int: Equatable { ... }
 let e1: Equatable = 1
 let e2: Equatable = 2
 if e1 == e2 { ... } // error: e1 and e2 don't necessarily have the 
 same dynamic type
 
 I would replace this with:
 
 protocol Equatable { // Use T instead of Self
 static func ==(lhs: T, rhs: T) -> Bool
 ...
 }
 struct Int: Equatable { ... }
 let e1: Equatable = 1
 let e2: Equatable = 2
 if e1 == e2 { ... } // No longer an error since they are both 
 Equatable
 
 As an aside on the aside, even better:
 
 protocol Equatable { // T defaults to Self
 static func ==(lhs: T, rhs: T) -> Bool
 ...
 }
 struct Int: Equatable { ... } // T is Int, the default is Self
 let e1: Equatable = 1  // T is Int, the default is Self
 let e2: Equatable = 2 // T is Int, the default is Self
 if e1 == e2 { ... } // No longer an error since they are both 
 Equatable
 
 Everything I am suggesting is done in other languages and from my personal 
 experience works out better.
 
 
   -- Howard.
 
> On 2 May 2017 at 09:53, Xiaodi Wu  wrote:
> Howard, take a look at the generics manifesto section on generic 
> protocols:
> 
> https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md
> 
> It explains very nicely how what you're really asking for is not generic 
> protocols but generalized existentials. This would be nice to have, but 
> it's clearly not happening within the next month and it wouldn't change 
> the solution for filter, for which this proposal is the obvious fix.
> 
> On Mon, May 1, 2017 at 18:09 Howard Lovatt via swift-evolution 
> 

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0174: Change `filter` to return an associated type

[Goffredo Marocchi via swift-evolution]

Sent from my iPhone

> On 3 May 2017, at 02:05, Howard Lovatt via swift-evolution 
>  wrote:
> 
> My experience with languages that have generalised existential is that they 
> are superior in many circumstances; not just for collections, e.g. I gave the 
> example of the comparison protocol. 

I think generalised existential is where we want to get to, is it not?

> I don't think methods called on a returned generalised existential have to be 
> called via a Vtable. If the return type is Self then the compiler can 
> eliminate the Vtable for selfs that are value types. For selfs that are 
> classes it would still have to use a Vtable though, because classes always 
> use Vtables! In most cases the return type will be Self and in most cases 
> the Self will be a value type, so I would argue that in most cases a Vtable 
> won't be used. 
> 
> -- Howard.
> 
>> On 2 May 2017, at 8:57 pm, Anders Ha  wrote:
>> 
>> I would like to add that generalized existential is not really a better 
>> solution than letting the collection optionally and statically supply one. 
>> It consequentially forces all calls to the filtered collections 
>> virtual/dynamic.
>> 
>> Higher kinded type would ideally help, but we all know it is not coming 
>> anytime soon, or perhaps ever. 
>> 
>> Regards
>> Anders
>> 
>>> On 2 May 2017, at 08:41, Xiaodi Wu via swift-evolution 
>>>  wrote:
>>> 
>>> Howard, this is also mentioned in the generics manifesto under "Opening 
>>> existentials," and it's received plentiful discussion and will surely 
>>> receive more as these issues become addressed in future proposals. Let's 
>>> not divert the conversation here about map and filter.
 On Mon, May 1, 2017 at 19:36 Howard Lovatt  wrote:
 Yes, I know the change I suggested involves making generalised 
 existentials. I am suggesting not making *any* changes until such effort 
 is available. I understand that this would be after Swift 4. I think the 
 wait would be worthwhile.
 
 As an aside: Currently one of the big issues with generalised existentials 
 in Swift is with Self (which you can think of as a form of generic 
 argument). Currently:
 
 protocol Equatable {
 static func ==(lhs: Self, rhs: Self) -> Bool
 ...
 }
 struct Int: Equatable { ... }
 let e1: Equatable = 1
 let e2: Equatable = 2
 if e1 == e2 { ... } // error: e1 and e2 don't necessarily have the 
 same dynamic type
 
 I would replace this with:
 
 protocol Equatable { // Use T instead of Self
 static func ==(lhs: T, rhs: T) -> Bool
 ...
 }
 struct Int: Equatable { ... }
 let e1: Equatable = 1
 let e2: Equatable = 2
 if e1 == e2 { ... } // No longer an error since they are both 
 Equatable
 
 As an aside on the aside, even better:
 
 protocol Equatable { // T defaults to Self
 static func ==(lhs: T, rhs: T) -> Bool
 ...
 }
 struct Int: Equatable { ... } // T is Int, the default is Self
 let e1: Equatable = 1  // T is Int, the default is Self
 let e2: Equatable = 2 // T is Int, the default is Self
 if e1 == e2 { ... } // No longer an error since they are both 
 Equatable
 
 Everything I am suggesting is done in other languages and from my personal 
 experience works out better.
 
 
   -- Howard.
 
> On 2 May 2017 at 09:53, Xiaodi Wu  wrote:
> Howard, take a look at the generics manifesto section on generic 
> protocols:
> 
> https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md
> 
> It explains very nicely how what you're really asking for is not generic 
> protocols but generalized existentials. This would be nice to have, but 
> it's clearly not happening within the next month and it wouldn't change 
> the solution for filter, for which this proposal is the obvious fix.
> 
> On Mon, May 1, 2017 at 18:09 Howard Lovatt via swift-evolution 
>  wrote:
>>> review of SE-0174 "Change `filter` to return an associated type" 
>>> 
>> 
>>> What is your evaluation of the proposal?
>> I think a change in this 'area' is valuable because currently always 
>> returning an array from collection operations is limiting. However I 
>> think this proposal feels like 'papering' over problems rather than 
>> fixing the root cause. I think it would be better to reject this and do 
>> two more adventurous proposals instead:
>> 
>>   1. Allow protocols to be generic, instead of associated types, so that 
>> you can write Sequence
>>   2. Allow Self to accept a generic argument, so that you can write 
>> Self
>> 
>> With 

Re: [swift-evolution] [swift-evolution-announce] [swift-build-dev] [Review] SE-0175 Package Manager Revised Dependency Resolution

[Kevin Ballard via swift-evolution]

On Tue, May 2, 2017, at 07:22 PM, Rick Ballard wrote:
> Proposal link:
> https://github.com/apple/swift-evolution/blob/master/proposals/0175-package-manager-revised-dependency-resolution.md

> * What is your evaluation of the proposal?

Big +1. This makes the package manager behave much more like how I expect it to.

> * Is the problem being addressed significant enough to warrant a change to 
> the Swift Package Manager?

Yes.

> * Does this proposal fit well with the feel and direction of Swift?

Yes.

> * If you have used other languages, libraries, or package managers with a 
> similar feature, how do you feel that this proposal compares to those?

This seems pretty similar to Cargo, Rust's package manager (which I think is 
excellent), although it doesn't have an explicit `resolve` command.

> * How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?

A quick reading.

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