Re: [swift-evolution] Type-annotated throws

> On Aug 26, 2016, at 8:39 AM, Félix Cloutier via swift-evolution > wrote: > > Hi all, > > Currently, a function that throws is assumed to throw anything. There was a > proposal draft last December to restrict that. The general idea was that > you'd write, for

Re: [swift-evolution] [Accepted] SE-0121: Remove Optional Comparison Operators

On Sun, Aug 28, 2016, at 01:28 PM, Dave Abrahams via swift-evolution wrote: > > on Fri Aug 26 2016, Kevin Ballard wrote: > > > Goddammit. I completely missed this thread, because Pipermail > > regularly decides not to deliver the swift-evolution-announce version > >

Re: [swift-evolution] [Accepted] SE-0121: Remove Optional Comparison Operators

On Mon, Aug 29, 2016, at 03:26 AM, Patrick Smith wrote: > A little nicer I think is: > > if request?.httpVersion.map({ $0 < HTTPVersion(1.0) }) ?? true { > > It’s very explicit what the fallback is too, the original’s ambiguity makes > me uncomfortable. I find that much less readable. > BTW,

Re: [swift-evolution] [Idea] Distinguishing code comments from text comments.

You don't have to. #if false { // disabled code here } > On Aug 29, 2016, at 1:16 PM, DifferentApps info via swift-evolution > wrote: > > The advantage is that you do not need to define a conditional flag for the > #if. > It is also more concise. > > Code

Re: [swift-evolution] [Idea] Add `bounds` function to standard library

Tim, The protocol extension alone would be sufficient, but for as long as the global functions `min` and `max` are still around I thought adding a global clamp function would make for good symmetry. I'll write a small draft proposal to illustrate my idea a little better. What does the community

[swift-evolution] Fwd: Add ability to specify the error type on throws

Hello, Consider the scenario of the vending machine example in the Swift Book: We have a function that throws errors from a single given ErrorType 1. func vend(itemNamed name: String) throws { 2. guard let item = inventory[name] else { 3. throw VendingMachineError.InvalidSelection

Re: [swift-evolution] [Pitch] [Stage 2] [Additional] Remove leading dot after closures

> On Aug 28, 2016, at 11:15 AM, Adrian Zubarev via swift-evolution > wrote: > > This is a small pitch for stage 2 (or even another Swift release, if the > community likes this change) > I’m sorry, but Stage 2 proposals are out of scope for right now, and syntactic

Re: [swift-evolution] [Idea] Distinguishing code comments from text comments.

> 29 Aug. 2016 23:15 DifferentApps info wrote: > > Thanks for your pattern suggestion. > But it would be also possible to switch between implementations with the > proposed syntax as shown bellow: > > /{ > > }/ > do { > > } No, that would not be

Re: [swift-evolution] [Idea] Distinguishing code comments from text comments.

On Mon, Aug 29, 2016 at 4:15 PM, DifferentApps info via swift-evolution < swift-evolution@swift.org> wrote: > Thanks for your pattern suggestion. > But it would be also possible to switch between implementations with the > proposed syntax as shown bellow: > > /{ > > }/ > do { > > } > >

Re: [swift-evolution] [Idea] Distinguishing code comments from text comments.

Thanks for your pattern suggestion. But it would be also possible to switch between implementations with the proposed syntax as shown bellow: /{ }/ do { } Le 29 août 2016 à 22:53, Magnus Ahltorp a écrit : >> 29 Aug. 2016 22:16 DifferentApps info

Re: [swift-evolution] [Idea] Distinguishing code comments from text comments.

Nice! With that explanation, I too am -1 on another way of doing the same thing. On Mon, Aug 29, 2016 at 15:53 Magnus Ahltorp via swift-evolution < swift-evolution@swift.org> wrote: > > 29 Aug. 2016 22:16 DifferentApps info > wrote: > > > > The advantage is that

Re: [swift-evolution] [Idea] Distinguishing code comments from text comments.

The advantage is that you do not need to define a conditional flag for the #if. It is also more concise. Code disabling (with /{...}/) is a tool useful when developing algorithm, and disabled code should not be aimed to remain definitively in a Swift file. Andre Ponzo > Le 29 août 2016 à

Re: [swift-evolution] [Idea] Distinguishing code comments from text comments.

> Am 29.08.2016 um 20:20 schrieb Magnus Ahltorp via swift-evolution > : > > What are the advantages of this compared to conditional compilation (#if)? Just was about to propose this (existing) alternative. I've already used it to store complicated breakpoint-actions

Re: [swift-evolution] Type-annotated throws

> On Aug 29, 2016, at 4:18 AM, Tino Heth via swift-evolution > wrote: > > I'm quite skeptical here (Java has already been mentioned…), but if it's > done, I'd vote for removing ErrorType: > This empty protocol always felt a little bit odd to me, and when each >

Re: [swift-evolution] Pitch: really_is and really_as operators

> On Aug 29, 2016, at 11:14 AM, Joe Groff wrote: > >> >> On Aug 24, 2016, at 5:08 PM, Charles Srstka via swift-evolution >> wrote: >> >> MOTIVATION: >> >> SE-0083 appears to be dead in the water, having been deferred until later in >> Swift 3

Re: [swift-evolution] [Idea] Distinguishing code comments from text comments.

> 27 Aug. 2016 21:03 Andre Ponzo via swift-evolution > wrote: > > 1) Advantages of disabled code ( /{ ... } ) instead of commented-out code (/* > ... */): > 2) Advantages of /{ ... } instead of "if false { ... }": What are the advantages of this compared to

[swift-evolution] [Idea] Add `bounds` function to standard library

What would the point of a free function be if you already have a protocol extension? > Georgios, Yes lets go with clamp for a name! > > Pyry, Originally I thought of just adding a global function akin to `min` > and `max` but I am also > in favour of adding the above extension to `Comparable`.

Re: [swift-evolution] Passing an optional first argument to sequence(first:next:)

The intent of my function wasn’t very clear, but it was supposed to return a sequence that contains *all* consecutive pairs, i.e. (0 ..< 4).pairs would result in [(0, 1), (1, 2), (2, 3)]. > on Fri Aug 26 2016, Tim Vermeulenwrote: > > > This is when I first wanted to

Re: [swift-evolution] Type-annotated throws

> On Aug 26, 2016, at 8:39 AM, Félix Cloutier via swift-evolution > wrote: > > Hi all, > > Currently, a function that throws is assumed to throw anything. There was a > proposal draft last December to restrict that. The general idea was that > you'd write, for

Re: [swift-evolution] Pitch: really_is and really_as operators

> On Aug 24, 2016, at 5:08 PM, Charles Srstka via swift-evolution > wrote: > > MOTIVATION: > > SE-0083 appears to be dead in the water, having been deferred until later in > Swift 3 back in May and not having been heard from since then, with the Swift > 3 release

Re: [swift-evolution] [Proposal draft] Bridge Optional As Its Payload Or NSNull

> On Aug 25, 2016, at 9:34 AM, Douglas Gregor wrote: > I’d thought we were going to get some warnings when putting an optional into > an Any that would end up going into Objective-C, but I don’t see the warning: > maybe Joe can weigh in as to why we didn’t do that. Warning

Re: [swift-evolution] [Proposal draft] Bridge Numeric Types to NSNumber and Cocoa Structs to NSValue

> On Aug 23, 2016, at 4:00 PM, Tony Parker via swift-evolution > wrote: > > Hi Doug, > >> On Aug 23, 2016, at 3:36 PM, Douglas Gregor via swift-evolution >> wrote: >> >> Introduction >> >> A handful of Swift numeric types are bridged

[swift-evolution] Allow failable initializers to return .none as well as nil

With the introduction of the Optional type in Swift, it is possible to write an entire application without explicitly referring to nil and instead use the Optional's .none case. However, on failable initializers nil is the only return value permitted by the compiler. Given that the initialization

Re: [swift-evolution] [Idea] Distinguishing code comments from text comments.

All, To add to Andre's comments about benefits of code commenting, /{ and }/ (or any equivalent that uses open and close braces) allows the IDE editor's brace-balancer to work, which in turn helps the user with finding endpoints of commented-out code. Commented-out code should be

Re: [swift-evolution] [Idea] Distinguishing code comments from text comments.

Good day, swift-evolution followers, After reading Doug McKenna's email, I also see advantages in using specific syntax to disable code instead of commenting it out. To illustrate these ideas lets pick the more appropriate syntax (in my opinion) proposed by Doug: /{ ... } For example: /{

Re: [swift-evolution] [Pitch] [Stage 2] [Additional] Remove leading dot after closures

While I kind of like the idea of effectively rolling my own keywords, my personal preference is to remain explicit about the fact that this is a method of something. I don't know if I'm against the idea, I just don't think I'd use it. > On 28 Aug 2016, at 19:15, Adrian Zubarev via

Re: [swift-evolution] [Accepted] SE-0121: Remove Optional Comparison Operators

I agree - I really don’t like these clever map constructs to work around optionals either and I avoid them at all costs. IMO they obscure intent pretty severely and shouldn’t be considered idiomatic Swift. Depending on circumstances, I might do something along these lines: guard let version =

Re: [swift-evolution] Type-annotated throws

+1 for removing Error protocol. Then it's a breaking change, and this edition of the proposal can be reviewed for Stage 1. Swift error model tries to be different (better) than of other languages. We encourage not to rethrow, but to think of errors as of meaningful results and process them

Re: [swift-evolution] [Accepted] SE-0121: Remove Optional Comparison Operators

Whenever I see such examples I feel like map is being abused because of some of its properties rather than this. Ring the best way to deal with optionals. Sent from my iPhone > On 29 Aug 2016, at 11:26, Patrick Smith via swift-evolution > wrote: > > A little nicer

Re: [swift-evolution] [Accepted] SE-0121: Remove Optional Comparison Operators

A little nicer I think is: if request?.httpVersion.map({ $0 < HTTPVersion(1.0) }) ?? true { It’s very explicit what the fallback is too, the original’s ambiguity makes me uncomfortable. BTW, did you want to be checking for <= 1.0? With HTTP 1.0, it’s opt in.

Re: [swift-evolution] [swift-users] Variadic parameter in function type

How about this? func output(_ separator: String, _ terminator: String, _ items: Any...) { print(items, separator, terminator) } output(",", "\n", "Apple", "Banana") Zhaoxin On Mon, Aug 29, 2016 at 3:47 PM, Jin Wang wrote: > Hey Zhao, > > Thanks for your reply,

Re: [swift-evolution] Type-annotated throws

I'm quite skeptical here (Java has already been mentioned…), but if it's done, I'd vote for removing ErrorType: This empty protocol always felt a little bit odd to me, and when each function has information about what errors to expect, imho there is absolutely no benefit associated with

Re: [swift-evolution] [Pitch] [Stage 2] [Additional] Remove leading dot after closures

This would be fairly inconsistent. I’ve never seen swift syntax with semantics that are dependent on the formatting. David. > On 29 Aug 2016, at 10:10, Adrian Zubarev via swift-evolution > wrote: > > It’s a very good point I haven’t seen at first glance. Therefore,

Re: [swift-evolution] [Pitch] [Stage 2] [Additional] Remove leading dot after closures

It’s a very good point I haven’t seen at first glance. Therefore, how about making the . optional in scenarios where the compiler can safely infer the chain: someArray.map { … } filter { … } flatMap { … } // and someArray.map { … } filter { … } flatMap { … } And still

Re: [swift-evolution] [Idea] Add `bounds` function to standard library

Georgios, Yes lets go with clamp for a name! Pyry, Originally I thought of just adding a global function akin to `min` and `max` but I am also in favour of adding the above extension to `Comparable`. I think having both the global function and the protocol extension for `clamp` would be great. -

Re: [swift-evolution] [swift-users] Variadic parameter in function type

Hey Zhao, Thanks for your reply, but then i can’t use the default value `print` which is the print function Swift provides. Any idea? Cheers, Jin > On 29 Aug. 2016, at 5:44 pm, zh ao wrote: > > It is suggested to put ... part at the end. > > Zhaoxin > > Get Outlook for

Re: [swift-evolution] [swift-users] Variadic parameter in function type

It is suggested to put ... part at the end. Zhaoxin Get Outlook for iOS On Mon, Aug 29, 2016 at 1:19 PM +0800, "Jin Wang via swift-users" wrote: Hey guys, Can anyone tell me how you handle the following scenario after SE-0111 gets implemented? let output: