Re: [swift-evolution] [Discussion] mailing list alternative

(Sending this again because the first was accidentally offlist. Stupid reply-to headers.) +1 for Discourse from me as well. As for making a Swift-based site, server libraries do exist (Perfect, Vapor, Kitura, etc.), but afaik there is currently no built-in server support yet. -thislooksfun

Re: [swift-evolution] [Draft] Test-Only Package Dependencies and Targets

No problem, it's been inactive for a couple weeks since I've been really busy. And yeah, yours is more thorough. I didn't even consider adding a `testTargets` section. That alone is worth merging. -thislooksfun (tlf) > On Jan 24, 2017, at 11:55 PM, Robert Widmann

Re: [swift-evolution] [Draft] Test-Only Package Dependencies and Targets

As the author of the Add support for test-only dependencies thread, and the accompanying draft , this gets a big +1 from me.

Re: [swift-evolution] [Draft] Test-Only Package Dependencies and Targets

I still much prefer 'testDependencies/Targets'. You seem to be confusing this proposal with the (already accepted) Package Manager Product Definitions proposal. This proposal is strictly

Re: [swift-evolution] [Pitch] @testable private members

Whoops, accidentally sent this off-list. -thislooksfun (tlf) > On Feb 18, 2017, at 12:26 PM, thislooksfun wrote: > > Big +1 from me. I see no point in having to elevate access just to make sure > everything is working. > > -thislooksfun (tlf) > >> On Feb 18, 2017,

Re: [swift-evolution] Preconditions aborting process in server scenarios [was: Throws? and throws!]

I really hate to bring Java up, but I really do think it got at least one thing right with its error system, namely that one subset of error (namely `RuntimeException`), wouldn't be enforced by the compiler, but could optionally be caught. Namely, all of the following would then be valid: //

Re: [swift-evolution] [Proposal] Replace all Swift comments by end notes.

-1 from me. I prefer at-site documentation rather than having to scroll through potentially hundreds of comments at the end of the file (each of which would then have to have additional data to provide context information that isn't needed as it currently stands. I fully understand (and agree)

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

+1 for optional type definition. As someone also coming from Java, I agree that its implementation is less than ideal. When I first suggested moving the `throws` statement, I thought the decision on whether or not to declare (even optionally) the exception types had already been made. I see now

Re: [swift-evolution] [Thoughts?][Phase2] default arguments and trailing closure syntax

I think the way it is now works just fine. The only use-case I could see for this would be for having multiple closures, but in that case I think defining them before the function call is clearer anyway. -thislooksfun (tlf) > On Jan 4, 2017, at 10:40 PM, Derrick Ho via swift-evolution >

Re: [swift-evolution] [Proposal draft] Use obtain let instead if let construction

-1 from me, I think that it makes perfect sense the way it is. More specifically, I read `if let safe = optional` as "if optional can be unwrapped into safe, then ..." I think `obtain let` is more confusing, as it's not clear that it's a conditional from that keyword. Plus to me, "obtain" seems

Re: [swift-evolution] [Pitch] Tweak `Self` and introduce `Current`

I like this idea, however, if I understand the proposal correctly, I think that the naming would make more sense the other way around. `Self` is, at least in my head, tied directly and statically to the enclosing type, where as `Current` sounds more dynamic, and could change from

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

As I originally mentioned, once you are familiar with the facts that A) `throws` takes no parameters, and B) that `->` is returns, then I agree that iit is perfectly clear. My original (and still continuing, but getting better) confusion might make more sense after seeing the following

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

Re: [swift-evolution] Replace named returns with `out` parameters?

Accidentally sent this offlist (why no 'reply to' header?) -thislooksfun (tlf) > On Dec 28, 2016, at 9:52 AM, thislooksfun wrote: > > This already basically exists in the form `inout` > // Define the function > func position(x: inout Int, y: inout Int) { > x = 0 >

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

tent. The pattern is familiar. I think we should > keep the placement of throw as it is. > > On Mon, Dec 26, 2016 at 9:38 AM thislooksfun via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > Hello Swifters, > > I've been writing a lot more

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

gt; wrote: > > > On Dec 26, 2016, at 09:38, thislooksfun via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >> Hello Swifters, >> >> I've been writing a lot more Swift code recently, and I have found that

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

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

value of the stated return type. In that perspective, `throws` >> could be justified in its current position interposed between the input and >> the desired output. >> >> >> On Tue, Dec 27, 2016 at 4:51 PM, thislooksfun via swift-evolution >> <swift-evoluti

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

(I think this is the right place for this suggestion, but please let me know if I'm mistaken) There is currently no supported way to have some dependencies only used for testing (`swift test`), and the workarounds for it, while workable, are unnecessary crude. Currently, what a lot of