Re: [swift-evolution] Should we relax restriction on closing over outer scope in class declarations?

> On 22 Dec 2016, at 22:39, Micah Hainline via swift-evolution > wrote: > > Currently we allow declarations of a new class in local scope, but > nothing can be referenced from the outer scope. Thus this is illegal: > > ``` > func foo() { > let widgetString: String = createWidgetString() >

Re: [swift-evolution] URL Literals

> On Dec 20, 2016, at 12:29 PM, David Sweeris wrote: > >> >> On Dec 20, 2016, at 2:11 AM, Jonathan Hull via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> Yes, I agree. I am excited to see what happens in phase 2. >> >> What I am suggesting here is slightly different. Ba

Re: [swift-evolution] URL Literals

We're nowhere close to bikeshedding the name yet; people are calling it constexpr to mean that the idea is something along the lines of C++'s constexpr, as opposed to C++'s const. Mentally substitute whatever word you want at the moment. On Fri, Dec 23, 2016 at 02:15 Georgios Moschovitis < george

Re: [swift-evolution] Should we relax restriction on closing over outer scope in class declarations?

Only if you're also assuming that people defining classes within functions would know about capturing. This violates the principle of progressive disclosure, since people naturally learn about functions and classes before they learn about closures and capturing. On Fri, Dec 23, 2016 at 01:51 Call

Re: [swift-evolution] Pattern matching with Arrays

> Yeah, this is something I've wanted to add for a while, along with pattern > matching for dictionaries, which together with array matching I think would > make a lot of JSON/plist wrangling much more pleasant. +1 ___ swift-evolution mailing list swif

Re: [swift-evolution] URL Literals

> As a bonus (IMHO, anyway) adding `@constexpr` would lay the groundwork for > adding `@pure` later on, both in Could that be just `@const` (since that keyword is not reserved yet)? Or something else? It bugs be that the `constexpr` keyword is hard to pronounce (and lacks a separator between

Re: [swift-evolution] Should we relax restriction on closing over outer scope in class declarations?

Assuming capture were allowed, people defining classes within functions who didn't want them to capture could position the class definition prior to any other code in the function so that there would be nothing to capture. On Thu, Dec 22, 2016 at 4:13 PM Xiaodi Wu via swift-evolution < swift-evolu

Re: [swift-evolution] Pattern matching with Arrays

> On Dec 17, 2016, at 9:43 PM, Mathew Sanders via swift-evolution > wrote: > > I've just joined the list (hi!) so not sure if this has been discussed in the > past. > > Curious to hear if a future version of Swift might ever include some sort of > pattern-matching extended to Arrays. Maybe s

[swift-evolution] Three quick(ish) generics enhancements; *maybe* phase 1

I want to revisit some specific generics idea that, IIRC, were generally well-recieved at the time, but the conversation died down and nobody got around to writing formal proposals. I want to revisit them now (as opposed to in phase 2) because I don’t know how much “growing room” there is in the

Re: [swift-evolution] Pattern matching with Arrays

On Dec 22, 2016, at 8:43 PM, Robert Widmann via swift-evolution wrote: > > Do you think there’s room for a more general Pattern Synonyms-like > feature that could > extend this to things that look tuple-y? We had a short conversation on

Re: [swift-evolution] Pattern matching with Arrays

Do you think there’s room for a more general Pattern Synonyms-like feature that could extend this to things that look tuple-y? We had a short conversation on Twitter 'round about the release of Swift 1.2 about Swiftz’s HList

Re: [swift-evolution] Should we relax restriction on closing over outer scope in class declarations?

I have to agree with Michael; it seems dangerous to allow implicit capture by classes. A primary purpose (telos?) of closures is to provide this functionality, which is actually quite an advanced concept. One knows to think carefully about this when encountering a closure expression. A primary purp

Re: [swift-evolution] Should we relax restriction on closing over outer scope in class declarations?

That's exactly what I'm suggesting, the class declaration could work similarly to a closure. > On Dec 22, 2016, at 4:15 PM, Michael Ilseman wrote: > > Are you asking for a class declaration to implicitly capture and extend the > lifetime of local variables? That seems like something that’s bet

Re: [swift-evolution] Should we relax restriction on closing over outer scope in class declarations?

Are you asking for a class declaration to implicitly capture and extend the lifetime of local variables? That seems like something that’s better done explicitly. Perhaps it’s better to think about how to reduce the boiler plate code, e.g. better default initializers. (this is of course, additiv

[swift-evolution] Should we relax restriction on closing over outer scope in class declarations?

Currently we allow declarations of a new class in local scope, but nothing can be referenced from the outer scope. Thus this is illegal: ``` func foo() { let widgetString: String = createWidgetString() class SimpleProvider: WidgetStringProvider { func provideWidgetString() -> String {

Re: [swift-evolution] "with" operator a la O'Caml?

I believe variables under private(set) can still be accessed with KVC (At least when the class inherits from nsobject.) On Thu, Dec 22, 2016 at 9:19 AM Andy Chou via swift-evolution < swift-evolution@swift.org> wrote: > Point taken. I think Swift supports both styles reasonably well. Initially > i

Re: [swift-evolution] "with" operator a la O'Caml?

Point taken. I think Swift supports both styles reasonably well. Initially it looked like writing the 'with' function would be troublesome but it turned out to be quite simple. I appreciate the point you're making, which is that you get much of the value of purely immutable values with Swift's

Re: [swift-evolution] Pattern matching with Arrays

> On Dec 17, 2016, at 9:43 PM, Mathew Sanders via swift-evolution > wrote: > > I've just joined the list (hi!) so not sure if this has been discussed in the > past. > > Curious to hear if a future version of Swift might ever include some sort of > pattern-matching extended to Arrays. Maybe s

Re: [swift-evolution] "with" operator a la O'Caml?

> On Dec 22, 2016, at 4:54 AM, Jeremy Pereira > wrote: > >> >> On 21 Dec 2016, at 14:07, Matthew Johnson wrote: >> The performance hit is likely a bit larger if you *don't* use a mutable property and instead create a whole new instance. >>> >>> How is >>> >>> let a = So

Re: [swift-evolution] "with" operator a la O'Caml?

> On 21 Dec 2016, at 14:07, Matthew Johnson wrote: > >>> >>> The performance hit is likely a bit larger if you *don't* use a mutable >>> property and instead create a whole new instance. >> >> How is >> >>let a = SomeStruct() >>var b = a >> >> not creating a new instance? > > Of c