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

-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

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

+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,

Re: [swift-evolution] Generic Subscripts

> 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 >>>

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

> 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

Re: [swift-evolution] Generic Subscripts

> 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: >>

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

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

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

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

Re: [swift-evolution] Range and ClosedRange

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

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

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

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

> 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

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

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

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

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

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

@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

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

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

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

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

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

> 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

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

> 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 >

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

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

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

> 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 { >

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

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

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

> 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,

[swift-evolution] Throws? and throws!

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

Re: [swift-evolution] Range and ClosedRange

> 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

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

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,

Re: [swift-evolution] Range and ClosedRange

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

Re: [swift-evolution] Range and ClosedRange

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

Re: [swift-evolution] Range and ClosedRange

Hi David, There were a few instances where this topic or similar came up at the Swift Evolution List and Swift Users List .

Re: [swift-evolution] Generic Subscripts

> 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

Re: [swift-evolution] Generic Subscripts

> 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 > > >

Re: [swift-evolution] Generic Subscripts

> 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

[swift-evolution] Range and ClosedRange

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

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

> 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

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

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

Re: [swift-evolution] Generic Subscripts

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 : >

Re: [swift-evolution] Generic Subscripts

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: >

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

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:

Re: [swift-evolution] Generic Subscripts

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,

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

> 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

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

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

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

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