Re: [swift-evolution] [Pitch] Guard/Catch

Also the Scala approach already works quite nicely in Swift 4 in case anyone was curious: enum Try { case success(T) case failure(Error) init(_ f: @autoclosure () throws -> T) { do { self = .success(try f()) } catch { self = .failure(error)

Re: [swift-evolution] [Pitch] Guard/Catch

> try startHandler(observer) catch { > observer.sendFailed(error) > } Technically the above doesn’t make sense. Please disregard. > On Oct 7, 2017, at 10:35 PM, Tyler Cloutier wrote: > > Has there been any progress on this? I came here to propose this but came > upon this thread first. >

Re: [swift-evolution] [Pitch] Guard/Catch

Has there been any progress on this? I came here to propose this but came upon this thread first. This proposal goes way beyond sugar. I find myself constantly in the following situation: let observer = Observer(with: CircuitBreaker(holding: self)) do { let handlerDi

Re: [swift-evolution] multi-line string literals.

I am very much a fan of this type of thing. It's very clear that new line are included in the string. Leading white space is explicit. It is easy to align. It's easy to copy and paste. And there isn't excessive escaping. > On Apr 3, 2017, at 7:00 AM, Ricardo Parada via swift-evolution > wrote

Re: [swift-evolution] multi-line string literals.

This is probably too late, and I still have to read over the rest of the thread, but one possibility would be to just concatenate adjacent string literals (where a one sided string literal extends until the end of the line. E.g. In your example: let string = "Hello " // Three trailing space c

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

> On Jan 9, 2017, at 1:11 PM, Anton Zhilin wrote: > > I also thought about sum types as implementation of errors, but selecting > between Tyler’s and John’s syntaxes, I would pick the latter. Compare: > > let x: (_ a: Int) -> (Error | (_ b: Float) -> (Error | Double)) > > let x: (_ a: Int) th

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

> On Jan 9, 2017, at 1:10 AM, Tyler Cloutier wrote: > >> >> On Dec 26, 2016, at 2:55 PM, Dave Abrahams via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> >> on Mon Dec 26 2016, thislooksfun > > wrote: >> >>> Hello Swifters, >>> >>> I've

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

> On Dec 26, 2016, at 2:55 PM, Dave Abrahams via swift-evolution > wrote: > > > on Mon Dec 26 2016, thislooksfun > wrote: > >> Hello Swifters, >> >> I've been writing a lot more Swift code recently, and I have found >> that the default placement of the 'thr

Re: [swift-evolution] [Pitch] Eliminate tuples - unify member access syntax

I’ll tell you it, though, it would be really nice to be able to add functions to tuples, just as they are done with structs. Perhaps there is a way to formalize tuples as unnamed or anonymous Structs? It would make them going away strictly by making them more powerful. > On Jan 8, 2017, at 1

Re: [swift-evolution] [Draft] Unify "import Darwin/Glibc" to simply "Libc"

> On Oct 5, 2016, at 10:29 PM, Chris Lattner via swift-evolution > wrote: > > On Oct 5, 2016, at 3:57 PM, Brent Royal-Gordon wrote: >>> On Sep 13, 2016, at 12:29 PM, Brian Gesiak via swift-evolution >>> wrote: >>> I hadn't thought about a unified overlay for POSIX. I think the simplified >>

Re: [swift-evolution] [Draft] Unify "import Darwin/Glibc" to simply "Libc"

There is also a similar intent for Zewo’s POSIX: https://github.com/Zewo/POSIX/blob/master/Sources/POSIX It would be great to have something included with Swift. > On Sep 14, 2016, at 5:59 AM, Alex Blewitt via swift-evolution > wrote: > > Vapor's Core package expresses a target called simply

Re: [swift-evolution] Proposal SE-0009 Reconsideration

As another colorblind developer, I have trouble paying attention to the syntax highlighting. I didn’t even notice that member variables were colored until someone mentioned it on this list. > On May 23, 2016, at 9:43 AM, Jeff Kelley via swift-evolution > wrote: > > As a colorblind developer,

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol syntax with Any

> On May 24, 2016, at 12:07 PM, Joe Groff via swift-evolution > wrote: > > 'Any' is definitely a better name, but I think this is still syntax only a > compiler can love. If we're going to repaint this bikeshed, I think we should > also consider as an alternative some form of infix syntax for

Re: [swift-evolution] [Review] SE-0089: Renaming String.init(_: T)

I was about to suggest this as well. It seems like the natural name given the CustomStringConvertible protocol requires the description property. > On May 17, 2016, at 10:17 PM, Austin Zheng via swift-evolution > wrote: > > I like Jacob's suggestion of "init(describing:)", and I also think th

Re: [swift-evolution] [Discussion] Namespaces

This seems like a problem that would be better solved by adopting the Python philosophy that you must provide the full namespace for types, either upon import or explicitly in the code. It also makes searching things in the code easier as it’s clear exactly which namespace each type belongs to.

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

> On May 16, 2016, at 9:21 AM, Matthew Johnson wrote: > > >>> On May 16, 2016, at 1:17 AM, Tyler Fleming Cloutier >>> wrote: >>> >>> >>> On May 15, 2016, at 11:48 AM, Dave Abrahams via swift-evolution >>> wrote: >>> >>> >>> on Mon May 09 2016, Matthew Johnson wrote: >>> > On May

Re: [swift-evolution] Change `repeat` to loop indefinitely if no while clause is present

> On May 10, 2016, at 5:56 PM, Chris Lattner wrote: > > >> On May 10, 2016, at 4:13 PM, Cole Campbell via swift-evolution >> wrote: >> >> I agree that repeat { } is ambiguous because you have to look to the end for >> a while clause to determine if it's infinite or not. > > Right, this is

Re: [swift-evolution] Change `repeat` to loop indefinitely if no while clause is present

:59 PM, Xiaodi Wu >> <mailto:xiaodi...@gmail.com>> wrote: >>> >>> On Tue, May 10, 2016 at 5:56 PM, Tyler Cloutier >> <mailto:cloutierty...@aol.com>> wrote: >>> >>>> On May 10, 2016, at 3:13 PM, Xiaodi Wu >>> <mailto:xi

Re: [swift-evolution] Change `repeat` to loop indefinitely if no while clause is present

>> On Tue, May 10, 2016 at 5:56 PM, Tyler Cloutier > <mailto:cloutierty...@aol.com>> wrote: >> >>> On May 10, 2016, at 3:13 PM, Xiaodi Wu >> <mailto:xiaodi...@gmail.com>> wrote: >>> >>> On Tue, May 10, 2016 at 3:30 PM, Tyler Cloutier

Re: [swift-evolution] Change `repeat` to loop indefinitely if no while clause is present

> On May 10, 2016, at 3:59 PM, Xiaodi Wu wrote: > > On Tue, May 10, 2016 at 5:56 PM, Tyler Cloutier <mailto:cloutierty...@aol.com>> wrote: > >> On May 10, 2016, at 3:13 PM, Xiaodi Wu > <mailto:xiaodi...@gmail.com>> wrote: >> >> On Tue

Re: [swift-evolution] Change `repeat` to loop indefinitely if no while clause is present

> On May 10, 2016, at 3:56 PM, Tyler Cloutier via swift-evolution > wrote: > >> >> On May 10, 2016, at 3:13 PM, Xiaodi Wu > <mailto:xiaodi...@gmail.com>> wrote: >> >> On Tue, May 10, 2016 at 3:30 PM, Tyler Cloutier via swift-evolution >&g

Re: [swift-evolution] Change `repeat` to loop indefinitely if no while clause is present

> On May 10, 2016, at 3:13 PM, Xiaodi Wu wrote: > > On Tue, May 10, 2016 at 3:30 PM, Tyler Cloutier via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > I’d actually say that I’m strongly in favor of allowing just a repeat > keyword, although I wouldn’t su

Re: [swift-evolution] Change `repeat` to loop indefinitely if no while clause is present

> On May 10, 2016, at 3:13 PM, Xiaodi Wu wrote: > > On Tue, May 10, 2016 at 3:30 PM, Tyler Cloutier via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > I’d actually say that I’m strongly in favor of allowing just a repeat > keyword, although I wouldn’t su

Re: [swift-evolution] Change `repeat` to loop indefinitely if no while clause is present

er is that, given repeat is > already part of the language, the former it is simpler, with less noise. It > reads like simple english. It also aligns well with current do {} syntax. > This is the only argument I’m offering, and I think it’s the only one that > could b

Re: [swift-evolution] Change `repeat` to loop indefinitely if no while clause is present

aligns well with current do {} syntax. This is the only argument I’m offering, and I think it’s the only one that could be offered for such a small syntax change given that it *only* serves to clarify and reduce noise of current syntax which has the same functionality. > On Tue, May 10, 2016

Re: [swift-evolution] Change `repeat` to loop indefinitely if no while clause is present

; continue do_stuff >> } >> >> This pattern explicit and allows very complex control flow patterns without >> the drawbacks of the unrestricted goto construct. >> >> Therefore I don’t see utility with having a repeat {} without while clause. >> >> Bes

Re: [swift-evolution] Change `repeat` to loop indefinitely if no while clause is present

> On May 10, 2016, at 1:34 PM, Sean Heber wrote: > >> On May 10, 2016, at 3:30 PM, Tyler Cloutier via swift-evolution >> wrote: >> >> Secondly it’s a very simple way of introducing new programmers to loops. >> It’s IMHO more clear to a new pro

Re: [swift-evolution] Change `repeat` to loop indefinitely if no while clause is present

I’d actually say that I’m strongly in favor of allowing just a repeat keyword, although I wouldn’t support making 'while true’. Firstly it reduces clutter and makes it very clear that the the code is just supposed to repeat. Secondly it’s a very simple way of introducing new programmers to loop

Re: [swift-evolution] Change `repeat` to loop indefinitely if no while clause is present

Furthermore, I also think it is a nice generalization of the do { } syntax for scopes. I think it is quite intuitive that do executes a block once, and repeat executes it repeatedly. > On May 10, 2016, at 1:09 PM, Erica Sadun via swift-evolution > wrote: > > I do not see sufficiently mea

Re: [swift-evolution] Change `repeat` to loop indefinitely if no while clause is present

> On May 10, 2016, at 1:10 PM, Austin Zheng via swift-evolution > wrote: > > Agreed. I'm not convinced that this actually prevents any more errors than it > might cause (forgot to finish writing my "repeat" block, and now my app is > unresponsive), and I don't think there's enough of an expre

Re: [swift-evolution] Change `repeat` to loop indefinitely if no while clause is present

Oh you are right, I totally missed that, thanks. > On May 10, 2016, at 12:10 PM, Xiaodi Wu wrote: > > Nicholas wrote that he would like `while true` to be a compile-time error. > I'm curious as to why. > > On Tue, May 10, 2016 at 13:47 Tyler Cloutier wrote: >>> On May 10, 2016, at 12:39 AM, X

Re: [swift-evolution] Change `repeat` to loop indefinitely if no while clause is present

> On May 10, 2016, at 12:39 AM, Xiaodi Wu via swift-evolution > wrote: > > On Tue, May 10, 2016 at 2:27 AM, Nicholas Maccharoli via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > ​Swift Evolution ​Community, > > Currently writing an infinite loop in swift looks either something

Re: [swift-evolution] multi-line string literals.

> On May 5, 2016, at 10:52 PM, Brent Royal-Gordon > wrote: > >> As far as mixed whitespace, I think the only sane thing to do would be to >> only allow leading tabs *or* spaces. Mixing tabs and spaces in the leading >> whitespace would be a syntax error. All lines in the string would need t

Re: [swift-evolution] multi-line string literals.

> On May 5, 2016, at 6:27 PM, Tyler Cloutier via swift-evolution > wrote: > > >> On May 5, 2016, at 5:08 PM, John Holdsworth via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> >>> On 5 May 2016, at 14:

Re: [swift-evolution] multi-line string literals.

> On May 5, 2016, at 5:08 PM, John Holdsworth via swift-evolution > wrote: > > >> On 5 May 2016, at 14:17, David Hart > > wrote: >> >> >>> On 05 May 2016, at 12:30, Michael Peternell via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> it's no

Re: [swift-evolution] [Idea] Remove optional pattern binding

> On May 2, 2016, at 1:08 PM, David Waite via swift-evolution > wrote: > >> The reason is simple: most developers don’t grok pattern matching. >> Particularly for people new to swift, “if let” is taught as a magic for >> dealing with optionals (which it is). This is a very useful mechanic wh

Re: [swift-evolution] Auto Unwrapping Of Optionals

The difference between the if-let syntax and the below syntax is that the type of foo never changes with the if-let syntax. Instead a new variable is created which shadows the original foo. The distinction is important because types don’t implicitly change in Swift. The implicit change is called

Re: [swift-evolution] mutating/non-mutating suggestion from a Rubyist

> On Apr 23, 2016, at 1:27 AM, Pyry Jahkola via swift-evolution > wrote: > > I'd like to second James Campbell's suggestion of a `mutate` keyword. > Clarifying comments inline below: > >> On 23 Apr 2016, at 00:24, Dave Abrahams via swift-evolution >> mailto:swift-evolution@swift.org>> wrote:

Re: [swift-evolution] multi-line string literals.

Hi Brent, What I mean is a document like the error handling rationale. Since there are so many potential solutions to this problem. And ah right! You were the one who responded and proposed an implementation. Thanks, Tyler > On Apr 27, 2016, at 2:19 PM, Tyler Cloutier via swift-evolut

Re: [swift-evolution] multi-line string literals.

Hi Brent, This is essentially the same solution I proposed way back in December: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/002374.html I still have the same reservations about copy

Re: [swift-evolution] mutating/non-mutating suggestion from a Rubyist

That being said I try to follow most of the discussions on swift-evolution and there does seem to be a great deal of hand wringing regarding this and things related to or affected by this. > On Apr 22, 2016, at 12:00 AM, Tyler Cloutier via swift-evolution > wrote: > > If I reca

Re: [swift-evolution] mutating/non-mutating suggestion from a Rubyist

If I recall correctly there was a thread with a similar idea which instead would create a new operator for mutation or a new way of method invocation, such that mutating methods would be called with &. or something similar. e.g. foo&.add(5) I think the consensus was that that was not a particul

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

I won’t do a full review because I don’t think I have spent enough time reading through the discussion, but just reading the proposal I’d say I’m an huge proponent of this change. Irrespective of the performance benefits, I think it’s a massive win for an easily understandable mental model. Tyl

Re: [swift-evolution] idea: immutable setters for structs and tuples?

I would very much like a standardized way of doing this. I am currently writing a game implementation in a functional style and the syntax for updating fields in pretty clunky. I’d like to avoid having to explicitly use var’s at all to accomplish it. > On Mar 23, 2016, at 7:29 AM, James Campbe

Re: [swift-evolution] [Idea] Add forced conversion for Error catching pattern matching

> > On Mar 21, 2016, at 6:01 AM, Haravikk wrote: > > I’m a ±1; for the way things are I’m a +1, but I think I’d still prefer to > have typed errors that the compiler can use to check for an exhaustive list, > as it would be easy for a forced conversion to result in unexpected runtime > errors

Re: [swift-evolution] Proposal: Add syntactic sugar for iterating over an Optional

The syntax could be for x in array? { } It wouldn't necessarily be consistent with if let foo = foo { } But as I've mentioned in another thread regarding the if let syntax and variable shadowing, it would probably make more sense to new users if the if let syntax was the following. if let

Re: [swift-evolution] use standard syntax instead of "do" and "repeat"

Please see comments inline. > On Dec 31, 2015, at 12:07 PM, Dave Abrahams via swift-evolution > wrote: > > >>> On Dec 27, 2015, at 10:25 PM, Brent Royal-Gordon via swift-evolution >>> wrote: >>> >>> So “try” instead of “do”. If there is no catch, then just use braces >>> without a keyword

Re: [swift-evolution] Proposal Sketch: simplify optional unwrapping syntax

I've always thought that, if let foo = foo? { } makes more sense than if let foo = foo { } as the ? indicates that you are unwrapping the optional and then assigning it to the new variable > On Dec 19, 2015, at 7:02 PM, Cihat Gündüz via swift-evolution > wrote: > > I’ve only read the l

Re: [swift-evolution] [Review] Require self for accessing instance members

On Dec 21, 2015, at 3:43 AM, Tyler Cloutier via swift-evolution > wrote: > > I'm strongly in favor of the proposal, but I too think the proposal is > missing balance. I'd really like to see all the points for and against laid > out in one place, so they can be weighed a

Re: [swift-evolution] [Review] Require self for accessing instance members

I'm strongly in favor of the proposal, but I too think the proposal is missing balance. I'd really like to see all the points for and against laid out in one place, so they can be weighed appropriately. Tyler > On Dec 16, 2015, at 12:13 PM, Nick Shelley via swift-evolution > wrote: > > Also,