Re: [swift-evolution] Move placement of 'throws' statement

On Dec 26, 2016, at 2:55 PM, Dave Abrahams via swift-evolution wrote: >> >> // Move `throws` to the end >> func baz() -> String throws > > I agree that reads much better. This doesn’t work unless you’re willing to break consistency with function type syntax, or if you’re willing to make funct

Re: [swift-evolution] Move placement of 'throws' statement

I don't know how this became a discussion for specifying errors when throwing but +1 on the off chance that this thread is actually used to gauge interest. On Tue, Dec 27, 2016 at 10:27 PM, Daniel Leping via swift-evolution < swift-evolution@swift.org> wrote: > -1 for checked exceptions. Don't ma

Re: [swift-evolution] Move placement of 'throws' statement

-1 for checked exceptions. Don't make it java. For thous interested why, just google. It's common frustration in Java world so the info is everywhere. In general you end up with wrapping and wrapping and wrapping the fine grained exceptions into general ones. And you have more exception classes th

Re: [swift-evolution] [SwiftPM] Proposal: Add support for test-only dependencies

The need for a feature such as this was pointed out some time ago. A proposal to allow dependencies to be declared with increased granularity has already been written, reviewed, and accepted! Here it is: https://github.com/apple/swift-evolution/blob/master/proposa ls/0146-package-manager-product-de

Re: [swift-evolution] [SwiftPM] Proposal: Add support for test-only dependencies

Does anyone else have any thoughts on this, or should I go ahead an assemble a PR? -thislooksfun (tlf) > On Dec 26, 2016, at 1:56 PM, thislooksfun wrote: > > (I think this is the right place for this suggestion, but please let me know > if I'm mistaken) > > There is currently no supported wa

Re: [swift-evolution] Move placement of 'throws' statement

That's fair. The reasoning I read about mentioned making it easier for newcomers, but it's very possible that was a 3rd party opinion (I don't remember). I certainly did not intend to upset anyone. Either way, I do still believe that the current placement / syntax isn't entirely clear. -thislo

Re: [swift-evolution] Move placement of 'throws' statement

> > Under the hood each expression passed to "throw" could make something like > > enum bar_abcdefj_throw { > case genericError // all NSError go here > case MyEnumErrorFirstError > } > > Where abcdefj is unique characters. > > > This enum would only be visible through the catch blocks which w

Re: [swift-evolution] Move placement of 'throws' statement

FYI, here's the December 2015 discussion on typed throws: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003284.html On Tue, Dec 27, 2016 at 4:57 PM, Tino Heth via swift-evolution < swift-evolution@swift.org> wrote: > Right now, we basically have "throws Error", and no ma

Re: [swift-evolution] Move placement of 'throws' statement

Agree, it doesn't seem to read naturally at first glance. However, one way perhaps to think about the rationale for this is that `throws` does "fit" logically between the parameters and the return type: a function that throws might take certain arguments and, by throwing, never return a value of t

Re: [swift-evolution] Move placement of 'throws' statement

>> Right now, we basically have "throws Error", and no matter what is actually >> thrown, we can always catch exhaustive by keeping the statement unspecific. > > True, but for me it's more about knowing what a method can throw That's always possible if throw can be annotated with a list of errors

Re: [swift-evolution] [Pitch] [Phase 2] New `permuting` keyword for protocols

On Tue, Dec 27, 2016 at 1:27 PM, Adrian Zubarev < adrian.zuba...@devandartist.com> wrote: > I’m not sure I’m following your point here. Could you provide a simple and > short code sample please? > So I guess I'm having trouble understanding the motivating use case for your idea. As I understand it

Re: [swift-evolution] Move placement of 'throws' statement

If some form of explicitly typed errors is added, my initial problem goes away. The only reason I suggested the move in the first place, is that a combination of `throws` and return (-> T) statements makes it look like there is already explicitly typed errors, especially to those of us coming fr

Re: [swift-evolution] Move placement of 'throws' statement

> On Dec 27, 2016, at 06:38, Anton Zhilin via swift-evolution > wrote: > On syntax, I feel like this is the obvious one: > > func convert(_: String) -> Int throws IntegerConversionError I agree this is the best syntax, though I might add a comma in there for even more readability: func conver

Re: [swift-evolution] Move placement of 'throws' statement

Moving “throws” or changing it to a prefix “throwing” as was originally suggested are relatively minor, reasonable improvements. We do need to consider if it restricts future language evolution (such as potentially listing all of the thrown errors), so that’s why it’s relevant to talk a little

Re: [swift-evolution] Move placement of 'throws' statement

Right. it should support the normal return type as well as the errors. Here is my revised suggestion. func foo() throws -> String {} switch try foo() { case .returnValue(let value): // do something with value case .MyEnumErrorFirstError: // handle error default: // handle NSError } On Tue, Dec

Re: [swift-evolution] Move placement of 'throws' statement

On Tue, Dec 27, 2016 at 4:03 PM, Derrick Ho via swift-evolution < swift-evolution@swift.org> wrote: > I suppose "throws" could be enhanced to produce a compiletime enum > > func bar() throws { > throw NSError() > throw MyEnumError.firstError > } > > Under the hood each expression passed to "throw"

Re: [swift-evolution] Move placement of 'throws' statement

I suppose "throws" could be enhanced to produce a compiletime enum func bar() throws { throw NSError() throw MyEnumError.firstError } Under the hood each expression passed to "throw" could make something like enum bar_abcdefj_throw { case genericError // all NSError go here case MyEnumErrorFirst

Re: [swift-evolution] Move placement of 'throws' statement

> On 27 Dec 2016, at 13:21, Haravikk wrote: > > >> On 27 Dec 2016, at 10:56, Derrick Ho via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> Daniel Leping, I am unfamiliar with java. Do you have any resources that >> describe the nightmare in detail? > > I think the proble

Re: [swift-evolution] URL Literals

> On Dec 22, 2016, at 11:39 PM, Jonathan Hull wrote: > > >> On Dec 20, 2016, at 12:29 PM, David Sweeris > > wrote: >> >>> >>> On Dec 20, 2016, at 2:11 AM, Jonathan Hull via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> Yes, I agree. I am

Re: [swift-evolution] [Pitch] [Phase 2] New `permuting` keyword for protocols

I’m not sure I’m following your point here. Could you provide a simple and short code sample please? --  Adrian Zubarev Sent with Airmail Am 27. Dezember 2016 um 19:24:15, Xiaodi Wu (xiaodi...@gmail.com) schrieb: What do you think of using a value type as a subtype, and having an initializer

Re: [swift-evolution] [Pitch] [Phase 2] New `permuting` keyword for protocols

What do you think of using a value type as a subtype, and having an initializer that supplies defaults? It can only be used once, and after that you have to create a new value. Does that not satisfy your compile-time needs? On Tue, Dec 27, 2016 at 13:20 Adrian Zubarev < adrian.zuba...@devandartist.

Re: [swift-evolution] [Pitch] Add the DefaultConstructible protocol to the standard library

-1 1) There is no semantic meaning to empty initializers. 2) It is a simple protocol to create and apply for specific (and semantically meaningful) purposes 3) This would be a core protocol and I defer to the team. when it comes to low-level protocols. This seems to be in conflict with their v

Re: [swift-evolution] [Pitch] [Phase 2] New `permuting` keyword for protocols

Do you have any suggestions on how this area could be solved differently and less complex as it seems to be here? :) I’m open minded and I’d really appreciate if we’d have some language support for this problem. --  Adrian Zubarev Sent with Airmail Am 27. Dezember 2016 um 18:49:22, Xiaodi Wu

Re: [swift-evolution] Move placement of 'throws' statement

> On 27 Dec 2016, at 13:43, Tino Heth <2...@gmx.de> wrote: > Imho this is no problem: > Right now, we basically have "throws Error", and no matter what is actually > thrown, we can always catch exhaustive by keeping the statement unspecific. True, but for me it's more about knowing what a method

Re: [swift-evolution] [Pitch] [Phase 2] New `permuting` keyword for protocols

TBH, I think you're trying to solve this problem in a very complicated way. What you're describing screams out for its own value subtype with let variables and an initializer that will provide defaults. I'm skeptical such a complicated design as you propose is necessary to achieve what you want. O

Re: [swift-evolution] Move placement of 'throws' statement

Imho the concept of checked exceptions was ok, but the important information is the category of error - in how to respond and how to report to the user. Use of a type system encourages an ontology of errors by subsystem and not by appropriate programmatic response. You could have appropriate use

Re: [swift-evolution] [Proposal] Change (Dispatch)Data.withUnsafeBytes to use UnsafeMutableBufferPointer

+1, I have run into this awkwardness myself and wished the API were different, exactly as you outline. On Tue, Dec 27, 2016 at 03:16 Karl via swift-evolution < swift-evolution@swift.org> wrote: > Looking for feedback before submitting a PR: > https://github.com/karwa/swift-evolution/blob/corelib

Re: [swift-evolution] Move placement of 'throws' statement

Not in a position to search for this myself at the moment, but for those unaware, somewhere on this list archive are posts from the core team describing the rationale for using throws instead of Result, and for having untyped throws by default with the door open for typed throws in the future as an

Re: [swift-evolution] Move placement of 'throws' statement

Although I have only partially vetted it myself, this came up for a google search: http://wiki.c2.com/?JavaExceptionsAreParticularlyEvil -DW Sent with my Thumbs > On Dec 27, 2016, at 5:56 AM, Derrick Ho via swift-evolution > wrote: > > Daniel Leping, I am unfamiliar with java. Do you have an

Re: [swift-evolution] Move placement of 'throws' statement

This proposal should be reviewed as a part of “typed throws” proposal, with the original PR prepared by David Owens. Typed throws won’t change anything about how many types can be thrown. Only one type/protocol will be specified in the function ty

Re: [swift-evolution] Move placement of 'throws' statement

> I think the problem really comes down to the inflexibility of it; if you > specify X, Y, and Z as throwable types, then all code calling that method > must handle those types in some way. Imho this is no problem: Right now, we basically have "throws Error", and no matter what is actually thro

Re: [swift-evolution] Move placement of 'throws' statement

Indeed, func baz() throws -> String is confusing. I do prefer these two alternatives: // Move `throws` to the end func baz() -> String throws // Change it to a prefix modifier (like `mutating`) throwing func baz() -> String I think I prefer the first one (throws at the very end). I wouldn’t mind

Re: [swift-evolution] Move placement of 'throws' statement

I have rarely caught up into these situations - if I end up with multiple types of error, I generally create a wrapper error type. For example, my networking code includes a NetworkError type which encompasses all the errors that can happen within Foundation or my own code. Could we not then in

Re: [swift-evolution] Move placement of 'throws' statement

> On 27 Dec 2016, at 10:56, Derrick Ho via swift-evolution > wrote: > > Daniel Leping, I am unfamiliar with java. Do you have any resources that > describe the nightmare in detail? I think the problem really comes down to the inflexibility of it; if you specify X, Y, and Z as throwable types

Re: [swift-evolution] Move placement of 'throws' statement

I think the clear middle ground is an approach where you *can* document the type, but let it not be required. Additionally, we can treat that at the calling end as a built time assurance of the type for error that is passed into the standard “catch { }”, and the compiler can also check that all

Re: [swift-evolution] Move placement of 'throws' statement

You need to list all exception types that can be thrown. And when you call another throwing method without handling the exception, it needs to be listed as well. Which means that you can end up with a method that has a list of a dozen of exception names that can be thrown. > On Dec 27, 2016, at

Re: [swift-evolution] Move placement of 'throws' statement

For me, handling Swift errors is a nightmare. You have no idea what to expect to be thrown. Some developers use NSError for use with Cocoa/UIKit (usually errors meant for user interaction), but some use enums that even can have a payload (extra info about the error). And you need to rely on the

Re: [swift-evolution] Move placement of 'throws' statement

Daniel Leping, I am unfamiliar with java. Do you have any resources that describe the nightmare in detail? On Tue, Dec 27, 2016 at 2:50 AM Tino Heth <2...@gmx.de> wrote: > -1 for specifying errors for throws. Please don't. Proven by practice in > java it's a nightmare. > > In Java, this topic is r

Re: [swift-evolution] Move placement of 'throws' statement

> -1 for specifying errors for throws. Please don't. Proven by practice in java > it's a nightmare. In Java, this topic is really interesting: It sounds like a great idea, but in real-life situations, afaics everyone hates checked exceptions. But Swift isn't Java, and our error handling is diff

Re: [swift-evolution] [Pitch] [Phase 2] New `permuting` keyword for protocols

Okay now I see your point there. :) Thank you Xiaodi and Tony. It’s an interesting approach you have there, but I see another problem with Self and - ProtocolName. Self does not refer to the current type returned from the protocol member. SE–0068 might help there, but as soon we’re working with

Re: [swift-evolution] Move placement of 'throws' statement

-1 for specifying errors for throws. Please don't. Proven by practice in java it's a nightmare. On Tue, 27 Dec 2016 at 14:51 Derrick Ho via swift-evolution < swift-evolution@swift.org> wrote: > I like the idea of "throw" having information about what might be thrown. > > Maybe you have an enum of

Re: [swift-evolution] Move placement of 'throws' statement

I like the idea of "throw" having information about what might be thrown. Maybe you have an enum of errors that may be thrown. How would the programmer know what might get thrown if they don't know the implementation details? While adding the throwing info in the comments is good, we might be bet

[swift-evolution] [Proposal] Change (Dispatch)Data.withUnsafeBytes to use UnsafeMutableBufferPointer

Looking for feedback before submitting a PR: https://github.com/karwa/swift-evolution/blob/corelibs-unsafebytes/proposals/-corelibs-unsafebytes.md — Change (Dispatch)Data.withUnsafeBytes to use UnsafeMutableBufferPointer Proposal: SE-