Re: [swift-evolution] Better syntax for deferred?

> Unless I missed something obvious, wouldn't placing "code that always has to > run at the end" actually *at the end* not make more sense? Like this… In most cases, you use defer for cleanup tasks - so it make more sense to keep it at the source of the "problem": file.open(); defer {

Re: [swift-evolution] Proposal: Add SequenceType.first

May I suggest a simple solution? extension SequenceType { /// Returns one element from the beginning of the sequence, or `nil` if the sequence is empty. /// If `self` is a single-pass sequence, this may consume the element. func one() ->

Re: [swift-evolution] Proposal: Add SequenceType.first

Hello, My two cents: I feel uncomfortable with SequenceType.first since SequenceType clearly states that it may be destructed on iteration. Compare : seq.generate().next() // clear that it may give another result if called twice seq.first // unclear that it may give another result

Re: [swift-evolution] Better syntax for deferred?

Le 2 janv. 2016 à 13:29, Maury Markowitz via swift-evolution a écrit : > No, they don't. With the exception of "Go", I'm unfamiliar with any other > language that implements this feature *in this fashion*. D has `scope (exit)`, which is exactly the same as `defer`

Re: [swift-evolution] Better syntax for deferred?

I have the terrible feeling something is wrong with my posts so that they get caught by spamfilters or similar… But as others stated as well: defer has a use case that is a little bit different from what you want to archive. > Why not use a solution that is widely used and better? I'm curious:

Re: [swift-evolution] Better syntax for deferred?

> On Jan 2, 2016, at 9:38 AM, Nicky Gerritsen wrote: > > Defer is used to make code *always* run, even if the function terminates > early. Imagine: Which is precisely why I called it 'always'. So in your example: func doSomethingWith(x: Int) { print(“1”)

Re: [swift-evolution] Better syntax for deferred?

Deferring at the end of the function removes the ability to defer actions on variables introduced in an inner scope. On Sat, Jan 2, 2016, 1:57 PM Tino Heth via swift-evolution < swift-evolution@swift.org> wrote: > I have the terrible feeling something is wrong with my posts so that they > get

Re: [swift-evolution] Better syntax for deferred?

> On Jan 2, 2016, at 12:56 PM, Tim Hawkins wrote: > > Again my 2 cents > > Other languages use "deffer", and have very simular semantics No, they don't. With the exception of "Go", I'm unfamiliar with any other language that implements this feature *in this fashion*.

Re: [swift-evolution] Proposal: Add SequenceType.first

No one appears to have considered the C# example yet. In C#, IEnumerable (Swift's SequenceType) has a `First()` (and `FirstOrDefault(T)`) method. C# also has a coroutine syntax (`yield return xyz`) that makes it easy to create sequences that are evaluated with side effects. However, Googling

Re: [swift-evolution] [swift-build-dev] [swiftpm] Add proposal for C language support

This sounds interesting. I don't have time to read it right now but I like the idea and I'll give better feedback later. Félix > Le 2 janv. 2016 à 12:28:10, Kostiantyn Koval via swift-evolution > a écrit : > > Hi, Happy 2016. > > The proposal looks great as for

[swift-evolution] [swiftpm] Add proposal for C language support

Happy 2016! I am working on an initial proposal for adding support for C language targets to the Swift package manager, and am interested in feedback: https://github.com/ddunbar/swift-evolution/blob/master/proposals/-swiftpm-c-language-targets.md Some TL;DR: - The proposal defines a

Re: [swift-evolution] Asserts should not cause undefined behaviour

> On Dec 31, 2015, at 1:56 PM, Dave Abrahams via swift-evolution > wrote: > >> >> On Dec 31, 2015, at 12:27 PM, Chris Lattner via swift-evolution >> wrote: >> >> On Dec 28, 2015, at 5:48 AM, Joseph Lord via swift-evolution >>

Re: [swift-evolution] Better syntax for deferred?

> On Jan 2, 2016, at 1:26 PM, Javier Soto wrote: > > How would always behave if the function has an early return? Exactly the same way as 'defer' would behave if the function has an early return. ___ swift-evolution mailing

Re: [swift-evolution] Better syntax for deferred?

(Sorry if you get this email twice, I realized I first sent it from an email address that is not the one I used to subscribe to this list) Not only that, but placing defer at the end of a scope, where any other code may never get executed if there’s an early return, kind of violates the whole

Re: [swift-evolution] Better syntax for deferred?

> On Jan 2, 2016, at 8:37 AM, Tino Heth via swift-evolution > wrote: > >> >> Unless I missed something obvious, wouldn't placing "code that always has to >> run at the end" actually *at the end* not make more sense? Like this… > In most cases, you use defer for

Re: [swift-evolution] [swift-build-dev] [swiftpm] Add proposal for C language support

Thanks for directing me to this, I missed it. > Most projects will not conform to these conventions. Giggle. Kind of an understatement, no? Like, okay. Here is a project I'd like to package. (Read: I do package it, with features not in mainline swiftPM.)

Re: [swift-evolution] Asserts should not cause undefined behaviour

> On Jan 2, 2016, at 5:39 PM, Dave Abrahams via swift-evolution > wrote: > > >>> On Dec 31, 2015, at 1:56 PM, Dave Abrahams via swift-evolution >>> wrote: >>> >>> >>> On Dec 31, 2015, at 12:27 PM, Chris Lattner via swift-evolution >>>

Re: [swift-evolution] Proposal: Add SequenceType.first

On Sat, Jan 2, 2016, at 12:13 PM, Brent Royal-Gordon wrote: > > Why should we absolutely add methods with unclear meanings or behavior, > > when there are already perfectly clear, if verbose, alternatives? > > seq.generate().next() may not be nice, but no one can get fooled by it. > > Well, for

Re: [swift-evolution] Better syntax for deferred?

-1. `defer` doesn’t exist just to execute code at the end of blocks, it exists to allow resource cleanup when you have a function with multiple return points or non-trivial scoping. For example, let’s add an if statement to your code: func clear() { print("1") print("3") if

Re: [swift-evolution] [swift-build-dev] [swiftpm] Add proposal for C language support

Seems like a good start for Swift developers that need to write some C code for their project. -David Sent from my iPhone > On Jan 2, 2016, at 9:00 AM, Daniel Dunbar via swift-build-dev > wrote: > > Happy 2016! > > I am working on an initial proposal for adding

Re: [swift-evolution] Proposal: Add SequenceType.first

On Sat, Jan 2, 2016, at 07:17 PM, Dave Abrahams wrote: >> But since it's a CollectionType, you need to preserve the ability to >> access older values. > > Not once you replace it with a slice of itself. Ah I see, I missed that subtlety. Or more specifically, when you first said "slice" I was

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] Asserts should not cause undefined behaviour

'assert' evaluates the condition and aborts only in Odebug builds. 'precondition' evaluates the condition and aborts also in optimized -0 builds. As far as I remember the decision was made to give it this semantics to mimic C's assert() function. If an abort is desired in optimized builds one

[swift-evolution] [Proposal]: Free the '$' Symbol!

Swift currently does not allow operators to use $ - I assume because the grammar reserves it in one place: `implicit-parameter-name`. I don't see why an entire class of identifiers has been eliminated, so I propose $ instead be reclassified as an `operator-character` so it can be used mixed in

Re: [swift-evolution] Proposal: Add SequenceType.first

> On Jan 2, 2016, at 12:13 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> Why should we absolutely add methods with unclear meanings or behavior, when >> there are already perfectly clear, if verbose, alternatives? >> seq.generate().next() may not be

Re: [swift-evolution] Proposal: Add SequenceType.first

> On Dec 31, 2015, at 3:20 PM, Kevin Ballard wrote: > > On Thu, Dec 31, 2015, at 02:03 PM, Dave Abrahams wrote: >> >>> On Dec 31, 2015, at 1:58 PM, Kevin Ballard >> > wrote: >>> >>> Good idea, though I'd probably call it PeekSequence

Re: [swift-evolution] Proposal: Add SequenceType.first

> `buffered` is no more problematic than `lazy` is. In fact, calling `buffered` > actually doesn't have any side-effects at all (it can avoid fetching the > first element until you call `first` on the result of `buffered`). If `seq` is a single-pass sequence, then `seq.buffered.first` will

Re: [swift-evolution] Proposal: Add SequenceType.first

On Sat, Jan 2, 2016, at 11:17 PM, Brent Royal-Gordon wrote: > > `buffered` is no more problematic than `lazy` is. In fact, calling > > `buffered` actually doesn't have any side-effects at all (it can avoid > > fetching the first element until you call `first` on the result of > > `buffered`). >

[swift-evolution] [SR-119] AnySequence --> Any*Collection promotion

Hello all, Currently there exist at least four 'type-erased' sequence/collection types: AnySequence, AnyForwardCollection, AnyBidirectionalCollection, and AnyRandomAccessCollection. The three Any*Collection types can be conceptually arranged into a 'ladder', in which collections can be

[swift-evolution] Customized Inline Init Closure

Ability to write an initializer while initializing an object. Example let name = “John Apple”; let person = Person { self.name = nameInput.first() + " " + nameInput.last() self.dob = dateInput.datetime() If (self.age() > 18) { self.taxableStatus = INDEPENDANT } else {

[swift-evolution] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

Hello Swift community, The review of "Replace `typealias` keyword with `associatedtype` for associated type declarations” begins now and runs through Wednesday, January 6th. The proposal is available here:

Re: [swift-evolution] [swift-evolution-announce] [Review] Replace `typealias` keyword with `associatedtype` for associated type declarations

On Sat, Jan 2, 2016, at 10:38 PM, Douglas Gregor wrote: > * What is your evaluation of the proposal? +1 I have a preference for `associated` instead of `associatedtype`, but it's not a big deal. > * Is the problem being addressed significant enough to warrant a > change to Swift? Personally I

Re: [swift-evolution] [Proposal]: Free the '$' Symbol!

+10 On Sat, Jan 2, 2016 at 11:36 PM, Developer via swift-evolution < swift-evolution@swift.org> wrote: > Swift currently does not allow operators to use $ - I assume because the > grammar reserves it in one place: `implicit-parameter-name`. I don't see > why an entire class of identifiers has

Re: [swift-evolution] Proposal: Add SequenceType.first

> On Jan 2, 2016, at 11:26 PM, Kevin Ballard via swift-evolution > wrote: > > On Sat, Jan 2, 2016, at 11:17 PM, Brent Royal-Gordon wrote: >>> `buffered` is no more problematic than `lazy` is. In fact, calling >>> `buffered` actually doesn't have any side-effects at

Re: [swift-evolution] [Proposal]: Free the '$' Symbol!

> Swift currently does not allow operators to use $ - I assume because the > grammar reserves it in one place: `implicit-parameter-name`. I don't see why > an entire class of identifiers has been eliminated, so I propose $ instead be > reclassified as an `operator-character` so it can be used

Re: [swift-evolution] Asserts should not cause undefined behaviour

Sent from my iPhone > On Jan 2, 2016, at 6:35 PM, Dave Abrahams wrote: > > >> On Jan 2, 2016, at 2:57 AM, Arnold wrote: >> >> 'assert' evaluates the condition and aborts only in Odebug builds. >> >> 'precondition' evaluates the condition and

Re: [swift-evolution] Empower String type with regular expression

> > On Dec 8, 2015, at 12:14 PM, Jerome Paschoud via swift-evolution > > > > wrote: > > > > I would like to see the String type to support regular expression per > > default. I think that a language that advertise itself as being a good

Re: [swift-evolution] Better syntax for deferred?

Not only that, but placing defer at the end of a scope, where any other code may never get executed if there’s an early return, kind of violates the whole concept of control flow. func f() throws { let o = file(path: "") o.openFile() do { try o.write(self.data) }

Re: [swift-evolution] Proposal: Add SequenceType.first

> Le 3 janv. 2016 à 01:58, Kevin Ballard a écrit : > >>> seq.generate().next() may not be nice, but no one can get fooled by it. >> >> Well, for one thing, because it doesn't work. […] > > Exactly. If `seq.generate().next()` worked, I'd be perfectly happy with that. > […]