Re: [swift-evolution] Throws? and throws!

[Rien via swift-evolution]

-1

I think the basic type system should remain free of such constructs.

I.e. if a Throws? is necessary on a + operation between integers, then the 
integers should be encapsulated into their own type.

In fact I am thinking lately of the “need” for a new type system in parallel to 
the current type system specifically for arithmetic. It would consist of 
Naturals, Reals, Imaginary etc. These new types would also have Nan and 
Infinite as members and use these to deal with out-of-bounds situations. 
Besides, it should be possible to constrain a subtype of them to a predefined 
ranges etc.

While these are just ‘thoughts’ at the moment, I did come to the conclusion 
that “one size fits all” is not the correct approach.
And I apply the same thinking to the suggested Throws?.
Imo it would introduce side effects into the current type system that would 
only benefit a small subset of users, and it would -probably- not completely 
satisfy those user fully. Hence a new arithmetic based type system would 
probably be better. And until (if ever) such a system is available it would imo 
be better to keep things as they are and implement specific mathematical 
requirements in wrappers.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl




> On 12 Jan 2017, at 23:58, Jonathan Hull via swift-evolution 
>  wrote:
> 
> I really like swift’s error handling system overall. It strikes a good 
> balance between safety and usability.
> 
> There are some cases where it would be nice to throw errors, but errors are 
> rarely expected in most use cases, so the overhead of ‘try’, etc… would make 
> things unusable. Thus fatalError or optionals are used instead.  For example, 
> operators like ‘+’ could never throw because adding ’try’ everywhere would 
> make arithmetic unbearable. But in a few cases it would make my algorithm 
> much cleaner if I just assume it will work and then catch overflow/underflow 
> errors if they happen, and resolve each of them with special cases.  Or 
> perhaps I am dealing with user entered values, and want to stop the 
> calculation and display a user visible error (e.g. a symbol in a spreadsheet 
> cell) instead of crashing.
> 
> I would like to propose adding ‘throws?’ and ‘throws!’ variants to ‘throws’.
> 
> These would be used for cases where error handling is not the default desired 
> behavior, but having it as an option is desired occasionally.  Essentially, 
> the user would no longer have to preface the call with ‘try’, as the compiler 
> would implicitly add ‘try?’ or ‘try!’ respectively.
> 
> Thus, the function would act like a non-throwing function (either trapping or 
> returning an optional in the case of error), but the user could add ‘try’ to 
> the call to override that behavior and deal with the error more explicitly.
> 
> Another example would be bounds checking on arrays.  If subscripting arrays 
> was marked as ‘throws!’ then it would have the same default behavior it does 
> now (trapping on bounds error).  But a user could add ‘try?’ to return nil 
> for a bounds error in cases where they explicitly want that, or they could 
> add ‘try’ to deal with it as an error using do-catch.
> 
> I think this would really increase the availability of error handling in 
> areas where it is impractical right now…
> 
> Thanks,
> Jon
> ___
> 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] Consolidate Code for Each Case in Enum

[Rien via swift-evolution]

+1

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl




> On 13 Jan 2017, at 03:01, Tim Shadel via swift-evolution 
>  wrote:
> 
> Fantastic points, all. Let me reply to a few.
> 
> First, the odd situations you mentioned with the defaults were spot on. I had 
> seen them, and thought a bit about it, but having you write it out in code 
> made it obvious that they're pretty harmful. I've removed defaults entirely 
> (see the updated Alternatives and Errors sections). This is actually a really 
> good indicator of whether you should use this syntax or not. If you'll save a 
> noticeable amount of space by using a default, then this isn't the syntax for 
> your situation.
> 
> To make that more obvious, I've added a Mixed Use Example 
> (https://gist.github.com/timshadel/5a5a8e085a6fd591483a933e603c2562#mixed-use-example)
>  showing how simple it is to use the existing syntax when you have a default 
> and a small number of exceptions, alongside the case block syntax for things 
> that are unique for each case. So, to summarize, I think that forcing the 
> additional code for each case is a good thing so that this syntax remains the 
> exception used when needed, instead of becoming the rule.
> 
> Now to your other points. The intent isn't to alter the amount of code 
> required to accomplish the task (code *complexity*), but to simplify 
> *maintenance and understanding* by allowing you to organize the code either 
> by property or by case (according to the merits of the code and your 
> judgement). Indeed, I try to highlight in the proposal that this usually 
> _increases_ code verbosity slightly in favor of the readability gained by 
> shifting the code layout.
> 
> Finally, to your point about attaching properties to values (also echoed in 
> David's musings about tagged unions vs Swift enums), it is different, but I'm 
> not sure of a cleaner way to group all the code related to a single case for 
> complex enums. In another light, no other type in Swift makes such heavy use 
> of `switch` statements as a mechanism to organize code, and so this starts to 
> make enum code look more like the rest of the code you find in Swift 
> projects, which could be a good thing for long-term readability.
> 
> 
>> On Jan 11, 2017, at 9:22 AM, Tony Allevato  wrote:
>> 
>> I'll summarize my thoughts for now, after thinking about it for a bit longer:
>> 
>> Plusses:
>> + In some cases it's nicer to have the ability to group functionality at 
>> each case rather than spread across methods lower in the type definition. 
>> I've written enums that were like state machines where being able to have 
>> the next state transition and other associated data grouped with the case 
>> would have made the code a bit cleaner, IMO.
>> + This is the cleanest syntax I've seen proposed for this idea.
>> 
>> Things that worry me:
>> – It's a new way to express the same idea without necessarily *simplifying* 
>> it in terms of code complexity.
>> – It adds a fair amount of complexity to the compiler, to build the implicit 
>> self-switch and merge the implementations for each partial property/function.
>> – It would be the first time, I believe, in Swift where properties/method 
>> implementations are attached to *values* rather than just to the *type*. 
>> That's quite a departure from the way we model these concepts.
>> – The use of the type-defined implementation as the default when a 
>> case-defined implementation is omitted can lead to some bizarre 
>> combinations, which I think need to be addressed in the proposal. Consider 
>> this:
>> 
>> ```
>> enum Foo {
>>   var description: String {
>> switch self {
>> case .bar: return "bar"
>> case .baz: return "baz"
>> default: return ""
>>   }
>>   
>>   case bar
>>   case baz
>>   case quux {
>> var description: String { return "quux" }
>>   }
>> }
>> ```
>> 
>> Should the user be able to omit the `default` case because everything is 
>> exhaustively covered without it? *Conceptually* yes, but that would require 
>> the compiler to analyze the switch statement inside `description` and 
>> understand that, which is probably not feasible for anything but the 
>> simplest examples (and perhaps not even for those). Otherwise, it would 
>> presumably transform the implementation to this:
>> 
>> ```
>>   var description: String {
>> switch self {
>> case .quux: return "quux"
>> default:
>>   switch self {
>>   case .bar: return "bar"
>>   case .baz: return "baz"
>>   default: return ""
>> }
>>   }
>> ```
>> 
>> ...which produces the expected output, but the generated code might not be 
>> ideal.
>> 
>> That makes me question whether we should allow default implementations at 
>> all. If we didn't allow it, we potentially require the user to write *more* 
>> code because they would have to duplicate the 

Re: [swift-evolution] Generic Subscripts

[Slava Pestov via swift-evolution]

> On Jan 12, 2017, at 7:05 PM, Karl Wagner  wrote:
> 
> 
>> On 12 Jan 2017, at 22:37, Slava Pestov via swift-evolution 
>> > wrote:
>> 
>>> 
>>> On Jan 12, 2017, at 9:53 AM, Chris Eidhof via swift-evolution 
>>> > wrote:
>>> 
>>> Ok, I've got a draft up as a gist: 
>>> https://gist.github.com/chriseidhof/6c681677d44903045587bf75fb17eb25 
>>> 
>>> 
>>> Before I submit it, could someone let me know if adding generics to 
>>> subscripts would influence the ABI? ( still feel pretty clueless in that 
>>> area).
>> 
>> It won’t change the ABI of existing subscript calls, but if the standard 
>> library introduces new generic subscripts that replace older non-generic 
>> subscripts, it will impact ABI.
>> 
>> Slava
> 
> Why are subscripts so different, anyway? One would think they are basically 
> sugared functions, but they don’t support so many things that regular 
> functions support. Not just syntax stuff, either - they also don’t support 
> @inline(__always) for some reason…

Nice catch with @inline(__always). Please file a JIRA issue, since I’m actively 
working on this stuff now.

Subscripts are a bit different from ordinary functions because they’re lvalues. 
You can call mutating members on the result of a subscript, or chain it with 
another property access or subscript. So the code path in SILGen is a little 
different than ordinary function calls. This is the reason subscripts cannot 
have default arguments also. With a bit of refactoring we can unify the code 
path for forming call arguments in ordinary calls and subscripts, and hopefully 
the default argument and generic cases will fall out naturally also.

> 
> Where generic subscripts are concerned, there are a couple of different 
> things to express:
> - Generic parameter  (I can understand various co-ordinates for the data)
> - Generic return type (I can construct your preferred representation of the 
> data)
> - Generic setter type (I can set the data using various compatible types):

I think all of these should be expressed with a single generic signature on the 
subscript itself. The element type passed to the setter and returned from the 
getter should be the same IMO, otherwise it’s not clear how it will work.

> 
> protocol MeaningfulToFoo {}
> protocol ConstructableFromFoo {}
> 
> struct Foo {
> subscript(index: Index) where Index: SignedInteger {
> get where T: ConstructableFromFoo { return T(self) }
> set where T: MeaningfulToFoo  { self.someProperty = 
> newValue.someData }
> }
> }
> 
> The syntax looks a bit awkward, though, IMO. I’m wondering if it might be 
> better to have some kind of combined subscript + property behaviours 
> (remember those?) and allow those to be generic instead. Subscripts and 
> properties are very similar anyway - they are both bundles of functions to 
> represent getting and setting data (not just regular-old “get” and “set”, 
> either, but also magic stuff like “mutableAddressWithPinnedNativeOwner”). The 
> only difference is that property getters can’t have parameters — which is 
> something I would also like to see lifted one day (I believe I’ve even seen 
> people asking for “named subscripts” due to the lack of this =P)
> 
> - Karl
> 

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

Re: [swift-evolution] Throws? and throws!

[Jose Cheyo Jimenez via swift-evolution]

> On Jan 12, 2017, at 5:34 PM, Greg Parker via swift-evolution 
>  wrote:
> 
> 
>> On Jan 12, 2017, at 4:46 PM, Xiaodi Wu via swift-evolution 
>> > wrote:
>> 
>>> On Thu, Jan 12, 2017 at 6:27 PM, Jonathan Hull >> > wrote:
>>> 
>>> Also, ‘try’ is still required to explicitly mark a potential error 
>>> propagation point, which is what it was designed to do.  You don’t have 
>>> ‘try’ with the variants because it is by default no longer a propagation 
>>> point (unless you make it one explicitly with ’try’).
>> 
>> If this is quite safe and more convenient, why then shouldn't it be the 
>> behavior for `throws`? (That is, why not just allow people to call throwing 
>> functions without `try` and crash if the error isn't caught? It'd be a 
>> purely additive proposal that's backwards compatible for all currently 
>> compiling code.)
> 
> Swift prefers that potential runtime crash points be visible in the code. You 
> can ignore a thrown error and crash instead, but the code will say `try!`. 
> You can force-unwrap an Optional and crash if it is nil, but the code will 
> say `!`. 
> 
> Allowing `try` to be omitted would obscure those crash points from humans 
> reading the code. It would no longer be possible to read call sites and be 
> able to distinguish which ones might crash due to an uncaught error.
> 
> (There are exceptions to this rule. Ordinary arithmetic and array access are 
> checked at runtime, and the default syntax is one that may crash.)
> 

Indirectly Diving by zero [1] // the compiler won’t let you directly divide by 
zero
Overflow or underflow [2]
Array Index out of range

Aside from those, Are there any other runtime “exceptions"?


[1] https://en.wikipedia.org/wiki/Undefined_(mathematics)#In_arithmetic 


//[2] example:
let number = Int16.max
print(number+1) //crash Illegal instruction

> 
> -- 
> Greg Parker gpar...@apple.com  Runtime 
> Wrangler
> 
> 
> ___
> 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] Generic Subscripts

[Karl Wagner via swift-evolution]

> On 12 Jan 2017, at 22:37, Slava Pestov via swift-evolution 
>  wrote:
> 
>> 
>> On Jan 12, 2017, at 9:53 AM, Chris Eidhof via swift-evolution 
>> > wrote:
>> 
>> Ok, I've got a draft up as a gist: 
>> https://gist.github.com/chriseidhof/6c681677d44903045587bf75fb17eb25 
>> 
>> 
>> Before I submit it, could someone let me know if adding generics to 
>> subscripts would influence the ABI? ( still feel pretty clueless in that 
>> area).
> 
> It won’t change the ABI of existing subscript calls, but if the standard 
> library introduces new generic subscripts that replace older non-generic 
> subscripts, it will impact ABI.
> 
> Slava

Why are subscripts so different, anyway? One would think they are basically 
sugared functions, but they don’t support so many things that regular functions 
support. Not just syntax stuff, either - they also don’t support 
@inline(__always) for some reason…

Where generic subscripts are concerned, there are a couple of different things 
to express:
- Generic parameter  (I can understand various co-ordinates for the data)
- Generic return type (I can construct your preferred representation of the 
data)
- Generic setter type (I can set the data using various compatible types):

protocol MeaningfulToFoo {}
protocol ConstructableFromFoo {}

struct Foo {
subscript(index: Index) where Index: SignedInteger {
get where T: ConstructableFromFoo { return T(self) }
set where T: MeaningfulToFoo  { self.someProperty = 
newValue.someData }
}
}

The syntax looks a bit awkward, though, IMO. I’m wondering if it might be 
better to have some kind of combined subscript + property behaviours (remember 
those?) and allow those to be generic instead. Subscripts and properties are 
very similar anyway - they are both bundles of functions to represent getting 
and setting data (not just regular-old “get” and “set”, either, but also magic 
stuff like “mutableAddressWithPinnedNativeOwner”). The only difference is that 
property getters can’t have parameters — which is something I would also like 
to see lifted one day (I believe I’ve even seen people asking for “named 
subscripts” due to the lack of this =P)

- Karl

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

Re: [swift-evolution] Consolidate Code for Each Case in Enum

[Tim Shadel via swift-evolution]

I'm glad you like it! I agree, it does lose the at-a-glace view of all cases. 
That's probably something you could still get with code-folding in the IDE, but 
it's still something you give up for this syntax. I would hope the small cost 
actually helps people stick with the old syntax for small enums, and consider 
this for more verbose cases.

> On Jan 12, 2017, at 11:15 AM, Jay Abbott  wrote:
> 
> Thanks for pointing this out Tim. I had actually read the whole thread but 
> over a few days between other things and must have missed the relevant 
> updates.
> 
> I think you may be reacting to the very first draft. `extension` isn't used 
> at all in the newest draft, and no code can exist outside the enum. In fact, 
> there's a fair amount of similarity to your idea in the newest proposal.
> 
> https://gist.github.com/timshadel/5a5a8e085a6fd591483a933e603c2562 
> 
> 
> 
> Oh yes - this is much better! Lovely in fact. Although it does lose the 
> benefit of at-a-glance understanding of the cases present in the enum when 
> they are on one line each (when the code gets bigger than in the example they 
> will be quite a way apart).

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

Re: [swift-evolution] Consolidate Code for Each Case in Enum

[Tim Shadel via swift-evolution]

Fantastic points, all. Let me reply to a few.

First, the odd situations you mentioned with the defaults were spot on. I had 
seen them, and thought a bit about it, but having you write it out in code made 
it obvious that they're pretty harmful. I've removed defaults entirely (see the 
updated Alternatives and Errors sections). This is actually a really good 
indicator of whether you should use this syntax or not. If you'll save a 
noticeable amount of space by using a default, then this isn't the syntax for 
your situation.

To make that more obvious, I've added a Mixed Use Example 
(https://gist.github.com/timshadel/5a5a8e085a6fd591483a933e603c2562#mixed-use-example)
 showing how simple it is to use the existing syntax when you have a default 
and a small number of exceptions, alongside the case block syntax for things 
that are unique for each case. So, to summarize, I think that forcing the 
additional code for each case is a good thing so that this syntax remains the 
exception used when needed, instead of becoming the rule.

Now to your other points. The intent isn't to alter the amount of code required 
to accomplish the task (code *complexity*), but to simplify *maintenance and 
understanding* by allowing you to organize the code either by property or by 
case (according to the merits of the code and your judgement). Indeed, I try to 
highlight in the proposal that this usually _increases_ code verbosity slightly 
in favor of the readability gained by shifting the code layout.

Finally, to your point about attaching properties to values (also echoed in 
David's musings about tagged unions vs Swift enums), it is different, but I'm 
not sure of a cleaner way to group all the code related to a single case for 
complex enums. In another light, no other type in Swift makes such heavy use of 
`switch` statements as a mechanism to organize code, and so this starts to make 
enum code look more like the rest of the code you find in Swift projects, which 
could be a good thing for long-term readability.


> On Jan 11, 2017, at 9:22 AM, Tony Allevato  wrote:
> 
> I'll summarize my thoughts for now, after thinking about it for a bit longer:
> 
> Plusses:
> + In some cases it's nicer to have the ability to group functionality at each 
> case rather than spread across methods lower in the type definition. I've 
> written enums that were like state machines where being able to have the next 
> state transition and other associated data grouped with the case would have 
> made the code a bit cleaner, IMO.
> + This is the cleanest syntax I've seen proposed for this idea.
> 
> Things that worry me:
> – It's a new way to express the same idea without necessarily *simplifying* 
> it in terms of code complexity.
> – It adds a fair amount of complexity to the compiler, to build the implicit 
> self-switch and merge the implementations for each partial property/function.
> – It would be the first time, I believe, in Swift where properties/method 
> implementations are attached to *values* rather than just to the *type*. 
> That's quite a departure from the way we model these concepts.
> – The use of the type-defined implementation as the default when a 
> case-defined implementation is omitted can lead to some bizarre combinations, 
> which I think need to be addressed in the proposal. Consider this:
> 
> ```
> enum Foo {
>   var description: String {
> switch self {
> case .bar: return "bar"
> case .baz: return "baz"
> default: return ""
>   }
>   
>   case bar
>   case baz
>   case quux {
> var description: String { return "quux" }
>   }
> }
> ```
> 
> Should the user be able to omit the `default` case because everything is 
> exhaustively covered without it? *Conceptually* yes, but that would require 
> the compiler to analyze the switch statement inside `description` and 
> understand that, which is probably not feasible for anything but the simplest 
> examples (and perhaps not even for those). Otherwise, it would presumably 
> transform the implementation to this:
> 
> ```
>   var description: String {
> switch self {
> case .quux: return "quux"
> default:
>   switch self {
>   case .bar: return "bar"
>   case .baz: return "baz"
>   default: return ""
> }
>   }
> ```
> 
> ...which produces the expected output, but the generated code might not be 
> ideal.
> 
> That makes me question whether we should allow default implementations at 
> all. If we didn't allow it, we potentially require the user to write *more* 
> code because they would have to duplicate the defaults under each case 
> separately. But it opens a door to potential confusion if we do allow them.
> 
> So... I guess I'm on the fence right now. I want to support this from the 
> point of view that syntactically it would improve the quality of some of the 
> enums I've written, but I'm hedging a bit conservatively because of those 
> concerns above.
> 
> 
> On Wed, Jan 11, 

Re: [swift-evolution] Range and ClosedRange

[Adriano Ferreira via swift-evolution]

Hi Dave,

I’m not arguing about correctness cause I understand the reasoning behind it, 
but about the abstraction itself.

I believe a simplified interface would be more fun to use and less confusing. 
This post  from Ole 
Begemann talks a little bit about this interesting idea.

Best,

—A

> On Jan 12, 2017, at 5:55 PM, David Sweeris  wrote:
> 
> 
>> On Jan 12, 2017, at 15:44, Adriano Ferreira via swift-evolution 
>>  wrote:
>> 
>> BTW, I agree with you, having the range type split is somewhat confusing, 
>> specially for those new to the language.
> 
> Do you mean that you think having two types is confusing, or that the way we 
> currently split them is confusing?
> 
> If it's the former, then I disagree... IIRC, open vs closed ranges is covered 
> in high school math, and IMHO it's not too hard to see the usefulness of both 
> "0..<5" and "1...5".
> 
> If it's the latter, I think it's only confusing because, well, partly because 
> we only implement half the kinds of ranges ("lower" is always closed, but 
> that's another thread), but mostly because we don't have generic protocols 
> yet. If we could write
>protocol Range where T : WhateverTheCurrentConstraintsAre {
>var lower: T {get}
>var upper: T {get}
>}
> Then we could define the concrete types as
>struct CCRange: Range {...}
>struct CORange: Range {...}
>struct OCRange: Range {...}
>struct OORange: Range {...}
> (Or spell it out, "ClosedClosedRange", if you don't like the abbreviations.) 
> Then in code, since `Range` doesn't have any "Self or associated type 
> requirements", you can make just make it the type of a variable. In fact, if 
> I'm not mistaken, the "..<" and "..." operators could even return a `Range` 
> instead of the relevant concrete type
>var x = 0..<5 // "..<" returns `CORange as Range`
>x = 0...4 // "..." returns `CCRange as Range`, which is fine because x's 
> type is `Range`, not `HalfOpenRange` (or whatever it's called now)
> We'd get full polymorphism between all the types of range without losing the 
> value semantics we want, and the current method of overloading functions is 
> still available if you need the speed of static dispatch.
> 
> - Dave Sweeris 
> 

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

Re: [swift-evolution] Throws? and throws!

[Xiaodi Wu via swift-evolution]

On Thu, Jan 12, 2017 at 7:34 PM, Greg Parker  wrote:

>
> On Jan 12, 2017, at 4:46 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Thu, Jan 12, 2017 at 6:27 PM, Jonathan Hull  wrote:
>
>
> Also, ‘try’ is still required to explicitly mark a potential error
> propagation point, which is what it was designed to do.  You don’t have
> ‘try’ with the variants because it is by default no longer a propagation
> point (unless you make it one explicitly with ’try’).
>
>
> If this is quite safe and more convenient, why then shouldn't it be the
> behavior for `throws`? (That is, why not just allow people to call throwing
> functions without `try` and crash if the error isn't caught? It'd be a
> purely additive proposal that's backwards compatible for all currently
> compiling code.)
>
>
> Swift prefers that potential runtime crash points be visible in the code.
> You can ignore a thrown error and crash instead, but the code will say
> `try!`. You can force-unwrap an Optional and crash if it is nil, but the
> code will say `!`.
>
> Allowing `try` to be omitted would obscure those crash points from humans
> reading the code. It would no longer be possible to read call sites and be
> able to distinguish which ones might crash due to an uncaught error.
>
> (There are exceptions to this rule. Ordinary arithmetic and array access
> are checked at runtime, and the default syntax is one that may crash.)
>

FWIW, that was meant to be an argument a fortiori (well, ad absurdum, I
suppose). If `throws!` is a good idea (whose purpose is to permit omission
of `try!` at call sites), then how much nicer would it be if we could just
do that with `throws`. It is, after all, technically source compatible. But
it is not, I agree, such a good idea with `throws`, so I'm skeptical of its
worth with the increased burden of new syntax.


-- 
> Greg Parker gpar...@apple.com Runtime Wrangler
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Throws? and throws!

[Greg Parker via swift-evolution]

> On Jan 12, 2017, at 4:46 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
>> On Thu, Jan 12, 2017 at 6:27 PM, Jonathan Hull > > wrote:
>> 
>> Also, ‘try’ is still required to explicitly mark a potential error 
>> propagation point, which is what it was designed to do.  You don’t have 
>> ‘try’ with the variants because it is by default no longer a propagation 
>> point (unless you make it one explicitly with ’try’).
> 
> If this is quite safe and more convenient, why then shouldn't it be the 
> behavior for `throws`? (That is, why not just allow people to call throwing 
> functions without `try` and crash if the error isn't caught? It'd be a purely 
> additive proposal that's backwards compatible for all currently compiling 
> code.)

Swift prefers that potential runtime crash points be visible in the code. You 
can ignore a thrown error and crash instead, but the code will say `try!`. You 
can force-unwrap an Optional and crash if it is nil, but the code will say `!`. 

Allowing `try` to be omitted would obscure those crash points from humans 
reading the code. It would no longer be possible to read call sites and be able 
to distinguish which ones might crash due to an uncaught error.

(There are exceptions to this rule. Ordinary arithmetic and array access are 
checked at runtime, and the default syntax is one that may crash.)


-- 
Greg Parker gpar...@apple.com  Runtime 
Wrangler


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

Re: [swift-evolution] Throws? and throws!

[Xiaodi Wu via swift-evolution]

On Thu, Jan 12, 2017 at 6:17 PM, Jonathan Hull  wrote:

>
> On Jan 12, 2017, at 3:35 PM, Xiaodi Wu  wrote:
>
> On Thu, Jan 12, 2017 at 4:58 PM, Jonathan Hull via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> I really like swift’s error handling system overall. It strikes a good
>> balance between safety and usability.
>>
>> There are some cases where it would be nice to throw errors, but errors
>> are rarely expected in most use cases, so the overhead of ‘try’, etc… would
>> make things unusable. Thus fatalError or optionals are used instead.  For
>> example, operators like ‘+’ could never throw because adding ’try’
>> everywhere would make arithmetic unbearable. But in a few cases it would
>> make my algorithm much cleaner if I just assume it will work and then catch
>> overflow/underflow errors if they happen, and resolve each of them with
>> special cases.  Or perhaps I am dealing with user entered values, and want
>> to stop the calculation and display a user visible error (e.g. a symbol in
>> a spreadsheet cell) instead of crashing.
>>
>
> Unless I'm mistaken, there is a performance overhead for throwing
> functions, and thus a much greater barrier to the use cases outlined above
> is that the performance penalty for '+' would be unacceptable in any case,
> whatever syntactic sugar you could come up with.
>
>
> I think that is an invalid assumption.  I don’t think we should limit our
> proposals based on the performance of the naive/brute-force implementation.
> I am sure there are lots of tricks the compiler could pull if performance
> is an issue. Off the top of my head, although the user model is that it
> adds “try!” before the function, it could actually make two different
> versions of the function (one with fatalError and the other with error
> handling) and insert the right one based on how it is called.
>
>
> I would like to propose adding ‘throws?’ and ‘throws!’ variants to
>> ‘throws’.
>>
>> These would be used for cases where error handling is not the default
>> desired behavior, but having it as an option is desired occasionally.
>
>
> While I admit the idea has an appeal on a practical level, I have an
> uncomfortable feeling about this. It's by definition true that error
> handling is never the default desired behavior, and if I recall correctly
> the performance of Swift error handling is tuned on the assumption that not
> throwing is far more common than throwing. If we accept this statement at
> face value as the justification for including `throws!`, then essentially
> all `throws` should be `throws!`. And indeed I suspect that if the feature
> were be implemented, that would rapidly become the case in much written
> Swift. In essence, then, I think you're effectively proposing to invert the
> assignment of responsibility for determining how errors are handled from
> the call site to the declaration site, at least by default. It goes against
> an overarching design principle in Swift (discussed earlier in the thread
> about DefaultConstructible) not to provide such defaults and to require
> explicitness at the call site.
>
>
> I would argue that it allows the framework designer a lot of
> expressiveness about what they feel the correct approach is.  By using
> ‘throws’, ‘throws?’, or ‘throws!’, they are able to require explicitness or
> not depending on how they expect the framework to be used.  There is still
> a lot of value to plain old ‘throws’ (namely where I need the user to
> consider the possibility of error), and I would continue to use it for most
> cases.  It is the cases where I have been forced to use fatalError, where I
> would use ‘throws!’.
>
> While mistake prevention is a worthy goal which I support fully, there is
> a difference between preventing programming errors and trying to enforce
> one’s coding philosophy on everyone.  I would argue for things like this,
> we should favor expressiveness and then trust framework designers to use
> that expressiveness responsibly.  I might argue differently in cases where
> there was a high probability of foot-gunning, but I don’t feel like this is
> one of those cases.  It is a choice made by the framework designer (just
> like they can make a class ‘open’ or not), and the good designers will use
> it well.
>

I should add, with respect to this point: I highly agree that "high
probability of foot-gunning" is one criterion for caution. But I think
there are other valid reasons for caution, and one has been perhaps only
occasionally remarked upon on this list:

One discussion--I can't recall whether on this list or on
swift-users--showed that there was already some confusion about best
practices surrounding failable vs throwing functions; those who raised the
point argued that two ways of failing was one too many. The Error Handling
Rationale document makes a very good case for each holding its own weight,
but I think we can all see that the choice does add to the complexity 

Re: [swift-evolution] Throws? and throws!

[Xiaodi Wu via swift-evolution]

On Thu, Jan 12, 2017 at 6:27 PM, Jonathan Hull  wrote:

> The problem with Java (and ObjC) is that exceptions can propagate
> unexpectedly into scopes which they weren’t expected and you end up with
> objects in inconsistent states where it is nearly impossible to continue in
> any meaningful way.  That can’t happen here as the error will never
> propagate beyond where it is expected to be.  On the contrary, ‘throws!’
> and ‘throws?’ both stop the propagation earlier than ‘throws’.
>

That's a fair point about `throws!`.

It seems that your motivation for `throws!` is to avoid writing `try!` at
the call site, since the functionality is otherwise the same. That keyword,
notably, is required at most once per statement. So--unless you're trying
to build up a solution for a whole new category of error (as mentioned
above)--the question boils down to: does having to write `try!` offer four
letters' worth of benefit at the call site? Your answer, if I understand,
seems to be: sometimes it might not be worth four letters, and that should
be enough to justify a new feature. I think, to make a convincing case,
you'll have to offer real-world use cases where many can agree on that
point, sufficient to justify the engineering resources for such a feature.
IMO the mere possibility that such a use case may exist is not enough,
especially offset against what I would argue is a real benefit to readers
of code that every call to a throwing function is currently clearly
annotated.

As to `throws?`, I'm not sure quite sure how it is supposed to work. If a
function `throws? -> Int`, is the return value actually of type `Int?`? And
if it's `throws? -> Int?`, then is the return value actually of type
`Int??`? In what ways would this design be superior to the already sketched
out `Result` type outlined in the Error Handling Rationale document,
which several people on this list have lined up to propose? Would a
`Result` cover even your use cases for `throws!`?

Also, ‘try’ is still required to explicitly mark a potential error
> propagation point, which is what it was designed to do.  You don’t have
> ‘try’ with the variants because it is by default no longer a propagation
> point (unless you make it one explicitly with ’try’).
>

If this is quite safe and more convenient, why then shouldn't it be the
behavior for `throws`? (That is, why not just allow people to call throwing
functions without `try` and crash if the error isn't caught? It'd be a
purely additive proposal that's backwards compatible for all currently
compiling code.)

Thanks,
> Jon
>
> On Jan 12, 2017, at 3:50 PM, Xiaodi Wu  wrote:
>
> Some additional thoughts: if I recall correctly from my (limited) Java
> days, throwing in Java worked essentially like your proposed `throws!`.
> That the Swift model expressly deviates from that example was not by
> accident, as far as I can tell. According to the error handling docs in the
> Swift repo:
>
> "Once an error is thrown, Swift will automatically propagate it out of
> scopes (that permit it), rather than relying on the programmer to manually
> check for errors and do their own control flow. This is just a lot less
> boilerplate for common error handling tasks. However, doing this naively
> would introduce a lot of implicit control flow, which makes it difficult to
> reason about the function's behavior. This is a serious maintenance problem
> and has traditionally been a considerable source of bugs in languages that
> heavily use exceptions.
>
> "Therefore, while Swift automatically propagates errors, it requires that
> statements and expressions that can implicitly throw be marked with the
> `try` keyword."
>
> So I think what this is saying is that requiring `try` _every time_ is
> core to the design of Swift error handling, and that `throws!` or even
> `throws?` would undo it.
>
>
> On Thu, Jan 12, 2017 at 5:35 PM, Xiaodi Wu  wrote:
>
>> On Thu, Jan 12, 2017 at 4:58 PM, Jonathan Hull via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> I really like swift’s error handling system overall. It strikes a good
>>> balance between safety and usability.
>>>
>>> There are some cases where it would be nice to throw errors, but errors
>>> are rarely expected in most use cases, so the overhead of ‘try’, etc… would
>>> make things unusable. Thus fatalError or optionals are used instead.  For
>>> example, operators like ‘+’ could never throw because adding ’try’
>>> everywhere would make arithmetic unbearable. But in a few cases it would
>>> make my algorithm much cleaner if I just assume it will work and then catch
>>> overflow/underflow errors if they happen, and resolve each of them with
>>> special cases.  Or perhaps I am dealing with user entered values, and want
>>> to stop the calculation and display a user visible error (e.g. a symbol in
>>> a spreadsheet cell) instead of crashing.
>>>
>>
>> Unless I'm mistaken, there is a performance overhead for 

Re: [swift-evolution] Best way to handle escaping function that might throw

[Howard Lovatt via swift-evolution]

@Slava,

I'm imagining that the compiler does much the same as Anton suggested, e.g.
Anton's:

struct FStore {
let f: () throws -> Void
init(_ f: @escaping () throws -> Void) { self.f = f }
func call() throws { try f() }
}

Is much the same as my:

struct FStore {
let f: () throws -> Void
init(_ f: @escaping () throws -> Void) { self.f = f }
func call() throws { try f() }
}

>From a compiler point of view.

The idea is that the compiler reuses some of its existing generic's
infrastructure. The main differences between my proposal and Anton's is
that because mine doesn't use a typed throw, E can only be 'AnyError' (any
type that implements Error) or Never, and E is not explicit. The
throws/rethrows distinction just becomes a compiler optimization in both
cases.

  -- Howard.

On 13 January 2017 at 10:42, Slava Pestov  wrote:

>
> On Jan 11, 2017, at 2:02 PM, Howard Lovatt via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Another possibility, other than generics, would be to drop rethrows all
> together and have the compiler infer if a throw is possible or not,
> including:
>
> struct FStore {
> let f: () throws -> Void
> func call() throws { try f() }
> }
>
> The compiler can make two versions, one if f can throw and one if it
> definitely doesn't.
>
>
> It seems that this approach is impractical, because you either have to
> compile two versions of every function, or make all function bodies
> available for inlining, which is a non-starter for a stable ABI.
>
> Slava
>
>
> Just a thought.
>
> On Tue, 10 Jan 2017 at 4:29 pm, Jacob Bandes-Storch 
> wrote:
>
>> Moving to swift-users list.
>>
>> No, there's no way to do this today. The point of rethrows is that within
>> one call site, "f(block)" can be treated as throwing if the block throws,
>> or not throwing if the block doesn't throw. In your example, once the
>> FStore object is constructed, the information about the original passed-in
>> function is lost, so the caller has no way to know whether call() can throw
>> or not.
>>
>> If this *were* possible, the information would somehow need to be encoded
>> in the type system when creating FStore(f: block). That would require
>> something like dependent typing, or generic-param-based-rethrows, e.g.
>>
>> struct FStore Void> {  // made-up syntax
>> let f: T
>> func call() rethrows(T) { try f() }  // throws-ness of this function
>> depends on throws-ness of T
>> }
>>
>>
>>
>> On Mon, Jan 9, 2017 at 9:21 PM, Howard Lovatt via swift-evolution > evolut...@swift.org> wrote:
>>
>> Hi,
>>
>> If I have an escaping function that I store and then call, I need to
>> declare the calling function as throwing, not rethrowing. EG:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> struct FStore {
>> let f: () throws -> Void
>> init(f: @escaping () throws -> Void) { self.f = f }
>> func call() throws { try f() } // Can't put rethrows here - have
>> to use throws
>> }
>> Is there a better solution?
>>
>> Thanks for any suggestions,
>>
>>   -- Howard.
>>
>>
>>
>>
>>
>> ___
>>
>>
>> swift-evolution mailing list
>>
>>
>> swift-evolution@swift.org
>>
>>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>>
>>
>>
>>
>> --
> -- Howard.
> ___
> 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] Throws? and throws!

[Xiaodi Wu via swift-evolution]

On Thu, Jan 12, 2017 at 6:17 PM, Jonathan Hull  wrote:

>
> On Jan 12, 2017, at 3:35 PM, Xiaodi Wu  wrote:
>
> On Thu, Jan 12, 2017 at 4:58 PM, Jonathan Hull via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> I really like swift’s error handling system overall. It strikes a good
>> balance between safety and usability.
>>
>> There are some cases where it would be nice to throw errors, but errors
>> are rarely expected in most use cases, so the overhead of ‘try’, etc… would
>> make things unusable. Thus fatalError or optionals are used instead.  For
>> example, operators like ‘+’ could never throw because adding ’try’
>> everywhere would make arithmetic unbearable. But in a few cases it would
>> make my algorithm much cleaner if I just assume it will work and then catch
>> overflow/underflow errors if they happen, and resolve each of them with
>> special cases.  Or perhaps I am dealing with user entered values, and want
>> to stop the calculation and display a user visible error (e.g. a symbol in
>> a spreadsheet cell) instead of crashing.
>>
>
> Unless I'm mistaken, there is a performance overhead for throwing
> functions, and thus a much greater barrier to the use cases outlined above
> is that the performance penalty for '+' would be unacceptable in any case,
> whatever syntactic sugar you could come up with.
>
>
> I think that is an invalid assumption.  I don’t think we should limit our
> proposals based on the performance of the naive/brute-force implementation.
> I am sure there are lots of tricks the compiler could pull if performance
> is an issue. Off the top of my head, although the user model is that it
> adds “try!” before the function, it could actually make two different
> versions of the function (one with fatalError and the other with error
> handling) and insert the right one based on how it is called.
>

Sure, that's not the meat of why I'm uncomfortable with the idea. I am
saying, however, that you've outlined as motivation two use cases here that
your proposal does not make possible.

> I would like to propose adding ‘throws?’ and ‘throws!’ variants to
>> ‘throws’.
>>
>> These would be used for cases where error handling is not the default
>> desired behavior, but having it as an option is desired occasionally.
>
>
> While I admit the idea has an appeal on a practical level, I have an
> uncomfortable feeling about this. It's by definition true that error
> handling is never the default desired behavior, and if I recall correctly
> the performance of Swift error handling is tuned on the assumption that not
> throwing is far more common than throwing. If we accept this statement at
> face value as the justification for including `throws!`, then essentially
> all `throws` should be `throws!`. And indeed I suspect that if the feature
> were be implemented, that would rapidly become the case in much written
> Swift. In essence, then, I think you're effectively proposing to invert the
> assignment of responsibility for determining how errors are handled from
> the call site to the declaration site, at least by default. It goes against
> an overarching design principle in Swift (discussed earlier in the thread
> about DefaultConstructible) not to provide such defaults and to require
> explicitness at the call site.
>
>
> I would argue that it allows the framework designer a lot of
> expressiveness about what they feel the correct approach is.  By using
> ‘throws’, ‘throws?’, or ‘throws!’, they are able to require explicitness or
> not depending on how they expect the framework to be used.  There is still
> a lot of value to plain old ‘throws’ (namely where I need the user to
> consider the possibility of error), and I would continue to use it for most
> cases.  It is the cases where I have been forced to use fatalError, where I
> would use ‘throws!’.
>

Have a gander at this document:
https://github.com/apple/swift/blob/master/docs/ErrorHandlingRationale.rst

In particular, have a look at the section titled "Kinds of error." I think
what you're describing here is that you've got something that's neither a
simple domain error nor a recoverable error, as classically described. And
you'll see that there are some kinds of error for which Swift doesn't
currently have a good answer. I'd be interested in some real-world use
cases, though, and a more holistic approach to these other kinds of error
would be called for. It's why I'm saying you've got the beginning of an
interesting idea, but it's a lot more involved than you're making it out to
be.

While mistake prevention is a worthy goal which I support fully, there is a
> difference between preventing programming errors and trying to enforce
> one’s coding philosophy on everyone.  I would argue for things like this,
> we should favor expressiveness and then trust framework designers to use
> that expressiveness responsibly.  I might argue differently in cases where
> there was a high probability of 

Re: [swift-evolution] Throws? and throws!

[Jonathan Hull via swift-evolution]

The problem with Java (and ObjC) is that exceptions can propagate unexpectedly 
into scopes which they weren’t expected and you end up with objects in 
inconsistent states where it is nearly impossible to continue in any meaningful 
way.  That can’t happen here as the error will never propagate beyond where it 
is expected to be.  On the contrary, ‘throws!’ and ‘throws?’ both stop the 
propagation earlier than ‘throws’.

Also, ‘try’ is still required to explicitly mark a potential error propagation 
point, which is what it was designed to do.  You don’t have ‘try’ with the 
variants because it is by default no longer a propagation point (unless you 
make it one explicitly with ’try’).

Thanks,
Jon

> On Jan 12, 2017, at 3:50 PM, Xiaodi Wu  wrote:
> 
> Some additional thoughts: if I recall correctly from my (limited) Java days, 
> throwing in Java worked essentially like your proposed `throws!`. That the 
> Swift model expressly deviates from that example was not by accident, as far 
> as I can tell. According to the error handling docs in the Swift repo:
> 
> "Once an error is thrown, Swift will automatically propagate it out of scopes 
> (that permit it), rather than relying on the programmer to manually check for 
> errors and do their own control flow. This is just a lot less boilerplate for 
> common error handling tasks. However, doing this naively would introduce a 
> lot of implicit control flow, which makes it difficult to reason about the 
> function's behavior. This is a serious maintenance problem and has 
> traditionally been a considerable source of bugs in languages that heavily 
> use exceptions.
> 
> "Therefore, while Swift automatically propagates errors, it requires that 
> statements and expressions that can implicitly throw be marked with the `try` 
> keyword."
> 
> So I think what this is saying is that requiring `try` _every time_ is core 
> to the design of Swift error handling, and that `throws!` or even `throws?` 
> would undo it.
> 
> 
> On Thu, Jan 12, 2017 at 5:35 PM, Xiaodi Wu  > wrote:
> On Thu, Jan 12, 2017 at 4:58 PM, Jonathan Hull via swift-evolution 
> > wrote:
> I really like swift’s error handling system overall. It strikes a good 
> balance between safety and usability.
> 
> There are some cases where it would be nice to throw errors, but errors are 
> rarely expected in most use cases, so the overhead of ‘try’, etc… would make 
> things unusable. Thus fatalError or optionals are used instead.  For example, 
> operators like ‘+’ could never throw because adding ’try’ everywhere would 
> make arithmetic unbearable. But in a few cases it would make my algorithm 
> much cleaner if I just assume it will work and then catch overflow/underflow 
> errors if they happen, and resolve each of them with special cases.  Or 
> perhaps I am dealing with user entered values, and want to stop the 
> calculation and display a user visible error (e.g. a symbol in a spreadsheet 
> cell) instead of crashing.
> 
> Unless I'm mistaken, there is a performance overhead for throwing functions, 
> and thus a much greater barrier to the use cases outlined above is that the 
> performance penalty for '+' would be unacceptable in any case, whatever 
> syntactic sugar you could come up with.
>  
> I would like to propose adding ‘throws?’ and ‘throws!’ variants to ‘throws’.
> 
> These would be used for cases where error handling is not the default desired 
> behavior, but having it as an option is desired occasionally.
> 
> While I admit the idea has an appeal on a practical level, I have an 
> uncomfortable feeling about this. It's by definition true that error handling 
> is never the default desired behavior, and if I recall correctly the 
> performance of Swift error handling is tuned on the assumption that not 
> throwing is far more common than throwing. If we accept this statement at 
> face value as the justification for including `throws!`, then essentially all 
> `throws` should be `throws!`. And indeed I suspect that if the feature were 
> be implemented, that would rapidly become the case in much written Swift. In 
> essence, then, I think you're effectively proposing to invert the assignment 
> of responsibility for determining how errors are handled from the call site 
> to the declaration site, at least by default. It goes against an overarching 
> design principle in Swift (discussed earlier in the thread about 
> DefaultConstructible) not to provide such defaults and to require 
> explicitness at the call site.
> 
> Essentially, the user would no longer have to preface the call with ‘try’, as 
> the compiler would implicitly add ‘try?’ or ‘try!’ respectively.
> 
> Thus, the function would act like a non-throwing function (either trapping or 
> returning an optional in the case of error), but the user could add ‘try’ to 
> the call to override that 

Re: [swift-evolution] Throws? and throws!

[Kevin Nattinger via swift-evolution]

> On Jan 12, 2017, at 3:50 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> Some additional thoughts: if I recall correctly from my (limited) Java days, 
> throwing in Java worked essentially like your proposed `throws!`. That the 
> Swift model expressly deviates from that example was not by accident, as far 
> as I can tell. According to the error handling docs in the Swift repo:

Java (functionally) has two types of exceptions, checked and unchecked. 
Checked exceptions must either be caught and handled or the calling method must 
be declared as throwing the same exception (or an ancestor).
Unchecked exceptions do not need to be declared, and can either be caught or 
implicitly work their way back up the stack until either they’re caught or they 
hit the top of the stack (in which case the JRE kills the program.

Objective-C’s exception system is essentially Java’s unchecked type, and 
Swift’s is checked (with the addition of requiring `try` at the call site. At 
risk of getting off on a tangent, I really dislike the raw `try` requirement. 
`try?` and `try!` at least make sense as they specify how to handle the 
exception; `try` does not.)
Swift’s exception system is basically checked exceptions; Objective-C’s is 
unchecked.

As far as I can tell, this proposal isn’t really like either; `throws?` would 
swallow the exception entirely if the caller didn’t handle it and `throws!` 
would kill the app without giving higher stack frames a chance to catch it. I’m 
really not a fan of either; I’d much prefer unchecked exceptions, and I think 
they fulfill the OP’s underlying concerns.

> 
> "Once an error is thrown, Swift will automatically propagate it out of scopes 
> (that permit it), rather than relying on the programmer to manually check for 
> errors and do their own control flow. This is just a lot less boilerplate for 
> common error handling tasks. However, doing this naively would introduce a 
> lot of implicit control flow, which makes it difficult to reason about the 
> function's behavior. This is a serious maintenance problem and has 
> traditionally been a considerable source of bugs in languages that heavily 
> use exceptions.
> 
> "Therefore, while Swift automatically propagates errors, it requires that 
> statements and expressions that can implicitly throw be marked with the `try` 
> keyword."
> 
> So I think what this is saying is that requiring `try` _every time_ is core 
> to the design of Swift error handling, and that `throws!` or even `throws?` 
> would undo it.
> 
> 
> On Thu, Jan 12, 2017 at 5:35 PM, Xiaodi Wu  > wrote:
> On Thu, Jan 12, 2017 at 4:58 PM, Jonathan Hull via swift-evolution 
> > wrote:
> I really like swift’s error handling system overall. It strikes a good 
> balance between safety and usability.
> 
> There are some cases where it would be nice to throw errors, but errors are 
> rarely expected in most use cases, so the overhead of ‘try’, etc… would make 
> things unusable. Thus fatalError or optionals are used instead.  For example, 
> operators like ‘+’ could never throw because adding ’try’ everywhere would 
> make arithmetic unbearable. But in a few cases it would make my algorithm 
> much cleaner if I just assume it will work and then catch overflow/underflow 
> errors if they happen, and resolve each of them with special cases.  Or 
> perhaps I am dealing with user entered values, and want to stop the 
> calculation and display a user visible error (e.g. a symbol in a spreadsheet 
> cell) instead of crashing.
> 
> Unless I'm mistaken, there is a performance overhead for throwing functions, 
> and thus a much greater barrier to the use cases outlined above is that the 
> performance penalty for '+' would be unacceptable in any case, whatever 
> syntactic sugar you could come up with.
>  
> I would like to propose adding ‘throws?’ and ‘throws!’ variants to ‘throws’.
> 
> These would be used for cases where error handling is not the default desired 
> behavior, but having it as an option is desired occasionally.
> 
> While I admit the idea has an appeal on a practical level, I have an 
> uncomfortable feeling about this. It's by definition true that error handling 
> is never the default desired behavior, and if I recall correctly the 
> performance of Swift error handling is tuned on the assumption that not 
> throwing is far more common than throwing. If we accept this statement at 
> face value as the justification for including `throws!`, then essentially all 
> `throws` should be `throws!`. And indeed I suspect that if the feature were 
> be implemented, that would rapidly become the case in much written Swift. In 
> essence, then, I think you're effectively proposing to invert the assignment 
> of responsibility for determining how errors are handled from the call site 
> to the declaration site, at least by default. It 

Re: [swift-evolution] Throws? and throws!

[Jonathan Hull via swift-evolution]

> On Jan 12, 2017, at 3:35 PM, Xiaodi Wu  wrote:
> 
> On Thu, Jan 12, 2017 at 4:58 PM, Jonathan Hull via swift-evolution 
> > wrote:
> I really like swift’s error handling system overall. It strikes a good 
> balance between safety and usability.
> 
> There are some cases where it would be nice to throw errors, but errors are 
> rarely expected in most use cases, so the overhead of ‘try’, etc… would make 
> things unusable. Thus fatalError or optionals are used instead.  For example, 
> operators like ‘+’ could never throw because adding ’try’ everywhere would 
> make arithmetic unbearable. But in a few cases it would make my algorithm 
> much cleaner if I just assume it will work and then catch overflow/underflow 
> errors if they happen, and resolve each of them with special cases.  Or 
> perhaps I am dealing with user entered values, and want to stop the 
> calculation and display a user visible error (e.g. a symbol in a spreadsheet 
> cell) instead of crashing.
> 
> Unless I'm mistaken, there is a performance overhead for throwing functions, 
> and thus a much greater barrier to the use cases outlined above is that the 
> performance penalty for '+' would be unacceptable in any case, whatever 
> syntactic sugar you could come up with.

I think that is an invalid assumption.  I don’t think we should limit our 
proposals based on the performance of the naive/brute-force implementation. I 
am sure there are lots of tricks the compiler could pull if performance is an 
issue. Off the top of my head, although the user model is that it adds “try!” 
before the function, it could actually make two different versions of the 
function (one with fatalError and the other with error handling) and insert the 
right one based on how it is called.


> I would like to propose adding ‘throws?’ and ‘throws!’ variants to ‘throws’.
> 
> These would be used for cases where error handling is not the default desired 
> behavior, but having it as an option is desired occasionally.
> 
> While I admit the idea has an appeal on a practical level, I have an 
> uncomfortable feeling about this. It's by definition true that error handling 
> is never the default desired behavior, and if I recall correctly the 
> performance of Swift error handling is tuned on the assumption that not 
> throwing is far more common than throwing. If we accept this statement at 
> face value as the justification for including `throws!`, then essentially all 
> `throws` should be `throws!`. And indeed I suspect that if the feature were 
> be implemented, that would rapidly become the case in much written Swift. In 
> essence, then, I think you're effectively proposing to invert the assignment 
> of responsibility for determining how errors are handled from the call site 
> to the declaration site, at least by default. It goes against an overarching 
> design principle in Swift (discussed earlier in the thread about 
> DefaultConstructible) not to provide such defaults and to require 
> explicitness at the call site.

I would argue that it allows the framework designer a lot of expressiveness 
about what they feel the correct approach is.  By using ‘throws’, ‘throws?’, or 
‘throws!’, they are able to require explicitness or not depending on how they 
expect the framework to be used.  There is still a lot of value to plain old 
‘throws’ (namely where I need the user to consider the possibility of error), 
and I would continue to use it for most cases.  It is the cases where I have 
been forced to use fatalError, where I would use ‘throws!’.

While mistake prevention is a worthy goal which I support fully, there is a 
difference between preventing programming errors and trying to enforce one’s 
coding philosophy on everyone.  I would argue for things like this, we should 
favor expressiveness and then trust framework designers to use that 
expressiveness responsibly.  I might argue differently in cases where there was 
a high probability of foot-gunning, but I don’t feel like this is one of those 
cases.  It is a choice made by the framework designer (just like they can make 
a class ‘open’ or not), and the good designers will use it well.

I would also add that all of your arguments apply equally well to ‘as!’ and 
forced unwrapping using ‘!’ which are both things that swift includes.  Thus I 
don’t think it is a overarching design principle of swift as you claim.  Rather 
we have safety by default, with the ability to override.


> Essentially, the user would no longer have to preface the call with ‘try’, as 
> the compiler would implicitly add ‘try?’ or ‘try!’ respectively.
> 
> Thus, the function would act like a non-throwing function (either trapping or 
> returning an optional in the case of error), but the user could add ‘try’ to 
> the call to override that behavior and deal with the error more explicitly.
> 
> Another example would be bounds checking on arrays.  If 

Re: [swift-evolution] Throws? and throws!

[Xiaodi Wu via swift-evolution]

Some additional thoughts: if I recall correctly from my (limited) Java
days, throwing in Java worked essentially like your proposed `throws!`.
That the Swift model expressly deviates from that example was not by
accident, as far as I can tell. According to the error handling docs in the
Swift repo:

"Once an error is thrown, Swift will automatically propagate it out of
scopes (that permit it), rather than relying on the programmer to manually
check for errors and do their own control flow. This is just a lot less
boilerplate for common error handling tasks. However, doing this naively
would introduce a lot of implicit control flow, which makes it difficult to
reason about the function's behavior. This is a serious maintenance problem
and has traditionally been a considerable source of bugs in languages that
heavily use exceptions.

"Therefore, while Swift automatically propagates errors, it requires that
statements and expressions that can implicitly throw be marked with the
`try` keyword."

So I think what this is saying is that requiring `try` _every time_ is core
to the design of Swift error handling, and that `throws!` or even `throws?`
would undo it.


On Thu, Jan 12, 2017 at 5:35 PM, Xiaodi Wu  wrote:

> On Thu, Jan 12, 2017 at 4:58 PM, Jonathan Hull via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> I really like swift’s error handling system overall. It strikes a good
>> balance between safety and usability.
>>
>> There are some cases where it would be nice to throw errors, but errors
>> are rarely expected in most use cases, so the overhead of ‘try’, etc… would
>> make things unusable. Thus fatalError or optionals are used instead.  For
>> example, operators like ‘+’ could never throw because adding ’try’
>> everywhere would make arithmetic unbearable. But in a few cases it would
>> make my algorithm much cleaner if I just assume it will work and then catch
>> overflow/underflow errors if they happen, and resolve each of them with
>> special cases.  Or perhaps I am dealing with user entered values, and want
>> to stop the calculation and display a user visible error (e.g. a symbol in
>> a spreadsheet cell) instead of crashing.
>>
>
> Unless I'm mistaken, there is a performance overhead for throwing
> functions, and thus a much greater barrier to the use cases outlined above
> is that the performance penalty for '+' would be unacceptable in any case,
> whatever syntactic sugar you could come up with.
>
>
>> I would like to propose adding ‘throws?’ and ‘throws!’ variants to
>> ‘throws’.
>>
>> These would be used for cases where error handling is not the default
>> desired behavior, but having it as an option is desired occasionally.
>
>
> While I admit the idea has an appeal on a practical level, I have an
> uncomfortable feeling about this. It's by definition true that error
> handling is never the default desired behavior, and if I recall correctly
> the performance of Swift error handling is tuned on the assumption that not
> throwing is far more common than throwing. If we accept this statement at
> face value as the justification for including `throws!`, then essentially
> all `throws` should be `throws!`. And indeed I suspect that if the feature
> were be implemented, that would rapidly become the case in much written
> Swift. In essence, then, I think you're effectively proposing to invert the
> assignment of responsibility for determining how errors are handled from
> the call site to the declaration site, at least by default. It goes against
> an overarching design principle in Swift (discussed earlier in the thread
> about DefaultConstructible) not to provide such defaults and to require
> explicitness at the call site.
>
> Essentially, the user would no longer have to preface the call with ‘try’,
>> as the compiler would implicitly add ‘try?’ or ‘try!’ respectively.
>>
>> Thus, the function would act like a non-throwing function (either
>> trapping or returning an optional in the case of error), but the user could
>> add ‘try’ to the call to override that behavior and deal with the error
>> more explicitly.
>>
>> Another example would be bounds checking on arrays.  If subscripting
>> arrays was marked as ‘throws!’ then it would have the same default behavior
>> it does now (trapping on bounds error).  But a user could add ‘try?’ to
>> return nil for a bounds error in cases where they explicitly want that, or
>> they could add ‘try’ to deal with it as an error using do-catch.
>>
>
> Subscripts cannot throw at all at the moment, and in another thread some
> of the challenges for designing throwing subscripts were just mentioned. I
> suspect any sort of throwing subscript will not be possible in the
> immediate future, so the argument for `throws!` here is moot.
>
> I think this would really increase the availability of error handling in
>> areas where it is impractical right now…
>>
>
> I think the practical argument could be made stronger by use cases not

Re: [swift-evolution] Best way to handle escaping function that might throw

[Slava Pestov via swift-evolution]

> On Jan 11, 2017, at 2:02 PM, Howard Lovatt via swift-evolution 
>  wrote:
> 
> Another possibility, other than generics, would be to drop rethrows all 
> together and have the compiler infer if a throw is possible or not, including:
> 
> struct FStore {
> let f: () throws -> Void
> func call() throws { try f() }
> }
> 
> The compiler can make two versions, one if f can throw and one if it 
> definitely doesn't. 

It seems that this approach is impractical, because you either have to compile 
two versions of every function, or make all function bodies available for 
inlining, which is a non-starter for a stable ABI.

Slava

> 
> Just a thought. 
> 
> On Tue, 10 Jan 2017 at 4:29 pm, Jacob Bandes-Storch  > wrote:
> Moving to swift-users list.
> 
> No, there's no way to do this today. The point of rethrows is that within one 
> call site, "f(block)" can be treated as throwing if the block throws, or not 
> throwing if the block doesn't throw. In your example, once the FStore object 
> is constructed, the information about the original passed-in function is 
> lost, so the caller has no way to know whether call() can throw or not.
> 
> If this *were* possible, the information would somehow need to be encoded in 
> the type system when creating FStore(f: block). That would require something 
> like dependent typing, or generic-param-based-rethrows, e.g.
> 
> struct FStore Void> {  // made-up syntax
> let f: T
> func call() rethrows(T) { try f() }  // throws-ness of this function 
> depends on throws-ness of T
> }
> 
> 
> 
> On Mon, Jan 9, 2017 at 9:21 PM, Howard Lovatt via swift-evolution 
> > wrote:
> Hi,
> 
> If I have an escaping function that I store and then call, I need to declare 
> the calling function as throwing, not rethrowing. EG:
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> struct FStore {
> let f: () throws -> Void
> init(f: @escaping () throws -> Void) { self.f = f }
> func call() throws { try f() } // Can't put rethrows here - have to 
> use throws
> }
> 
> Is there a better solution?
> 
> Thanks for any suggestions,
> 
>   -- Howard.
> 
> 
> 
> 
> 
> ___
> 
> 
> swift-evolution mailing list
> 
> 
> swift-evolution@swift.org 
> 
> 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> 
> 
> 
> 
> 
> 
> -- 
> -- Howard.
> ___
> 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] Throws? and throws!

[Xiaodi Wu via swift-evolution]

On Thu, Jan 12, 2017 at 4:58 PM, Jonathan Hull via swift-evolution <
swift-evolution@swift.org> wrote:

> I really like swift’s error handling system overall. It strikes a good
> balance between safety and usability.
>
> There are some cases where it would be nice to throw errors, but errors
> are rarely expected in most use cases, so the overhead of ‘try’, etc… would
> make things unusable. Thus fatalError or optionals are used instead.  For
> example, operators like ‘+’ could never throw because adding ’try’
> everywhere would make arithmetic unbearable. But in a few cases it would
> make my algorithm much cleaner if I just assume it will work and then catch
> overflow/underflow errors if they happen, and resolve each of them with
> special cases.  Or perhaps I am dealing with user entered values, and want
> to stop the calculation and display a user visible error (e.g. a symbol in
> a spreadsheet cell) instead of crashing.
>

Unless I'm mistaken, there is a performance overhead for throwing
functions, and thus a much greater barrier to the use cases outlined above
is that the performance penalty for '+' would be unacceptable in any case,
whatever syntactic sugar you could come up with.


> I would like to propose adding ‘throws?’ and ‘throws!’ variants to
> ‘throws’.
>
> These would be used for cases where error handling is not the default
> desired behavior, but having it as an option is desired occasionally.


While I admit the idea has an appeal on a practical level, I have an
uncomfortable feeling about this. It's by definition true that error
handling is never the default desired behavior, and if I recall correctly
the performance of Swift error handling is tuned on the assumption that not
throwing is far more common than throwing. If we accept this statement at
face value as the justification for including `throws!`, then essentially
all `throws` should be `throws!`. And indeed I suspect that if the feature
were be implemented, that would rapidly become the case in much written
Swift. In essence, then, I think you're effectively proposing to invert the
assignment of responsibility for determining how errors are handled from
the call site to the declaration site, at least by default. It goes against
an overarching design principle in Swift (discussed earlier in the thread
about DefaultConstructible) not to provide such defaults and to require
explicitness at the call site.

Essentially, the user would no longer have to preface the call with ‘try’,
> as the compiler would implicitly add ‘try?’ or ‘try!’ respectively.
>
> Thus, the function would act like a non-throwing function (either trapping
> or returning an optional in the case of error), but the user could add
> ‘try’ to the call to override that behavior and deal with the error more
> explicitly.
>
> Another example would be bounds checking on arrays.  If subscripting
> arrays was marked as ‘throws!’ then it would have the same default behavior
> it does now (trapping on bounds error).  But a user could add ‘try?’ to
> return nil for a bounds error in cases where they explicitly want that, or
> they could add ‘try’ to deal with it as an error using do-catch.
>

Subscripts cannot throw at all at the moment, and in another thread some of
the challenges for designing throwing subscripts were just mentioned. I
suspect any sort of throwing subscript will not be possible in the
immediate future, so the argument for `throws!` here is moot.

I think this would really increase the availability of error handling in
> areas where it is impractical right now…
>

I think the practical argument could be made stronger by use cases not
encumbered by other difficulties as outlined above. Is there a currently
throwing function you've encountered that would be greatly improved by such
a feature? Besides that, though, my discomfort is (as mentioned above) that
the practical effect of such a feature is that it will actually altogether
invert the default responsibility for error handling, and I'm not sure that
it's entirely consistent with Swift's design as a consequence. In any case
it'd be a far greater change than you've made it out to be. Interesting
suggestion, definitely.

Thanks,
> Jon
> ___
> 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] Make the type-casting operator accept expressions on its right side

[David Sweeris via swift-evolution]

> On Jan 12, 2017, at 16:50, Oscar Swanros via swift-evolution 
>  wrote:
> 
> Hello everyone. This is my first contribution to Swift Evolution. In summary: 
> It would be nice if the type casting operator accepted expressions on its 
> right side. 
> 
> So, basically, the type casting operator only accepts types and can't process 
> expressions on its right side.
> 
> Having a class A, and a subclass of A, B:
> 
> class A {}
> class B: A {}
> 
> And a function that returns the passed type:
> 
> func type(t: T.Type) -> T.Type {
> return t
> }
> 
> The following scenario works:
> 
> let b = B()
> let a = (b as A)
> 
> However the following scenario doesn't:
> 
> let b = B()
> let a = (b as type(A))
> 
> 
> Having the “as” accept expressions on its right side would be really useful 
> and could enable some truly great generic algorithm implementations.

+1 for the functionality, but I think it's part of the larger issue of 
"functions which can be evaluated at compile-time", which, IIRC, is presently 
considered out of scope (can't recall if that's just for phase 1 or Swift 4 
altogether). I might be wrong, though. I'm sure someone who knows more than I 
do will be along shortly with a better answer.

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

[swift-evolution] Throws? and throws!

[Jonathan Hull via swift-evolution]

I really like swift’s error handling system overall. It strikes a good balance 
between safety and usability.

There are some cases where it would be nice to throw errors, but errors are 
rarely expected in most use cases, so the overhead of ‘try’, etc… would make 
things unusable. Thus fatalError or optionals are used instead.  For example, 
operators like ‘+’ could never throw because adding ’try’ everywhere would make 
arithmetic unbearable. But in a few cases it would make my algorithm much 
cleaner if I just assume it will work and then catch overflow/underflow errors 
if they happen, and resolve each of them with special cases.  Or perhaps I am 
dealing with user entered values, and want to stop the calculation and display 
a user visible error (e.g. a symbol in a spreadsheet cell) instead of crashing.

I would like to propose adding ‘throws?’ and ‘throws!’ variants to ‘throws’.

These would be used for cases where error handling is not the default desired 
behavior, but having it as an option is desired occasionally.  Essentially, the 
user would no longer have to preface the call with ‘try’, as the compiler would 
implicitly add ‘try?’ or ‘try!’ respectively.

Thus, the function would act like a non-throwing function (either trapping or 
returning an optional in the case of error), but the user could add ‘try’ to 
the call to override that behavior and deal with the error more explicitly.

Another example would be bounds checking on arrays.  If subscripting arrays was 
marked as ‘throws!’ then it would have the same default behavior it does now 
(trapping on bounds error).  But a user could add ‘try?’ to return nil for a 
bounds error in cases where they explicitly want that, or they could add ‘try’ 
to deal with it as an error using do-catch.

I think this would really increase the availability of error handling in areas 
where it is impractical right now…

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

Re: [swift-evolution] Range and ClosedRange

[David Sweeris via swift-evolution]

> On Jan 12, 2017, at 15:44, Adriano Ferreira via swift-evolution 
>  wrote:
> 
> BTW, I agree with you, having the range type split is somewhat confusing, 
> specially for those new to the language.

Do you mean that you think having two types is confusing, or that the way we 
currently split them is confusing?

If it's the former, then I disagree... IIRC, open vs closed ranges is covered 
in high school math, and IMHO it's not too hard to see the usefulness of both 
"0..<5" and "1...5".

If it's the latter, I think it's only confusing because, well, partly because 
we only implement half the kinds of ranges ("lower" is always closed, but 
that's another thread), but mostly because we don't have generic protocols yet. 
If we could write
protocol Range where T : WhateverTheCurrentConstraintsAre {
var lower: T {get}
var upper: T {get}
}
Then we could define the concrete types as
struct CCRange: Range {...}
struct CORange: Range {...}
struct OCRange: Range {...}
struct OORange: Range {...}
(Or spell it out, "ClosedClosedRange", if you don't like the abbreviations.) 
Then in code, since `Range` doesn't have any "Self or associated type 
requirements", you can make just make it the type of a variable. In fact, if 
I'm not mistaken, the "..<" and "..." operators could even return a `Range` 
instead of the relevant concrete type
var x = 0..<5 // "..<" returns `CORange as Range`
x = 0...4 // "..." returns `CCRange as Range`, which is fine because x's 
type is `Range`, not `HalfOpenRange` (or whatever it's called now)
We'd get full polymorphism between all the types of range without losing the 
value semantics we want, and the current method of overloading functions is 
still available if you need the speed of static dispatch.

- Dave Sweeris 

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

[swift-evolution] Make the type-casting operator accept expressions on its right side

[Oscar Swanros via swift-evolution]

Hello everyone. This is my first contribution to Swift Evolution. In summary: 
It would be nice if the type casting operator accepted expressions on its right 
side.


So, basically, the type casting operator only accepts types and can't process 
expressions on its right side.

Having a class A, and a subclass of A, B:

class A {}
class B: A {}

And a function that returns the passed type:

func type(t: T.Type) -> T.Type {
   return t
}

The following scenario works:

let b = B()
let a = (b as A)

However the following scenario doesn't:

let b = B()
let a = (b as type(A))




Having the “as” accept expressions on its right side would be really useful and 
could enable some truly great generic algorithm implementations.




Looking forward to what you guys think about this.

— Oscar Swanros | @swanros

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

Re: [swift-evolution] Range and ClosedRange

[Sean Heber via swift-evolution]

I would very much like to know what the status is of conditional conformances 
and if there’s a timeline for them or they are underway or whatnot. My 
unscientific gut check suggests something like 50% of recent proposals or rough 
ideas have been impaired by their absence. :P

l8r
Sean


> On Jan 12, 2017, at 4:03 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> I agree that there are use cases where the distinction between ClosedRange 
> and Range is less ergonomic than perhaps possible. However, I would be very 
> much against rolling back the improved correctness, but as has been suggested 
> by a previous comment on the swift-users lists, a protocol would not be out 
> of place. By current Swift conventions, and given our goal of as much source 
> compatibility as possible (i.e. not renaming `Range`), such a protocol would 
> be named `RangeProtocol`.
> 
> At the moment, we actually have four range types: Range, CountableRange, 
> ClosedRange, CountableClosedRange. Once conditional conformances fall into 
> place, the Countable versions can go away. There are useful algorithms that 
> can ignore the distinction between an open range and a closed range when the 
> bounds are countable (e.g. Int) that do _not_ make sense when the bounds are 
> not countable (e.g. Float). This comes down to the fact that `0...(2 as Int)` 
> is in many ways another way of expressing `0..<(3 as Int)` but `0...(2 as 
> Float)` is very much not the same thing as `0..<(3 as Float)`. Therefore, IMO 
> it'd be wisest to hold off on designing a `RangeProtocol` until the requisite 
> generics features are implemented, so that the final design can take 
> advantage of such features for a maximally ergonomic but still correct design.
> 
> 
> On Thu, Jan 12, 2017 at 3:44 PM, Adriano Ferreira via swift-evolution 
>  wrote:
> Hi David,
> 
> There were a few instances where this topic or similar came up at the Swift 
> Evolution List and Swift Users List.
> 
> There’s even this interesting proposal that dwells with it while providing 
> more lenient subscripts to collections.
> 
> BTW, I agree with you, having the range type split is somewhat confusing, 
> specially for those new to the language.
> 
> Best,
> 
> —A
> 
>> On Jan 12, 2017, at 3:11 PM, David Hart via swift-evolution 
>>  wrote:
>> 
>> Hello,
>> 
>> Since the release of Swift 3, I’ve seen quite a few people (me included) 
>> experience a lot of friction with the new types for representing ranges. 
>> I’ve seen people confused when writing an API that takes a Range as argument 
>> but then can’t pass in a ClosedRange. Sometimes this can be fixed because 
>> the API should be written against a more general protocol, but sometimes 
>> that’s not the case.
>> 
>> Those new types definitely seem to cause more problems than they fixed (the 
>> Int.max problem). Has the Standard Library team put any thought into this?
>> 
>> Regards,
>> 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
> 
> 
> ___
> 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] Range and ClosedRange

[Xiaodi Wu via swift-evolution]

I agree that there are use cases where the distinction between ClosedRange
and Range is less ergonomic than perhaps possible. However, I would be very
much against rolling back the improved correctness, but as has been
suggested by a previous comment on the swift-users lists, a protocol would
not be out of place. By current Swift conventions, and given our goal of as
much source compatibility as possible (i.e. not renaming `Range`), such a
protocol would be named `RangeProtocol`.

At the moment, we actually have four range types: Range, CountableRange,
ClosedRange, CountableClosedRange. Once conditional conformances fall into
place, the Countable versions can go away. There are useful algorithms that
can ignore the distinction between an open range and a closed range when
the bounds are countable (e.g. Int) that do _not_ make sense when the
bounds are not countable (e.g. Float). This comes down to the fact that
`0...(2 as Int)` is in many ways another way of expressing `0..<(3 as Int)`
but `0...(2 as Float)` is very much not the same thing as `0..<(3 as
Float)`. Therefore, IMO it'd be wisest to hold off on designing a
`RangeProtocol` until the requisite generics features are implemented, so
that the final design can take advantage of such features for a maximally
ergonomic but still correct design.


On Thu, Jan 12, 2017 at 3:44 PM, Adriano Ferreira via swift-evolution <
swift-evolution@swift.org> wrote:

> Hi David,
>
> There were a few instances where this topic or similar came up at the Swift
> Evolution List
> 
>  and Swift Users List
> 
> .
>
> There’s even this interesting proposal
> 
>  that
> dwells with it while providing more lenient subscripts to collections.
>
> BTW, I agree with you, having the range type split is somewhat confusing,
> specially for those new to the language.
>
> Best,
>
> —A
>
> On Jan 12, 2017, at 3:11 PM, David Hart via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Hello,
>
> Since the release of Swift 3, I’ve seen quite a few people (me included)
> experience a lot of friction with the new types for representing ranges.
> I’ve seen people confused when writing an API that takes a Range as
> argument but then can’t pass in a ClosedRange. Sometimes this can be fixed
> because the API should be written against a more general protocol, but
> sometimes that’s not the case.
>
> Those new types definitely seem to cause more problems than they fixed
> (the Int.max problem). Has the Standard Library team put any thought into
> this?
>
> Regards,
> 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
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Range and ClosedRange

[Adriano Ferreira via swift-evolution]

Hi David,

There were a few instances where this topic or similar came up at the Swift 
Evolution List 

 and Swift Users List 
.

There’s even this interesting proposal 

 that dwells with it while providing more lenient subscripts to collections.

BTW, I agree with you, having the range type split is somewhat confusing, 
specially for those new to the language.

Best,

—A

> On Jan 12, 2017, at 3:11 PM, David Hart via swift-evolution 
>  wrote:
> 
> Hello,
> 
> Since the release of Swift 3, I’ve seen quite a few people (me included) 
> experience a lot of friction with the new types for representing ranges. I’ve 
> seen people confused when writing an API that takes a Range as argument but 
> then can’t pass in a ClosedRange. Sometimes this can be fixed because the API 
> should be written against a more general protocol, but sometimes that’s not 
> the case.
> 
> Those new types definitely seem to cause more problems than they fixed (the 
> Int.max problem). Has the Standard Library team put any thought into this?
> 
> Regards,
> 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] Generic Subscripts

[Douglas Gregor via swift-evolution]

> On Jan 12, 2017, at 9:53 AM, Chris Eidhof  wrote:
> 
> Ok, I've got a draft up as a gist: 
> https://gist.github.com/chriseidhof/6c681677d44903045587bf75fb17eb25 
> 
Please remember to fill in the title (rather than “Feature name”). Otherwise… 
there’s not much to say. It’s a straightforward addition. Thanks for working on 
it! 

> 
> Before I submit it, could someone let me know if adding generics to 
> subscripts would influence the ABI? ( still feel pretty clueless in that 
> area).

What Slava said!

- Doug

> 
> Thanks!
> 
> On Thu, Jan 12, 2017 at 8:57 AM, Douglas Gregor via swift-evolution 
> > wrote:
> 
> 
> Sent from my iPhone
> 
> On Jan 11, 2017, at 11:05 PM, Chris Eidhof via swift-evolution 
> > wrote:
> 
>> Okay,
>> 
>> I agree that throwing subscripts would be great to have. Likewise, 
>> generic(and maybe even throwing) properties could be useful. However, I 
>> think that for this proposal, it makes more sense to focus on just generic 
>> subscripts, and mention throwing subscripts as "future improvements"? 
> 
> There's already a draft proposal covering throwing subscripts. You can 
> mention it's existence, but I don't see a reason to say much. 
> 
>  - Doug
> 
> 
>> 
>> On Wed, Jan 11, 2017 at 8:52 PM, John McCall via swift-evolution 
>> > wrote:
>>> On Jan 11, 2017, at 1:32 PM, Erica Sadun via swift-evolution 
>>> > wrote:
 On Jan 11, 2017, at 12:26 AM, Chris Lattner via swift-evolution 
 > wrote:
 
 On Jan 10, 2017, at 11:40 AM, Douglas Gregor via swift-evolution 
 > wrote:
>> On Jan 10, 2017, at 10:34 AM, Michael Ilseman via swift-evolution 
>> > wrote:
>> 
>> [Forgot to CC swift-evolution the first time]
>> 
>> When this came up last, it was seen as more so a bug in the current 
>> implementation, rather than an explicit choice. There's no need for a 
>> proposal, just a JIRA: 
>> https://bugs.swift.org/browse/SR-115?jql=text%20~%20%22Generic%20subscript%22
>>  
>> 
>>  
> 
> It’s a nontrivial new user-facing feature with new syntax in the 
> language, so it’ll need a proposal. ‘twould be good for the proposal to 
> link to the JIRA ticket.
> 
> I’ve only heard positive reactions toward this feature, and it’s 
> something that the standard library could make good use of.
 
 +1, this would be clearly great to happen.
 
 -Chris
>>> 
>>> 
>>> I apologize for adding to this topic rather than starting a new one, but I 
>>> figure people interested in subscripts would be more likely to see my 
>>> question:
>>> 
>>> Is there a good reason subscripts cannot throw? Right now you can create a 
>>> [safe: index] subscript to return an optional but you can't create one that 
>>> returns an unwrapped value or throws.
>> 
>> Throwing accessors are mostly straightforward, but there is a big conceptual 
>> question: what happens if an accessor is called during error propagation?  
>> For example:
>> 
>>   objectWithThrowingSubscriptSetter[index].mutatingMethodThatCanThrow()
>> 
>> If the method throws, we currently still call the setter in order to finish 
>> the access.  If the setter can throw, then, we might end up with multiple 
>> errors being thrown at the same time, which isn't good — the language is put 
>> in the awkward position of having to invent an arbitrary resolution 
>> mechanism.
>> 
>> You might ask: why do we call the setter if an error is thrown?  Well, it's 
>> complicated.  One reason is that the implementation technique we use for 
>> generic access to subscripts and properties — accesses where we don't know 
>> how the subscript/property is implemented — doesn't know how to distinguish 
>> between *finishing* an access normally and *aborting* an access abnormally.  
>> Some kinds of property/subscript implementation — ones currently reserved 
>> for the standard library, but likely to be eventually offered to users in 
>> some form — depend on doing extra work no matter how the access is 
>> terminated, e.g. to release a buffer pointer.  (In fact, in general this 
>> applies even to get/set implementations, because even if we decided not to 
>> call the setter when an error was thrown, we would at least need to destroy 
>> the index argument that we were going to pass to the setter.)  In order to 
>> get consistent behavior between generic and non-generic accesses, we've 

Re: [swift-evolution] Generic Subscripts

[Slava Pestov via swift-evolution]

> On Jan 12, 2017, at 9:53 AM, Chris Eidhof via swift-evolution 
>  wrote:
> 
> Ok, I've got a draft up as a gist: 
> https://gist.github.com/chriseidhof/6c681677d44903045587bf75fb17eb25 
> 
> 
> Before I submit it, could someone let me know if adding generics to 
> subscripts would influence the ABI? ( still feel pretty clueless in that 
> area).

It won’t change the ABI of existing subscript calls, but if the standard 
library introduces new generic subscripts that replace older non-generic 
subscripts, it will impact ABI.

Slava

> 
> Thanks!
> 
> On Thu, Jan 12, 2017 at 8:57 AM, Douglas Gregor via swift-evolution 
> > wrote:
> 
> 
> Sent from my iPhone
> 
> On Jan 11, 2017, at 11:05 PM, Chris Eidhof via swift-evolution 
> > wrote:
> 
>> Okay,
>> 
>> I agree that throwing subscripts would be great to have. Likewise, 
>> generic(and maybe even throwing) properties could be useful. However, I 
>> think that for this proposal, it makes more sense to focus on just generic 
>> subscripts, and mention throwing subscripts as "future improvements"? 
> 
> There's already a draft proposal covering throwing subscripts. You can 
> mention it's existence, but I don't see a reason to say much. 
> 
>  - Doug
> 
> 
>> 
>> On Wed, Jan 11, 2017 at 8:52 PM, John McCall via swift-evolution 
>> > wrote:
>>> On Jan 11, 2017, at 1:32 PM, Erica Sadun via swift-evolution 
>>> > wrote:
 On Jan 11, 2017, at 12:26 AM, Chris Lattner via swift-evolution 
 > wrote:
 
 On Jan 10, 2017, at 11:40 AM, Douglas Gregor via swift-evolution 
 > wrote:
>> On Jan 10, 2017, at 10:34 AM, Michael Ilseman via swift-evolution 
>> > wrote:
>> 
>> [Forgot to CC swift-evolution the first time]
>> 
>> When this came up last, it was seen as more so a bug in the current 
>> implementation, rather than an explicit choice. There's no need for a 
>> proposal, just a JIRA: 
>> https://bugs.swift.org/browse/SR-115?jql=text%20~%20%22Generic%20subscript%22
>>  
>> 
>>  
> 
> It’s a nontrivial new user-facing feature with new syntax in the 
> language, so it’ll need a proposal. ‘twould be good for the proposal to 
> link to the JIRA ticket.
> 
> I’ve only heard positive reactions toward this feature, and it’s 
> something that the standard library could make good use of.
 
 +1, this would be clearly great to happen.
 
 -Chris
>>> 
>>> 
>>> I apologize for adding to this topic rather than starting a new one, but I 
>>> figure people interested in subscripts would be more likely to see my 
>>> question:
>>> 
>>> Is there a good reason subscripts cannot throw? Right now you can create a 
>>> [safe: index] subscript to return an optional but you can't create one that 
>>> returns an unwrapped value or throws.
>> 
>> Throwing accessors are mostly straightforward, but there is a big conceptual 
>> question: what happens if an accessor is called during error propagation?  
>> For example:
>> 
>>   objectWithThrowingSubscriptSetter[index].mutatingMethodThatCanThrow()
>> 
>> If the method throws, we currently still call the setter in order to finish 
>> the access.  If the setter can throw, then, we might end up with multiple 
>> errors being thrown at the same time, which isn't good — the language is put 
>> in the awkward position of having to invent an arbitrary resolution 
>> mechanism.
>> 
>> You might ask: why do we call the setter if an error is thrown?  Well, it's 
>> complicated.  One reason is that the implementation technique we use for 
>> generic access to subscripts and properties — accesses where we don't know 
>> how the subscript/property is implemented — doesn't know how to distinguish 
>> between *finishing* an access normally and *aborting* an access abnormally.  
>> Some kinds of property/subscript implementation — ones currently reserved 
>> for the standard library, but likely to be eventually offered to users in 
>> some form — depend on doing extra work no matter how the access is 
>> terminated, e.g. to release a buffer pointer.  (In fact, in general this 
>> applies even to get/set implementations, because even if we decided not to 
>> call the setter when an error was thrown, we would at least need to destroy 
>> the index argument that we were going to pass to the setter.)  In order to 
>> get consistent behavior between generic and 

Re: [swift-evolution] Generic Subscripts

[Slava Pestov via swift-evolution]

> On Jan 12, 2017, at 9:56 AM, Gwendal Roué via swift-evolution 
>  wrote:
> 
> Hello Chris, thanks for this draft!
> 
> May I suggest that the introduction mentions genericity on return type as 
> well?
> 
> subscript(_ index: Int) -> T
> 
> (I have database rows in mind.)

Yeah, there’s no reason to restrict it to either just the index or element type.

Slava

> 
> Gwendal
> 
>> Le 12 janv. 2017 à 18:53, Chris Eidhof via swift-evolution 
>> > a écrit :
>> 
>> Ok, I've got a draft up as a gist: 
>> https://gist.github.com/chriseidhof/6c681677d44903045587bf75fb17eb25 
>> 
>> 
>> Before I submit it, could someone let me know if adding generics to 
>> subscripts would influence the ABI? ( still feel pretty clueless in that 
>> area).
>> 
>> Thanks!
>> 
>> On Thu, Jan 12, 2017 at 8:57 AM, Douglas Gregor via swift-evolution 
>> > wrote:
>> 
>> 
>> Sent from my iPhone
>> 
>> On Jan 11, 2017, at 11:05 PM, Chris Eidhof via swift-evolution 
>> > wrote:
>> 
>>> Okay,
>>> 
>>> I agree that throwing subscripts would be great to have. Likewise, 
>>> generic(and maybe even throwing) properties could be useful. However, I 
>>> think that for this proposal, it makes more sense to focus on just generic 
>>> subscripts, and mention throwing subscripts as "future improvements"? 
>> 
>> There's already a draft proposal covering throwing subscripts. You can 
>> mention it's existence, but I don't see a reason to say much. 
>> 
>>  - Doug
>> 
>> 
>>> 
>>> On Wed, Jan 11, 2017 at 8:52 PM, John McCall via swift-evolution 
>>> > wrote:
 On Jan 11, 2017, at 1:32 PM, Erica Sadun via swift-evolution 
 > wrote:
> On Jan 11, 2017, at 12:26 AM, Chris Lattner via swift-evolution 
> > wrote:
> 
> On Jan 10, 2017, at 11:40 AM, Douglas Gregor via swift-evolution 
> > wrote:
>>> On Jan 10, 2017, at 10:34 AM, Michael Ilseman via swift-evolution 
>>> > wrote:
>>> 
>>> [Forgot to CC swift-evolution the first time]
>>> 
>>> When this came up last, it was seen as more so a bug in the current 
>>> implementation, rather than an explicit choice. There's no need for a 
>>> proposal, just a JIRA: 
>>> https://bugs.swift.org/browse/SR-115?jql=text%20~%20%22Generic%20subscript%22
>>>  
>>> 
>>>  
>> 
>> It’s a nontrivial new user-facing feature with new syntax in the 
>> language, so it’ll need a proposal. ‘twould be good for the proposal to 
>> link to the JIRA ticket.
>> 
>> I’ve only heard positive reactions toward this feature, and it’s 
>> something that the standard library could make good use of.
> 
> +1, this would be clearly great to happen.
> 
> -Chris
 
 
 I apologize for adding to this topic rather than starting a new one, but I 
 figure people interested in subscripts would be more likely to see my 
 question:
 
 Is there a good reason subscripts cannot throw? Right now you can create a 
 [safe: index] subscript to return an optional but you can't create one 
 that returns an unwrapped value or throws.
>>> 
>>> Throwing accessors are mostly straightforward, but there is a big 
>>> conceptual question: what happens if an accessor is called during error 
>>> propagation?  For example:
>>> 
>>>   objectWithThrowingSubscriptSetter[index].mutatingMethodThatCanThrow()
>>> 
>>> If the method throws, we currently still call the setter in order to finish 
>>> the access.  If the setter can throw, then, we might end up with multiple 
>>> errors being thrown at the same time, which isn't good — the language is 
>>> put in the awkward position of having to invent an arbitrary resolution 
>>> mechanism.
>>> 
>>> You might ask: why do we call the setter if an error is thrown?  Well, it's 
>>> complicated.  One reason is that the implementation technique we use for 
>>> generic access to subscripts and properties — accesses where we don't know 
>>> how the subscript/property is implemented — doesn't know how to distinguish 
>>> between *finishing* an access normally and *aborting* an access abnormally. 
>>>  Some kinds of property/subscript implementation — ones currently reserved 
>>> for the standard library, but likely to be eventually offered to users in 
>>> some form — depend on doing extra work no matter how the access is 
>>> 

[swift-evolution] Range and ClosedRange

[David Hart via swift-evolution]

Hello,

Since the release of Swift 3, I’ve seen quite a few people (me included) 
experience a lot of friction with the new types for representing ranges. I’ve 
seen people confused when writing an API that takes a Range as argument but 
then can’t pass in a ClosedRange. Sometimes this can be fixed because the API 
should be written against a more general protocol, but sometimes that’s not the 
case.

Those new types definitely seem to cause more problems than they fixed (the 
Int.max problem). Has the Standard Library team put any thought into this?

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

Re: [swift-evolution] Update on the Swift Project Lead

[J.E. Schotsman via swift-evolution]

> On 12 Jan 2017, at 18:58, Derrick Ho wrote:
> 
> I look forward to seeing tesla car apps that can be written in swift.

Only for cars that ride in the fast lane.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Consolidate Code for Each Case in Enum

[Jay Abbott via swift-evolution]

Thanks for pointing this out Tim. I had actually read the whole thread but
over a few days between other things and must have missed the relevant
updates.

I think you may be reacting to the very first draft. `extension` isn't used
> at all in the newest draft, and no code can exist outside the enum. In
> fact, there's a fair amount of similarity to your idea in the newest
> proposal.
>
> https://gist.github.com/timshadel/5a5a8e085a6fd591483a933e603c2562
>
>
Oh yes - this is much better! Lovely in fact. Although it does lose the
benefit of at-a-glance understanding of the cases present in the enum when
they are on one line each (when the code gets bigger than in the example
they will be quite a way apart).
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Generic Subscripts

[Gwendal Roué via swift-evolution]

Hello Chris, thanks for this draft!

May I suggest that the introduction mentions genericity on return type as well?

subscript(_ index: Int) -> T

(I have database rows in mind.)

Gwendal

> Le 12 janv. 2017 à 18:53, Chris Eidhof via swift-evolution 
>  a écrit :
> 
> Ok, I've got a draft up as a gist: 
> https://gist.github.com/chriseidhof/6c681677d44903045587bf75fb17eb25 
> 
> 
> Before I submit it, could someone let me know if adding generics to 
> subscripts would influence the ABI? ( still feel pretty clueless in that 
> area).
> 
> Thanks!
> 
> On Thu, Jan 12, 2017 at 8:57 AM, Douglas Gregor via swift-evolution 
> > wrote:
> 
> 
> Sent from my iPhone
> 
> On Jan 11, 2017, at 11:05 PM, Chris Eidhof via swift-evolution 
> > wrote:
> 
>> Okay,
>> 
>> I agree that throwing subscripts would be great to have. Likewise, 
>> generic(and maybe even throwing) properties could be useful. However, I 
>> think that for this proposal, it makes more sense to focus on just generic 
>> subscripts, and mention throwing subscripts as "future improvements"? 
> 
> There's already a draft proposal covering throwing subscripts. You can 
> mention it's existence, but I don't see a reason to say much. 
> 
>  - Doug
> 
> 
>> 
>> On Wed, Jan 11, 2017 at 8:52 PM, John McCall via swift-evolution 
>> > wrote:
>>> On Jan 11, 2017, at 1:32 PM, Erica Sadun via swift-evolution 
>>> > wrote:
 On Jan 11, 2017, at 12:26 AM, Chris Lattner via swift-evolution 
 > wrote:
 
 On Jan 10, 2017, at 11:40 AM, Douglas Gregor via swift-evolution 
 > wrote:
>> On Jan 10, 2017, at 10:34 AM, Michael Ilseman via swift-evolution 
>> > wrote:
>> 
>> [Forgot to CC swift-evolution the first time]
>> 
>> When this came up last, it was seen as more so a bug in the current 
>> implementation, rather than an explicit choice. There's no need for a 
>> proposal, just a JIRA: 
>> https://bugs.swift.org/browse/SR-115?jql=text%20~%20%22Generic%20subscript%22
>>  
>> 
>>  
> 
> It’s a nontrivial new user-facing feature with new syntax in the 
> language, so it’ll need a proposal. ‘twould be good for the proposal to 
> link to the JIRA ticket.
> 
> I’ve only heard positive reactions toward this feature, and it’s 
> something that the standard library could make good use of.
 
 +1, this would be clearly great to happen.
 
 -Chris
>>> 
>>> 
>>> I apologize for adding to this topic rather than starting a new one, but I 
>>> figure people interested in subscripts would be more likely to see my 
>>> question:
>>> 
>>> Is there a good reason subscripts cannot throw? Right now you can create a 
>>> [safe: index] subscript to return an optional but you can't create one that 
>>> returns an unwrapped value or throws.
>> 
>> Throwing accessors are mostly straightforward, but there is a big conceptual 
>> question: what happens if an accessor is called during error propagation?  
>> For example:
>> 
>>   objectWithThrowingSubscriptSetter[index].mutatingMethodThatCanThrow()
>> 
>> If the method throws, we currently still call the setter in order to finish 
>> the access.  If the setter can throw, then, we might end up with multiple 
>> errors being thrown at the same time, which isn't good — the language is put 
>> in the awkward position of having to invent an arbitrary resolution 
>> mechanism.
>> 
>> You might ask: why do we call the setter if an error is thrown?  Well, it's 
>> complicated.  One reason is that the implementation technique we use for 
>> generic access to subscripts and properties — accesses where we don't know 
>> how the subscript/property is implemented — doesn't know how to distinguish 
>> between *finishing* an access normally and *aborting* an access abnormally.  
>> Some kinds of property/subscript implementation — ones currently reserved 
>> for the standard library, but likely to be eventually offered to users in 
>> some form — depend on doing extra work no matter how the access is 
>> terminated, e.g. to release a buffer pointer.  (In fact, in general this 
>> applies even to get/set implementations, because even if we decided not to 
>> call the setter when an error was thrown, we would at least need to destroy 
>> the index argument that we were going to pass to the setter.)  In order to 
>> get consistent behavior between generic and 

Re: [swift-evolution] Generic Subscripts

[Matthew Johnson via swift-evolution]

Thanks for putting this together!  I’m looking forward to seeing this make it 
into the language!

> On Jan 12, 2017, at 11:53 AM, Chris Eidhof via swift-evolution 
>  wrote:
> 
> Ok, I've got a draft up as a gist: 
> https://gist.github.com/chriseidhof/6c681677d44903045587bf75fb17eb25 
> 
> 
> Before I submit it, could someone let me know if adding generics to 
> subscripts would influence the ABI? ( still feel pretty clueless in that 
> area).
> 
> Thanks!
> 
> On Thu, Jan 12, 2017 at 8:57 AM, Douglas Gregor via swift-evolution 
> > wrote:
> 
> 
> Sent from my iPhone
> 
> On Jan 11, 2017, at 11:05 PM, Chris Eidhof via swift-evolution 
> > wrote:
> 
>> Okay,
>> 
>> I agree that throwing subscripts would be great to have. Likewise, 
>> generic(and maybe even throwing) properties could be useful. However, I 
>> think that for this proposal, it makes more sense to focus on just generic 
>> subscripts, and mention throwing subscripts as "future improvements"? 
> 
> There's already a draft proposal covering throwing subscripts. You can 
> mention it's existence, but I don't see a reason to say much. 
> 
>  - Doug
> 
> 
>> 
>> On Wed, Jan 11, 2017 at 8:52 PM, John McCall via swift-evolution 
>> > wrote:
>>> On Jan 11, 2017, at 1:32 PM, Erica Sadun via swift-evolution 
>>> > wrote:
 On Jan 11, 2017, at 12:26 AM, Chris Lattner via swift-evolution 
 > wrote:
 
 On Jan 10, 2017, at 11:40 AM, Douglas Gregor via swift-evolution 
 > wrote:
>> On Jan 10, 2017, at 10:34 AM, Michael Ilseman via swift-evolution 
>> > wrote:
>> 
>> [Forgot to CC swift-evolution the first time]
>> 
>> When this came up last, it was seen as more so a bug in the current 
>> implementation, rather than an explicit choice. There's no need for a 
>> proposal, just a JIRA: 
>> https://bugs.swift.org/browse/SR-115?jql=text%20~%20%22Generic%20subscript%22
>>  
>> 
>>  
> 
> It’s a nontrivial new user-facing feature with new syntax in the 
> language, so it’ll need a proposal. ‘twould be good for the proposal to 
> link to the JIRA ticket.
> 
> I’ve only heard positive reactions toward this feature, and it’s 
> something that the standard library could make good use of.
 
 +1, this would be clearly great to happen.
 
 -Chris
>>> 
>>> 
>>> I apologize for adding to this topic rather than starting a new one, but I 
>>> figure people interested in subscripts would be more likely to see my 
>>> question:
>>> 
>>> Is there a good reason subscripts cannot throw? Right now you can create a 
>>> [safe: index] subscript to return an optional but you can't create one that 
>>> returns an unwrapped value or throws.
>> 
>> Throwing accessors are mostly straightforward, but there is a big conceptual 
>> question: what happens if an accessor is called during error propagation?  
>> For example:
>> 
>>   objectWithThrowingSubscriptSetter[index].mutatingMethodThatCanThrow()
>> 
>> If the method throws, we currently still call the setter in order to finish 
>> the access.  If the setter can throw, then, we might end up with multiple 
>> errors being thrown at the same time, which isn't good — the language is put 
>> in the awkward position of having to invent an arbitrary resolution 
>> mechanism.
>> 
>> You might ask: why do we call the setter if an error is thrown?  Well, it's 
>> complicated.  One reason is that the implementation technique we use for 
>> generic access to subscripts and properties — accesses where we don't know 
>> how the subscript/property is implemented — doesn't know how to distinguish 
>> between *finishing* an access normally and *aborting* an access abnormally.  
>> Some kinds of property/subscript implementation — ones currently reserved 
>> for the standard library, but likely to be eventually offered to users in 
>> some form — depend on doing extra work no matter how the access is 
>> terminated, e.g. to release a buffer pointer.  (In fact, in general this 
>> applies even to get/set implementations, because even if we decided not to 
>> call the setter when an error was thrown, we would at least need to destroy 
>> the index argument that we were going to pass to the setter.)  In order to 
>> get consistent behavior between generic and non-generic accesses, we've just 
>> generally been finishing the access all the time.
>> 
>> I 

Re: [swift-evolution] Allow ' in variable/constant names?

[Jay Abbott via swift-evolution]

Georgios - the problem with that character is that it's an apostrophe in
Unicode, not a single-quote. It was originally overloaded as both in ASCII
though hence commonly used as either, especially in programming languages.
I'm definitely with Ted Clancy on this one:
https://tedclancy.wordpress.com/2015/06/03/which-unicode-character-should-represent-the-english-apostrophe-and-why-the-unicode-committee-is-very-wrong/

I generally don't care what characters my editor/email client/browser/etc.
use when I type ' on the keyboard, because a human reader will understand
it, so I just do the quickest/easiest thing. But when I'm writing a TeX
document I take care to use an apostrophe where needed and left/right
single quotation marks where needed. And for coding I'd like to be precise,
specific, unambiguous, and technically correct, so either single or double
quotation marks (or ‹ and ›) would be acceptable for character literals. If
compiler can cope with double quotes for both string and character literals
in an unambiguous way then that's fine too.

On Thu, 12 Jan 2017 at 14:35 Georgios Moschovitis <
george.moschovi...@icloud.com> wrote:

> So yeah, solution is to make characters easier to type, not modify the
> language.
>
>
> +1
>
> If like me you don't have such a keyboard, you can always use ctrl+⌘+
>  and type ‘PRIME’ to find it, then pick it from recently
> used/favourites.
>
> Regarding the other point, I agree that character literals would be handy,
> but again I’m not sure if apostrophe is the right character to indicate it.
> Although it is familiar, perhaps LEFT SINGLE QUOTATION MARK and RIGHT
> SINGLE QUOTATION MARK would be better, they can be relatively easily typed
> with ⎇+] and ⎇+⇧+] respectively. Xcode could also convert two apostrophes
> into ‘’ for you and your fingers would quickly learn to type ' ' ← ‹char›.
>
> I think the single (ASCII) quote is standard enough for use as a character
> delimiter.
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Generic Subscripts

[Chris Eidhof via swift-evolution]

Ok, I've got a draft up as a gist:
https://gist.github.com/chriseidhof/6c681677d44903045587bf75fb17eb25

Before I submit it, could someone let me know if adding generics to
subscripts would influence the ABI? ( still feel pretty clueless in that
area).

Thanks!

On Thu, Jan 12, 2017 at 8:57 AM, Douglas Gregor via swift-evolution <
swift-evolution@swift.org> wrote:

>
>
> Sent from my iPhone
>
> On Jan 11, 2017, at 11:05 PM, Chris Eidhof via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Okay,
>
> I agree that throwing subscripts would be great to have. Likewise,
> generic(and maybe even throwing) properties could be useful. However, I
> think that for this proposal, it makes more sense to focus on just generic
> subscripts, and mention throwing subscripts as "future improvements"?
>
>
> There's already a draft proposal covering throwing subscripts. You can
> mention it's existence, but I don't see a reason to say much.
>
>  - Doug
>
>
>
> On Wed, Jan 11, 2017 at 8:52 PM, John McCall via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> On Jan 11, 2017, at 1:32 PM, Erica Sadun via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> On Jan 11, 2017, at 12:26 AM, Chris Lattner via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> On Jan 10, 2017, at 11:40 AM, Douglas Gregor via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> On Jan 10, 2017, at 10:34 AM, Michael Ilseman via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> [Forgot to CC swift-evolution the first time]
>>
>> When this came up last, it was seen as more so a bug in the current
>> implementation, rather than an explicit choice. There's no need for a
>> proposal, just a JIRA: https://bugs.swift.org/b
>> rowse/SR-115?jql=text%20~%20%22Generic%20subscript%22
>>
>>
>> It’s a nontrivial new user-facing feature with new syntax in the
>> language, so it’ll need a proposal. ‘twould be good for the proposal to
>> link to the JIRA ticket.
>>
>> I’ve only heard positive reactions toward this feature, and it’s
>> something that the standard library could make good use of.
>>
>>
>> +1, this would be clearly great to happen.
>>
>> -Chris
>>
>>
>>
>> I apologize for adding to this topic rather than starting a new one, but
>> I figure people interested in subscripts would be more likely to see my
>> question:
>>
>> Is there a good reason subscripts cannot throw? Right now you can create
>> a [safe: index] subscript to return an optional but you can't create one
>> that returns an unwrapped value or throws.
>>
>>
>> Throwing accessors are mostly straightforward, but there is a big
>> conceptual question: what happens if an accessor is called during error
>> propagation?  For example:
>>
>>   objectWithThrowingSubscriptSetter[index].mutatingMethodThatCanThrow()
>>
>> If the method throws, we currently still call the setter in order to
>> finish the access.  If the setter can throw, then, we might end up with
>> multiple errors being thrown at the same time, which isn't good — the
>> language is put in the awkward position of having to invent an arbitrary
>> resolution mechanism.
>>
>> You might ask: why do we call the setter if an error is thrown?  Well,
>> it's complicated.  One reason is that the implementation technique we use
>> for generic access to subscripts and properties — accesses where we don't
>> know how the subscript/property is implemented — doesn't know how to
>> distinguish between *finishing* an access normally and *aborting* an access
>> abnormally.  Some kinds of property/subscript implementation — ones
>> currently reserved for the standard library, but likely to be eventually
>> offered to users in some form — depend on doing extra work no matter how
>> the access is terminated, e.g. to release a buffer pointer.  (In fact, in
>> general this applies even to get/set implementations, because even if we
>> decided not to call the setter when an error was thrown, we would at least
>> need to destroy the index argument that we were going to pass to the
>> setter.)  In order to get consistent behavior between generic and
>> non-generic accesses, we've just generally been finishing the access all
>> the time.
>>
>> I think it would be possible to teach this generic mechanism the
>> difference between finishing and aborting an access, and thus to avoid
>> calling setters or otherwise doing arbitrary work that's allowed to throw
>> during an abort.  However, we would first have to decide that those are
>> indeed the correct semantics and that setters should not be called after a
>> throw, and that would be a change in behavior.
>>
>> John.
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>
>
> --
> Chris Eidhof
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> 

Re: [swift-evolution] Allow ' in variable/constant names?

[Georgios Moschovitis via swift-evolution]

> So yeah, solution is to make characters easier to type, not modify the 
> language.

+1

> If like me you don't have such a keyboard, you can always use ctrl+⌘+ 
> and type ‘PRIME’ to find it, then pick it from recently used/favourites.
> Regarding the other point, I agree that character literals would be handy, 
> but again I’m not sure if apostrophe is the right character to indicate it. 
> Although it is familiar, perhaps LEFT SINGLE QUOTATION MARK and RIGHT SINGLE 
> QUOTATION MARK would be better, they can be relatively easily typed with ⎇+] 
> and ⎇+⇧+] respectively. Xcode could also convert two apostrophes into ‘’ for 
> you and your fingers would quickly learn to type ' ' ← ‹char›.
> 

I think the single (ASCII) quote is standard enough for use as a character 
delimiter.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Consolidate Code for Each Case in Enum

[Anton Zhilin via swift-evolution]

2017-01-12 0:51 GMT+03:00 David Sweeris :
>
> I don't understand the lines in the struct version where you assign
> something to `self`. What is ".invalid", for example? I thought you'd
> removed the enum altogether.
>

I totally overlooked it. That can't be done with protocols, scrap that
suggestion.

> But pattern matching on structs is impossible—we can change that with a
> separate proposal. For example, we can allow destructuring
> structs/enums/classes by any combination of their properties:
>
> struct S {
> var foo: Int
> var bar: Double
> var buz: String { return "42" }
> }
> let s = S(foo: 42, bar: 42.0)
> let S(foo: x, buz: z) = s
>
> I was under the impression that we could switch over anything that had the
> `~=` operator defined. Is that not the case?
>

Well, this one is a bit different, but it's horribly off-topic for this
thread.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Consolidate Code for Each Case in Enum

[Tim Shadel via swift-evolution]

I think you may be reacting to the very first draft. `extension` isn't used at 
all in the newest draft, and no code can exist outside the enum. In fact, 
there's a fair amount of similarity to your idea in the newest proposal.

https://gist.github.com/timshadel/5a5a8e085a6fd591483a933e603c2562


> On Jan 11, 2017, at 6:43 PM, Jay Abbott via swift-evolution 
>  wrote:
> 
> I like the idea behind this, but I think the proposed syntax abuses 
> extension, which applies to types not individual cases. Putting the code 
> outside the enum also seems wrong, and it’s difficult to see how the compiler 
> would handle it, in particular ensuring exhaustiveness. So I have come up 
> with an alternate syntax using the example from the proposal that I think 
> works a bit better (or at least might inspire someone else to improve it 
> further):
> 
> enum TokenState {
> case expired(at: Date)
> case validated(token: String)
> 
> caseprotocol { // (1)
> mutating func react(to event: Event)
> var description: String
> }
> caseimpl<.expired(let at)> { // (2)
> var description: String {
> return "Expired at \(at)"
> }
> mutating func react(to event: Event) {
> switch event {
> case _ as TokenRefreshed:
> self = .validated(token: event.token)
> default: break
> }
> }
> }
> caseimpl<.validated(let token)> { // (3)
> var description: String {
> return "Token \(token) has been validated."
> }
> mutating func react(to event: Event) {
> switch event {
> case _ as TokenRejected:
> self = .expired(at: Date())
> case _ as UserLoggedOut:
> self = .expired(at: Date())
> default: break
> }
> }
> }
> // (4)
> }
> I find this easier to parse manually, and I think the compiler would too…
> 
> At (1) it is equivalent to defining a normal protocol outside the enum. The 
> enum itself would implicitly conform to this protocol. Calculated properties 
> would be implicitly get-only in the protocol.
> At (2) and (3) this would be equivalent to defining a static object that 
> conforms to a compiler-modified version of the protocol, with static 
> implementations of the getters/functions. Mutating functions would have an 
> inout ref to self and they would all have any associated values sent in as 
> per the let in the caseimpl declaration. The body would come directly from 
> the programmer code.
> At (4) the compiler would generate the enum’s implementation to conform to 
> the protocol, this would switch on self and call the appropriate static 
> functions. As per the original proposal.
> It might be good if you don’t have to repeat all the func signatures in each 
> caseimpl - I considered a different syntax where you defined a casefunc 
> (similar to a typealias) like casefunc ReactTo = mutating func react(to 
> event: Event) then in the caseimpl you could just do ReactTo = { func body 
> here } but it didn’t seem to fit. Hopefully someone else will have some ideas 
> to reduce the repetition.
> 
> ___
> 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