Re: [swift-evolution] [Review] SE-0019 Swift Testing (Package Manager)

> On Jan 6, 2016, at 4:06 AM, Rick Ballard via swift-evolution > wrote: > > * What is your evaluation of the proposal? Overall this is great direction, but needs more deliberation and sifting about the details. This kind of infrastructure will live a while, or

[swift-evolution] Keyword Discoverability

Hello all It feels like Swift has some risk of going the direction of C++ at times. By that I mean complexity creep. Increasingly nuanced scoping results in more keywords and constructs. Useful and good but increasingly complex and steepening learning curve. I'd like to kick off discussion

Re: [swift-evolution] [Mini-proposal] Require @nonobjc on members of @objc protocol extensions

Would it not be possible to do the relative analog of Objective-C nullability macro sandwiches in Swift? And then allowing exceptions within the file to be called out explicitly with @nonobjc or @objc ? @begin_assume_nonobjc @end_assume_nonobjc @begin_assume_objc @begin_assume_objc > On Jan 5,

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

I have been thinking about this topic a lot, but not '$' symbol, rather the tools to create DSLs within Swift to enable productive & meaningful special casing. (Ruby's Rake vs Make/GNUMake come to mind a lot, or Ruby's Sinatra web framework come to mind, perhaps Python's Flask to a lesser

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] Closure Syntax

> On Jan 2, 2016, at 9:41 AM, Charles Srstka via swift-evolution > wrote: > >> On Jan 1, 2016, at 5:05 PM, Chris Lattner via swift-evolution >> > wrote: >> >>> On Jan 1, 2016, at 2:21 PM, Ethan Diamond