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

2016-01-02 Thread Tino Heth via swift-evolution
> 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

2016-01-02 Thread Brent Royal-Gordon via swift-evolution
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

2016-01-02 Thread Gwendal Roué via swift-evolution
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] Inquiry: Status of SR-122 ?

2016-01-02 Thread Dmitri Gribenko via swift-evolution
On Sat, Jan 2, 2016 at 4:53 AM, Dave Abrahams via swift-evolution wrote: > >> On Jan 1, 2016, at 4:34 PM, plx via swift-evolution >> wrote: >> >> I was preparing a proposal-sketch relating to this earlier discussion: >>

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

2016-01-02 Thread Michel Fortin via swift-evolution
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?

2016-01-02 Thread Tino Heth via swift-evolution
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?

2016-01-02 Thread Maury Markowitz via swift-evolution
> 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?

2016-01-02 Thread Dennis Lysenko via swift-evolution
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?

2016-01-02 Thread Maury Markowitz via swift-evolution
> 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

2016-01-02 Thread Félix Cloutier via swift-evolution
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

2016-01-02 Thread Félix Cloutier via swift-evolution
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

2016-01-02 Thread Daniel Dunbar via swift-evolution
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

2016-01-02 Thread Dave Abrahams via swift-evolution
> 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?

2016-01-02 Thread Maury Markowitz via swift-evolution
> 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?

2016-01-02 Thread Robert S Mozayeni via swift-evolution
(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?

2016-01-02 Thread Charles Srstka via swift-evolution
> 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

2016-01-02 Thread Drew Crawford via swift-evolution
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

2016-01-02 Thread Joseph Lord via swift-evolution
> 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] use standard syntax instead of "do" and "repeat"

2016-01-02 Thread Tyler Cloutier via swift-evolution
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

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

2016-01-02 Thread Kevin Ballard via swift-evolution
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?

2016-01-02 Thread Developer via swift-evolution
-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

2016-01-02 Thread David Owens II via swift-evolution
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

2016-01-02 Thread Kevin Ballard via swift-evolution
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

2016-01-02 Thread Tyler Cloutier via swift-evolution
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

2016-01-02 Thread Arnold via swift-evolution
'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!

2016-01-02 Thread Developer via swift-evolution
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

2016-01-02 Thread Dave Abrahams via swift-evolution
> 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

2016-01-02 Thread Dave Abrahams via swift-evolution
> 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

2016-01-02 Thread Brent Royal-Gordon via swift-evolution
> `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

2016-01-02 Thread Kevin Ballard via swift-evolution
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

2016-01-02 Thread Austin Zheng via swift-evolution
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

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

2016-01-02 Thread Brent Royal-Gordon via swift-evolution
> If I don’t sound sympathetic, it’s because nobody has shown a use-case for > this functionality, and until I see one I am going to have a hard time > believing there’s a problem worth solving. If you want to make the case that > we need something like this, please show me why. Didn't this

[swift-evolution] Customized Inline Init Closure

2016-01-02 Thread Weston Catron via swift-evolution
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

2016-01-02 Thread Douglas Gregor via swift-evolution
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

2016-01-02 Thread Kevin Ballard via swift-evolution
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!

2016-01-02 Thread Jacob Bandes-Storch via swift-evolution
+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

2016-01-02 Thread Dave Abrahams via swift-evolution
> 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!

2016-01-02 Thread Brent Royal-Gordon via swift-evolution
> 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

2016-01-02 Thread Arnold via swift-evolution
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

2016-01-02 Thread John Joyce via swift-evolution
> > 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?

2016-01-02 Thread Robert S Mozayeni via swift-evolution
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

2016-01-02 Thread Kevin Ballard via swift-evolution
On Sat, Jan 2, 2016, at 09:50 PM, Brent Royal-Gordon via swift-evolution wrote: > > If I don’t sound sympathetic, it’s because nobody has shown a use-case for > > this functionality, and until I see one I am going to have a hard time > > believing there’s a problem worth solving. If you want to

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

2016-01-02 Thread Gwendal Roué via swift-evolution
> 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. > […]