Re: [swift-evolution] ternary operator ?: suggestion

In the case where your input is hashable, you could just do: let i = [.Red:0xff, .Green:0x00ff00, .Blue:0xff][color] this would mean that color must be a Color and not an Optional (because of swift 2.x limitations) -DW > On Dec 22, 2015, at 8:04 AM, Félix Cloutier via swift-evolution

Re: [swift-evolution] Community Proposal: "This Week In Swift" newsletter

> On Dec 22, 2015, at 9:29 PM, Kevin Ballard via swift-evolution > wrote: > > During the development of Rust prior to v1.0, one of the things that really > helped with keeping up with changes (both in the language and in the stdlib) > was Corey Richardson's weekly newsletter/blog titled This

Re: [swift-evolution] [Proposal idea] Improved interop for ErrorType->NSError

I find it a little bit strange that your error handling function takes an optional in the first place. The caller should only call an errror handler in case of an error, so you should already have unwrapped the optional. -Thorsten > Am 22.12.2015 um 18:30 schrieb Paul Cantrell via swift-evol

Re: [swift-evolution] Community Proposal: "This Week In Swift" newsletter

Although more general and not specific to the language development itself, there’s https://swiftnews.curated.co. It has a couple links to summaries of Swift-Evolution activity too. > On Dec 22, 2015, at 10:29 PM, Kevin Ballard via swift-evolution > wrote: > > During the development of Rust p

Re: [swift-evolution] Proposal: Allow Type Annotations on Throws

David's proposal looks good enough for me. With regards to Matthew's worry of cluttering the code with conversion I'd like to remark that this conversion code should only live on the border of your API (the facade), so it should probably not be too invasive to your business logic. -Thorsten

[swift-evolution] Community Proposal: "This Week In Swift" newsletter

During the development of Rust prior to v1.0, one of the things that really helped with keeping up with changes (both in the language and in the stdlib) was Corey Richardson's weekly newsletter/blog titled This Week In Rust. Since 1.0, that was actually turned into its own website at https://th

Re: [swift-evolution] Proposal: Python's indexing and slicing

Oh that's a good point, I hadn't thought of that. It makes sense to keep $abc reserved for the debugger. I don't believe LLDB tries to use a bare $ anywhere (although I could be wrong) so leaving that as a valid identifier should be fine. -Kevin Ballard On Tue, Dec 22, 2015, at 07:48 PM, Jorda

Re: [swift-evolution] [Review] Tuple comparison operators (was: Add a Lazy flatMap for Sequences of Optionals)

On Tue, Dec 22, 2015, at 08:13 PM, Guillaume Lessard via swift-evolution wrote: > > > On 22 déc. 2015, at 19:40, Dave Abrahams wrote: > > > > It’s very convenient for “<“ to correspond to the standard strict-weak > > ordering for a type where possible. > > Convenient maybe. Is it advisable f

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

I did see that point made earlier in the thread, but I’m not convinced that design for googleability is the right ordering of priorities. I think people will probably figure out that they need to search for “swift protocol type” or whatever the final choice ends up being. > On Dec 22, 2015, at

Re: [swift-evolution] Coroutine for Swift

FWIW: https://github.com/Zewo/Venice On Wed, Dec 23, 2015, 00:13 Susan Cheng via swift-evolution < swift-evolution@swift.org> wrote: > Hi, > > I just want a wide public concern in swift community with this > implementation. > Should we have a proposal about @goto and @label as workaround? Just a

Re: [swift-evolution] [Review] Tuple comparison operators (was: Add a Lazy flatMap for Sequences of Optionals)

On Tue, Dec 22, 2015 at 8:13 PM, Guillaume Lessard via swift-evolution wrote: > >> On 22 déc. 2015, at 19:40, Dave Abrahams wrote: >> >> It’s very convenient for “<“ to correspond to the standard strict-weak >> ordering for a type where possible. > > Convenient maybe. Is it advisable for a stand

[swift-evolution] [Pitch] Guarding on enum values

Motivation The guard statement rescues us from the pyramid of doom, and lets our code hug the left margin more... if the failure case is false or nil. I'd like to guard against specific values in an enum, and get the same flattening of code flow. This generalizes Swift’s convenient handling of

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

> I don’t see any problem in referring to the feature as associated types, but > then having the syntax be just plain “type”. I think it's been said before, but the problem with using a `type` keyword is that if you type "swift type" into Google (or any other search feature you might use for do

Re: [swift-evolution] [Review] Tuple comparison operators (was: Add a Lazy flatMap for Sequences of Optionals)

> * What is your evaluation of the proposal? This is a very useful addition to the standard library, implemented given current limitations of the language (without variadic generics). The only concern is code size, and it will be mitigated by choosing a reasonable number of overloads to implement

Re: [swift-evolution] Proposal - Allow properties in Extensions

> On Dec 22, 2015, at 7:40 PM, Jordan Rose wrote: >> On Dec 18, 2015, at 20:11 , Chris Lattner via swift-evolution >> wrote: >> >> On Dec 18, 2015, at 4:11 PM, John McCall via swift-evolution >> wrote: One potentially large downside is you can no longer look at a type declara

Re: [swift-evolution] [Proposal] Property behaviors

> You shouldn’t have to say myProperty.lazy.backingStore.clear(), just > myProperty.lazy.clear(). > > I don’t know where that leaves us :-) I wonder if these should all just be flattened into the instance that owns the property. So instead of saying foo.myProperty.lazy.clear(), you just say fo

Re: [swift-evolution] [Review] Tuple comparison operators (was: Add a Lazy flatMap for Sequences of Optionals)

> On 22 déc. 2015, at 19:40, Dave Abrahams wrote: > > It’s very convenient for “<“ to correspond to the standard strict-weak > ordering for a type where possible. Convenient maybe. Is it advisable for a standard library feature? Doubtful. This is about the definition of <. It means “less th

Re: [swift-evolution] Lambda function syntax

I think "in" is slightly easier to type in than "=>". The => may be interpreted as equal or greater than. On Dec 22, 2015, at 9:52 PM, Andrey Tarantsov via swift-evolution wrote: >> And yes, I certainly would prefer `=>` rather than `in`. > > It seems like the community can actually agree

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

Yes, true, it’s not quite a parameter because it can’t vary. But in the sense that it’s a slot that you have to provide a value for, you might call it a parameter. Having the syntax be “type parameter” gives a further hint that there’s more to it than a regular parameter. But having said that

Re: [swift-evolution] Lambda function syntax

Hi, Alexander. For your most recent version, what does the syntax look like when there are explicit types? As far as I can tell the only change is substituting "in" for "=>", which means taking an existing keyword (from 'for' loops) and replacing it with what's currently a valid operator. We de

Re: [swift-evolution] Final by default for classes and methods

> On Dec 22, 2015, at 6:24 PM, Dave Abrahams wrote: > >> On Dec 22, 2015, at 9:03 AM, Paul Cantrell via swift-evolution >> wrote: >> >> I weigh the safety argument against the many long hours I’ve spent beating >> my head against library behaviors, wishing I could read UIKit’s source code,

Re: [swift-evolution] Lambda function syntax

The standard map syntax is directly inspired by that of C#. For Swift, I’d be relatively happy with something like the following (repeating what’s already been said I believe) map ({ x => x + 5 }) or using trailing closure map { x => x + 5 } with the possibility of an additional single-line o

Re: [swift-evolution] Proposal: Python's indexing and slicing

> On Dec 21, 2015, at 19:47 , Kevin Ballard via swift-evolution > wrote: > > On another note, I'm tempted to say that we should use $start and $end > instead of $.start and $.end. The compiler doesn't currently allow this, > because it expects a number after the $, but I see no reason why we

Re: [swift-evolution] Lambda function syntax

It has probably been 6 months since I have had time to do anything interesting (JDK6 + Oracle SQL recently for contracts recently) so if I am messing up terminology or syntax - please excuse me. I messed a few things up and had to open up an old Scala project to remind me what I was doing. Th

Re: [swift-evolution] Proposal - Allow properties in Extensions

> On Dec 18, 2015, at 20:11 , Chris Lattner via swift-evolution > wrote: > > On Dec 18, 2015, at 4:11 PM, John McCall via swift-evolution > wrote: >>> >>> One potentially large downside is you can no longer look at a type >>> declaration and find out how large it is. For example, I could de

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

> I don’t see how this: > > protocol P { > type/*alias*/ A > } > > struct X : P { > struct A {} > } > > is fundamentally any different from: > > protocol P { > func f() > } > > struct X : P { > func f() {} > } > > What am I missing? I'd say it's the fact that adding an associated typ

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

> On 22 déc. 2015, at 19:01, Douglas Gregor via swift-evolution > wrote: > > >> On Dec 22, 2015, at 11:05 AM, Matt Whiteside via swift-evolution >> wrote: >> >> “parameter” is a good thought. On it’s own it seems like it’s missing >> something though. But it gives me other ideas: “typepa

Re: [swift-evolution] Lambda function syntax

It would not prevent curly brackets for single-line cases…. just the difference between a map function call map() vs infix with scope. > On 2015-12-23, at 9:48:24, Alexander Regueiro wrote: > > Why not curly braces for single-line and multi-line cases? About the brackets > around multiple

Re: [swift-evolution] Lambda function syntax

> foo.map( bar => bar.boz) // single line Well how important is it to use () instead of {} here? If you make it foo.map { bar => bar.boz } then it's like it is now, but with "in" replace by "=>". > foo.map { (x, y) => x * 5 + y } I actually like the bare version: foo.map { x, y => x * 5 + y

Re: [swift-evolution] Lambda function syntax

Why not curly braces for single-line and multi-line cases? About the brackets around multiple parameters: like I said before, no strong opinion either way. > On 23 Dec 2015, at 02:46, Craig Cruden wrote: > > I am joining this discussion a little late - so I would not be surprised if > discusse

Re: [swift-evolution] Lambda function syntax

I am joining this discussion a little late - so I would not be surprised if discussed earlier. but: My preference would be: foo.map( bar => bar.boz) // single line or foo.map { bar => …. } if more than one line if there are multiple values then: foo.map {

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

> On Dec 22, 2015, at 5:51 PM, Erica Sadun wrote: > >> >> On Dec 22, 2015, at 6:25 PM, Dave Abrahams > > wrote: >> >>> >>> On Dec 22, 2015, at 9:30 AM, Erica Sadun via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> As SE-0011 states, the co

Re: [swift-evolution] [Review] Tuple comparison operators (was: Add a Lazy flatMap for Sequences of Optionals)

> On Dec 22, 2015, at 6:28 PM, Guillaume Lessard > wrote: > > >> On 22 déc. 2015, at 18:11, Dave Abrahams wrote: >> Yes, the mathematical definition of lexicographical order (the only >> definition that can apply here) is the same everywhere. > > Okay. I got sidetracked by “lexicography”. I

Re: [swift-evolution] Lambda function syntax

One thing I'm really bothered by in C# and ES6 are no-argument methods: () => { foo() } // GROSS The syntax of C# isn't so bad, though, when there's no return type: foo.map((bar) => bar.boz) but those double-parens bother me and my eyes a bit, so this definitely looks better: foo.map { (bar

Re: [swift-evolution] Lambda function syntax

Fair suggestion. I’d give this my vote, in fact. > On 23 Dec 2015, at 02:34, Craig Cruden wrote: > > I would prefer the type definition for functions return type to be the same > syntax as the type definition for parameters - which would leave the arrows > for things like lambdas. > > i.e. >

Re: [swift-evolution] Lambda function syntax

I would prefer the type definition for functions return type to be the same syntax as the type definition for parameters - which would leave the arrows for things like lambdas. i.e. func test(symbol: String): Bool { } > On 2015-12-23, at 9:30:24, Andrey Tarantsov via swift-evolution

Re: [swift-evolution] Lambda function syntax

This was my first proposal, and was changed my second, but this syntax is inspired by C#, where a lambda expression is of one of the following forms: (Type1 param1, …) => foo // single-statement expression (Type1 param1, …) => { …; return foo; } // multi-statement expression Haskell also uses sy

Re: [swift-evolution] Lambda function syntax

So I believe the opinion of the core team and the community would be generally in opposition to the style you want. I understand your arguments, but somehow they are against the entire experience of me (and, presumably, others) as developers. To continue our friendly banter, though, do you mind

Re: [swift-evolution] [Review] Tuple comparison operators (was: Add a Lazy flatMap for Sequences of Optionals)

> On 22 déc. 2015, at 18:11, Dave Abrahams wrote: > Yes, the mathematical definition of lexicographical order (the only > definition that can apply here) is the same everywhere. Okay. I got sidetracked by “lexicography”. I like to buy dictionaries. This converges on the problem, though: this-p

Re: [swift-evolution] Lambda function syntax

Disagree, disagree, disagree. Don’t see any logic to that. On 23 Dec 2015, at 02:10, Andrey Tarantsov wrote: > > Can't help commenting... > >> I can only see subjective “dislike this”. > > The feel of the language is very important. We're talking about improving the > syntax to look better he

Re: [swift-evolution] Coroutine for Swift

Hi, I just want a wide public concern in swift community with this implementation. Should we have a proposal about @goto and @label as workaround? Just a joke ;) Chris Lattner 於 2015年12月23日星期三 寫道： > Hi Susan, > > As I mentioned on your original pull request, coroutines are closely > related to

Re: [swift-evolution] Lambda function syntax

Can't help commenting... > I can only see subjective “dislike this”. The feel of the language is very important. We're talking about improving the syntax to look better here, so of course the subjective look of it matters most. > Using “func” or “lambda” outside is uglier than “in” inside the b

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

> On Dec 22, 2015, at 11:05 AM, Matt Whiteside via swift-evolution > wrote: > > “parameter” is a good thought. On it’s own it seems like it’s missing > something though. But it gives me other ideas: “typeparam”, “type param", > “typeparameter”, or “type parameter”. It’s not a parameter, t

Re: [swift-evolution] Proposal Sketch: Bring flexible array members in as Array|UnsafeReference

On Tue, Dec 22, 2015 at 2:29 PM, T.J. Usiyan via swift-evolution < swift-evolution@swift.org> wrote: > MIDIMetaEvent and MIDIEventUserData are both examples of framework > provided types which rely on flexible member arrays. Their last member is > (officially) an array of UInt8 with 1 element. In

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

> On Dec 22, 2015, at 6:25 PM, Dave Abrahams wrote: > >> >> On Dec 22, 2015, at 9:30 AM, Erica Sadun via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> As SE-0011 states, the concept of typealias is overloaded. >> In one case, it's really just typedef. >> In the other it

Re: [swift-evolution] Optional dictionary subscripts

I think this would be the standard syntax: if let value = key.map({ dict[$0] }) { } > On Dec 22, 2015, at 10:33 AM, Félix Cloutier via swift-evolution > wrote: > > if let value = map(key) { dict($0) } > > Félix > >> Le 22 déc. 2015 à 13:00:45, Erica Sadun via swift-evolution >> a écrit :

Re: [swift-evolution] [Pitch] Achieving a heterogeneous collection of Equatables

On Tue, Dec 22, 2015 at 10:18 PM, Joe Groff wrote: > What you're proposing is closer to the other approach I laid out, allowing protocol types to be > extended to conform to protocols themselves I couldn't find the thread you've explained this earlier, so I'm going by what you've described in th

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

> On Dec 22, 2015, at 9:30 AM, Erica Sadun via swift-evolution > wrote: > > As SE-0011 states, the concept of typealias is overloaded. > In one case, it's really just typedef. > In the other it's a stand-in for a deferred type that is specified by > conforming classes. > While you could arg

Re: [swift-evolution] Proposal Sketch: Bring flexible array members in as Array|UnsafeReference

In general, I find that importing C arrays is problematic. I don't have any nice solution to offer, though. For now, you might be able to get away with withUnsafePointer(&event.data) { ... }. Félix > Le 22 déc. 2015 à 17:29:10, T.J. Usiyan via swift-evolution > a écrit : > > MIDIMetaEvent a

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

I would much prefer one of the longer terms such as 'associatedtype' to 'type'. The simple reason why: I've been using a lot of generics for a while and I still find it tricky. I want a term I can type into a search engine and expect results for, and 'type's too common for that. On Tue, Dec 22, 20

Re: [swift-evolution] [swift-build-dev] [Proposal] Lock file for Swift Package Manager

> On 23 Dec 2015, at 9:28 AM, Joshua Scott Emmons via swift-build-dev > wrote: > > There are three things that should be possible at this point: > 1. Build with the existing v1.1 dep. > 2. Update deps to the lockfile version (v1.2). > 3. Update deps and lockfile to the latest conforming versio

Re: [swift-evolution] [swift-build-dev] [Proposal] Lock file for Swift Package Manager

> I’d prefer a workflow that omits —bootstrap, to repeat my previous email: > > If the lock file is committed I think swift-build should always use it. If > the user wants newer updates they can execute `swift build —update`. > > This makes understanding what happens simpler: `swift build` alway

Re: [swift-evolution] swift-evolution Digest, Vol 1, Issue 227

Perhaps if enums were automatically indexed by the compiler for the order of the case declerations? enum Food {    case Fruit    case Vegetable    case Meat } Food.Fruit.index == 0 Food.Vegetable.index == 1 Food.Meat.index == 2 3. Re: Proposal: Enum 'count' functionality (Joe Groff) Messag

Re: [swift-evolution] [swift-build-dev] [Proposal] Lock file for Swift Package Manager

> On Dec 22, 2015, at 2:50 PM, Max Howell wrote: > >>> I’d prefer a workflow that omits —bootstrap, to repeat my previous email: >>> >>> If the lock file is committed I think swift-build should always use it. If >>> the user wants newer updates they can execute `swift build —update`. >>> >>>

Re: [swift-evolution] [Review] Tuple comparison operators (was: Add a Lazy flatMap for Sequences of Optionals)

> On Dec 22, 2015, at 2:44 PM, Guillaume Lessard via swift-evolution > wrote: > > >> On 22 déc. 2015, at 14:03, Kevin Ballard via swift-evolution >> wrote: >> >> On Tue, Dec 22, 2015, at 10:39 AM, Guillaume Lessard via swift-evolution >> wrote: >>> >>> The justification for making Tuples

Re: [swift-evolution] [Review] Tuple comparison operators (was: Add a Lazy flatMap for Sequences of Optionals)

> On Dec 22, 2015, at 10:39 AM, Guillaume Lessard > wrote: > > I wholeheartedly support the Equatable (==) portion of this proposal. > I’m quite negative about the Comparable portion; it doesn’t really make sense. > > The justification for making Tuples comparable pretty much consists of > ha

Re: [swift-evolution] Final by default for classes and methods

> On Dec 22, 2015, at 11:03 AM, Paul Cantrell via swift-evolution > wrote: > > I’m not totally opposed to final by default. Joe’s arguments sway me in > principle. In practice, if Swift does indeed moves us toward “less wiggle > room, less hackable” by default, then that wiggle room _will_ ha

Re: [swift-evolution] Final by default for classes and methods

> On Dec 22, 2015, at 9:03 AM, Paul Cantrell via swift-evolution > wrote: > > Joe’s and Brent’s writeups copied below really get to the heart of this for > me. This is a tough question, and I find myself torn. I’m sympathetic to both > lines of argument. > > It’s not entirely true that “you

Re: [swift-evolution] Lambda function syntax

>> I’ve also explained the big problem with trailing closures already. And >> closures are really *not* control flow statements, so treating like them is >> just a fallacy and source of confusion. > > Trailing closures allow you to write constructs that look and act as if they > were control fl

Re: [swift-evolution] Lambda function syntax

> On Dec 22, 2015, at 3:45 PM, Alexander Regueiro via swift-evolution > wrote: > > I’ve also explained the big problem with trailing closures already. And > closures are really *not* control flow statements, so treating like them is > just a fallacy and source of confusion. Trailing closures

Re: [swift-evolution] Final by default for classes and methods

It comes down to a few issues: 1. Final exists in the language. This itself creates headaches for framework makers when their framework classes need to become “final” at a later stage. What do you do with the old subclasses in an app that shipped 5 years ago subclassing a now-final class? 2. M

Re: [swift-evolution] Final by default for classes and methods

I could read the entire conversation because following the web archives is super unintuitive. So feel free to answer me with a bunch of links if you think my question was already answered. Isn't this proposal solving a problem that in practice doesn't exist or isn't common enough to be worth a

Re: [swift-evolution] Lambda function syntax

Sorry, but I don’t think you could be more wrong on every point. I’ve clearly detailed why my solution is superior (both factually and in my opinion), and I can only see subjective “dislike this”. Using “func” or “lambda” outside is uglier than “in” inside the braes? Really? That just boggles m

Re: [swift-evolution] Final by default for classes and methods

> On Dec 22, 2015, at 11:31 AM, Kevin Ballard via swift-evolution > wrote: > > UIKit classes aren't subclassable because of a lack of sealed-by-default, > they're subclassable because until very recently there was no way to mark > classes as not being subclassable. There are two historical w

Re: [swift-evolution] Proposal: Add a Future type to the language

> I would much rather see the language adopt something more akin to C#’s > Async-Await, where the compiler handles restructuring synchronous-looking > code into something asynchronous and non-blocking. Agreed. The ‘when let’ syntax in my ‘proposal’ is a play on C#’s await. I think it’d be great

Re: [swift-evolution] Final by default for classes and methods

> On 23 Dec 2015, at 7:20 AM, Tino Heth via swift-evolution > wrote: > You're quite right, but imho the whole issue is bigger than a few characters > that have to be typed to get the desired inheritance characteristic: That > would not drive discussion that long. > It's also about the philosoph

Re: [swift-evolution] [Review] Tuple comparison operators (was: Add a Lazy flatMap for Sequences of Optionals)

> On 22 déc. 2015, at 14:03, Kevin Ballard via swift-evolution > wrote: > > On Tue, Dec 22, 2015, at 10:39 AM, Guillaume Lessard via swift-evolution > wrote: >> >> The justification for making Tuples comparable pretty much consists of >> hand-waving. >> Why should (0,3,4) be smaller than (0,

[swift-evolution] Proposal Sketch: Bring flexible array members in as Array|UnsafeReference

MIDIMetaEvent and MIDIEventUserData are both examples of framework provided types which rely on flexible member arrays. Their last member is (officially) an array of UInt8 with 1 element. In practice, developers are meant to allocate enough space for an array of the necessary length along with the

Re: [swift-evolution] Coroutine for Swift

Chris, Susan, fwiw, this looks pretty similar to how we have Iterators as extension on our Swift compiler: http://docs.elementscompiler.com/Silver/LanguageExtensions/Iterators/. Looking forward to (something like) this becoming part of official Swift — the more custom extensions we can get rid

Re: [swift-evolution] Proposal: Python's indexing and slicing

There’s two different issues here, as far as I can tell. (both of which the $ operator seems to be trying to solve) The first is being able to use the start and end indices of a collection in a more concise way, so you can write ar[$3..<$] instead of ar[(ar.startIndex+3).. On 22 Dec 2015, at 21:

Re: [swift-evolution] Coroutine for Swift

Hi Susan, As I mentioned on your original pull request, coroutines are closely related to async and other concurrency forms. That entire space is out of scope for Swift 3, so we should wait until fall 2016 to pick up discussion on this and related topics. -Chris > On Dec 22, 2015, at 12:16 P

Re: [swift-evolution] Compile time assertion / checking?

Joe, > Given the deep dependence in our standard library on LLVM primitives and > semantics, as well as the rather messy interactions between our compiler, > stdlib, and runtime in general, I'm not sure that's a practical goal. Probably not no. I just figured, the more syntax — even internal/h

Re: [swift-evolution] Proposal: Python's indexing and slicing

It was an intentional decision for Swift's indexes to not be based on offset indexing. In many cases (including indexing into strings) calculating index offsets is an O(N) operation. The design of Swift's indexes is such that you pay the cost when constructing an index, rather than when using the i

Re: [swift-evolution] [Review] Tuple comparison operators (was: Add a Lazy flatMap for Sequences of Optionals)

On Tue, Dec 22, 2015, at 10:39 AM, Guillaume Lessard via swift-evolution wrote: > I wholeheartedly support the Equatable (==) portion of this proposal. > I’m quite negative about the Comparable portion; it doesn’t really make sense. > > The justification for making Tuples comparable pretty much co

Re: [swift-evolution] Run Swift code at compile time

I don’t know if something like this has been done before, but I agree, the idea of the compile time version of the language being the same same as the runtime version, is very interesting. +1. Matt > On Dec 20, 2015, at 21:43, Tyler Fleming Cloutier via swift-evolution > wrote: > > Woah, Ale

Re: [swift-evolution] Swift case conventions for Enums

I’ve run into a few situations where the reverse is true, for example: enum Priority { case Low, Default, High } I would not be able to use the word “default” if it was lowercase since it would conflict with the keyword. In fact, in this one project, I have at least 2 enums that would have

Re: [swift-evolution] Proposal: Python's indexing and slicing

I don’t think I am. Maybe I’m confused: the current suggestion is the addition of a $ operator (or labelled subscripts, or another operator) to signify “offset indexing”, yes? As in: someCollection[$3] == someCollection[someCollection.startIndex.advancedBy(3)] someCollection[$3..<$] == someColl

Re: [swift-evolution] [swift-build-dev] [Proposal] Lock file for Swift Package Manager

>> I’d prefer a workflow that omits —bootstrap, to repeat my previous email: >> >> If the lock file is committed I think swift-build should always use it. If >> the user wants newer updates they can execute `swift build —update`. >> >> This makes understanding what happens simpler: `swift build`

Re: [swift-evolution] Proposal: Add a Future type to the language

Like you mentioned, the Swift team has made it very clear that concurrency is out of scope for Swift 3, and we probably won’t see it until at least Swift 4 at a bare minimum. That said, while your proposal is a much better alternative to the completion handler pyramids of doom we have today, I’

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

The fact that “associated type” is used throughout the documentation is worth making note of, but it could also be that some other replacement would make the concept more clear than it currently is in the documentation. Matt > On Dec 22, 2015, at 09:30, Erica Sadun via swift-evolution > wrote

Re: [swift-evolution] [Proposal] Lock file for Swift Package Manager

> On Dec 22, 2015, at 3:24 PM, Paul Cantrell wrote: > > I share Rick’s concerns about any proposal that pushes locked versions > downstream to dependent projects. Two thoughts on that: > > First, the specific: a lockfile should lock the versions for all > dependencies, direct and indirect. Li

Re: [swift-evolution] [Proposal] Lock file for Swift Package Manager

I share Rick’s concerns about any proposal that pushes locked versions downstream to dependent projects. Two thoughts on that: First, the specific: a lockfile should lock the versions for all dependencies, direct and indirect. Library lockfiles should have no effect on downstream projects. (Bun

Re: [swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

I still prefer "type" as "associatedtype" is quite a mouthful and, really being two words, quite untypical for a keyword. And required functions etc. use simply "func" instead of "requiredfunc" as well. -Thorsten > Am 22.12.2015 um 18:30 schrieb Erica Sadun via swift-evolution > : > > As SE-

Re: [swift-evolution] Final by default for classes and methods

> Whether the language has final-by-default/sealed-by-default doesn't really > affect this in any way. I guarantee you that once Apple starts putting Swift > code in their frameworks, every single framework class Apple releases is > going to make an explicit decision about being final/sealed vs

Re: [swift-evolution] Final by default for classes and methods

In principle I agree the proposed "sealed by default." The arguments are compelling. A lot of us, including myself, are working from a point of fear that this system will be used by framework providers to institute rigidity and inflexibility into frameworks where that is not required, in a way

Re: [swift-evolution] Coroutine for Swift

Hi Daniel, I've heard many great things about goroutines, and I definitively think their advantages should be considered in the design of Swift's concurrency. I haven't used goroutines much so I may be incorrect, but I don't think they can be used to efficiently represent a generator like the pro

Re: [swift-evolution] Proposal: Python's indexing and slicing

On Mon, Dec 21, 2015, at 08:28 PM, Donnacha Oisín Kidney wrote: > Why not make the “forgiving” version the default? I mean, the majority of > python-style composable slicing would be happening on arrays and array > slices, for which there’s no performance overhead, and the forgiving version > wo

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

> On Dec 22, 2015, at 11:38 AM, Félix Cloutier wrote: > > > Sorry to sidetrack the discussion, but does that mean that using `let` > properties in a type where memory layout is important is possibly not > forward-compatible? Swift has no support for such a type, when it does, it should be opt

Re: [swift-evolution] ternary operator ?: suggestion

> Am 22.12.2015 um 19:30 schrieb Félix Cloutier : > This is essentially the latest proposal that Paul offered. The most similar proposal in his last mail seemed to be the following: >> let b = switch(colorEnum then .Red: 0xFF, .Green: 0x00FF00, .Blue: >> 0x0FF, default: 0xFF) This

[swift-evolution] Pre-proposal: Convert reference params to tuples

This is a re-post of a proposal I previously submitted to Radar. This seems like a more appropriate place for it, though, and since Apple seems to be planning a heuristic mechanism to rewrite Objective-C APIs to make them more idiomatic to Swift (https://github.com/apple/swift-evolution/blob/ma

Re: [swift-evolution] Final by default for classes and methods

Kevin, I feel like our messages came in the opposite order — my previous message is essentially an answer to what you wrote! I agree that Apple is going to think carefully about what is subclassable / overridable when given that option. I agree that third-party library authors ought to do this

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

> Problem 2: This can cause very surprising performance issues, because it > forces the let property to be stored. With the previous example, it is a > goal for us to be able to compile: > > public class X { > let a = 42 > } > > into the equivalent of: > > public class X { > var a : Int {

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

(adding on) > On 22 déc. 2015, at 12:02, Matthew Johnson wrote: > > Why would you have an immutable instance member that is always going to have > a constant value of 1? That’s obviously a toy example. You can also use function calls, and that’s useful: public struct A { public let propert

Re: [swift-evolution] [Proposal idea] Improved interop for ErrorType->NSError

Sent from my iPhone On Dec 22, 2015, at 1:26 PM, Paul Cantrell via swift-evolution wrote: >> On Dec 22, 2015, at 12:03 PM, Chris Lattner wrote: >> On Dec 22, 2015, at 9:44 AM, David Owens II via swift-evolution wrote: On Dec 22, 2015, at 9:30 AM, Paul Cantrell via swi

Re: [swift-evolution] Make non-void functions @warn_unused_result by default

On Mon, Dec 21, 2015, at 11:17 PM, Brent Royal-Gordon wrote: > > And that brings to mind a second question: How about functions that are > > generic in their return type? For example, > > `withExtendedLifetime(_: T, _: T throws -> Result) rethrows -> > > Result`. The return type may be Void in m

Re: [swift-evolution] Final by default for classes and methods

UIKit classes aren't subclassable because of a lack of sealed-by-default, they're subclassable because until very recently there was no way to mark classes as not being subclassable. Many classes in UIKit are designed to handle subclassing, but some classes are not designed to handle that, and a

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

> On Dec 22, 2015, at 8:46 AM, Matthew Johnson wrote: > > Hi Chris, > > I have given your feedback a lot of thought and have taken another run at > this proposal from a slightly different angle. I believe it is a significant > improvement. Hi Matthew, I continue to really like the approa

Re: [swift-evolution] [Proposal idea] Improved interop for ErrorType->NSError

> On Dec 22, 2015, at 12:03 PM, Chris Lattner wrote: > >> On Dec 22, 2015, at 9:44 AM, David Owens II via swift-evolution >> wrote: >> >>> On Dec 22, 2015, at 9:30 AM, Paul Cantrell via swift-evolution >>> wrote: >>> >>> Hmm, I wonder if #1 or #4 suggest any language changes to propose for

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

I would like let rules to be consistent whether you have a memberwise init or not; and I would like them to be consistent with classes. I think this places me on Guillaume's side here. Félix > Le 22 déc. 2015 à 14:20:47, Guillaume Lessard via swift-evolution > a écrit : > > >> On 22 déc. 20

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

> On 22 déc. 2015, at 12:02, Matthew Johnson wrote: > > This is not an attempt to subvert `let` properties. The `= 1` in the > declaration can very reasonably be viewed as a default value that should be > used if the member is not otherwise initialized. I see it as a definition. > Why woul

  1   2   3   >