Re: [swift-evolution] Making capturing semantics of local functions explicit

class A { func foo() -> ()->String { func local() -> String { [weak self] in return "foo \(self.i)" } return local } ... compares well with this... class A { func foo() -> ()->String { let local : () -> String = { [weak self] in

Re: [swift-evolution] Making capturing semantics of local functions explicit

i support this™ On Wed, Oct 25, 2017 at 6:41 AM, David Hart via swift-evolution < swift-evolution@swift.org> wrote: > I got bit again by a sneaky memory leak concerning local functions and > would like to discuss a small language change. I vaguely remember this > being discussed in the past, but

Re: [swift-evolution] Making capturing semantics of local functions explicit

I agree; I think the 'in' should be there. This should be fairly straight-forward to implement right? It's just alternative syntax over existing behavior. (thinking about the proposal now...) On Wed, Oct 25, 2017 at 5:45 PM, John McCall via swift-evolution < swift-evolution@swift.org> wrote: >

Re: [swift-evolution] Pitch: Member lookup on String should not find members of NSString

I don’t think anyone is really looking at that at the time but +1 to bringing NSString functionality to String. This is something that gets talked about a lot but no one has really sat down to outline what such an API would look like. On Wed, Oct 25, 2017 at 3:24 PM, David Hart via

Re: [swift-evolution] Standard error?

This has been on my wishlist for a long time and I don’t think it’s in the Swift stdlib. You have to import Darwin/Glibc. On Wed, Oct 25, 2017 at 3:51 PM, Daryle Walker via swift-evolution < swift-evolution@swift.org> wrote: > Been looking at the Swift standard library pages at Apple’s website.

Re: [swift-evolution] Making capturing semantics of local functions explicit

> On Oct 25, 2017, at 4:21 PM, David Hart wrote: >> On 25 Oct 2017, at 19:01, John McCall > > wrote: >> >>> On Oct 25, 2017, at 7:41 AM, David Hart via swift-evolution >>>

[swift-evolution] Standard error?

Been looking at the Swift standard library pages at Apple’s website. There’s “print” and “readLine” for I/O to/from standard output/input. Put there seems to be no function for standard error. The “print” function has an overload for custom streams, but there doesn’t seem to be an object that

Re: [swift-evolution] Pitch: Member lookup on String should not find members of NSString

> On 25 Oct 2017, at 15:29, Matthew Johnson via swift-evolution > wrote: > > > > Sent from my iPad > >> On Oct 24, 2017, at 5:55 PM, Slava Pestov via swift-evolution >> wrote: >> >> I think to maintain source compatibility, the old

Re: [swift-evolution] Making capturing semantics of local functions explicit

> On 25 Oct 2017, at 19:01, John McCall wrote: > >> On Oct 25, 2017, at 7:41 AM, David Hart via swift-evolution >> > wrote: >> I got bit again by a sneaky memory leak concerning local functions and would >> like

Re: [swift-evolution] [SPM] Roadmap?

To clarify. I meant the infrastructure for IDE integration with Xcode as one of the IDEs that used that infrastructure. -- Howard. > On 24 Oct 2017, at 11:26 pm, David James via swift-evolution > wrote: > > I would also +1000 Xcode integration, whoever does it.

Re: [swift-evolution] Making capturing semantics of local functions explicit

Does the compiler treat a nested function differently from a closure in any meaningful way? (I suppose they might have symbols emitted in the symbol table, whereas a closure assigned to a local variable wouldn't?) It definitely seems odd that you can write two functionally equivalent pieces of

Re: [swift-evolution] [draft] Introduce Sequence.filteredMap(_:)

> On Oct 25, 2017, at 2:15 AM, Tino <2...@gmx.de> wrote: > > >>> It’s unfortunate when a piece of code gets a different meaning — but as you >>> said: >>> It’s a misuse, and when you write code that is wrong, the results might be >>> wrong as well. >> And this is exactly that we’re trying to

Re: [swift-evolution] Making capturing semantics of local functions explicit

> On Oct 25, 2017, at 4:41 AM, David Hart via swift-evolution > wrote: > > I got bit again by a sneaky memory leak concerning local functions and would > like to discuss a small language change. I vaguely remember this being > discussed in the past, but can’t find

Re: [swift-evolution] Making capturing semantics of local functions explicit

> On Oct 25, 2017, at 7:41 AM, David Hart via swift-evolution > wrote: > I got bit again by a sneaky memory leak concerning local functions and would > like to discuss a small language change. I vaguely remember this being > discussed in the past, but can’t find the

Re: [swift-evolution] Pitch: Deprecate/remove AnyObject method dispatch

> On Oct 25, 2017, at 10:27 AM, BJ Homer wrote: > > That would be a Cocoa-side change, since UIView, NSView, NSMenuItem, NSCell > are all Cocoa-level objects. (I’m not aware of any other type that would be > commonly passed as a ‘sender’ parameter and would have a tag.) That

Re: [swift-evolution] Pitch: Deprecate/remove AnyObject method dispatch

That would be a Cocoa-side change, since UIView, NSView, NSMenuItem, NSCell are all Cocoa-level objects. (I’m not aware of any other type that would be commonly passed as a ‘sender’ parameter and would have a tag.) That change wouldn’t go through Swift-Evolution. So in theory, if Swift 5

Re: [swift-evolution] Pitch: Deprecate/remove AnyObject method dispatch

I guess, but doesn’t it seem far more elegant to have a protocol for tag-containing objects? This is a feature that’s pretty heavily used… Charles > On Oct 24, 2017, at 6:06 PM, Slava Pestov wrote: > > You can implement an @objc protocol with an optional requirement, and

Re: [swift-evolution] Pitch: Member lookup on String should not find members of NSString

Sent from my iPad > On Oct 24, 2017, at 5:55 PM, Slava Pestov via swift-evolution > wrote: > > I think to maintain source compatibility, the old behavior would be preserved > until/if we remove -swift-version 4 mode. By deprecating it though, we won’t > have to

[swift-evolution] Making capturing semantics of local functions explicit

I got bit again by a sneaky memory leak concerning local functions and would like to discuss a small language change. I vaguely remember this being discussed in the past, but can’t find the thread (if anybody could point me to it, I’d appreciate it). Basically, here’s an example of the leak:

Re: [swift-evolution] [draft] Introduce Sequence.filteredMap(_:)

>> It’s unfortunate when a piece of code gets a different meaning — but as you >> said: >> It’s a misuse, and when you write code that is wrong, the results might be >> wrong as well. > And this is exactly that we’re trying to address. Not the impurity of the > function, not the performance,

Re: [swift-evolution] Pitch: Deprecate/remove AnyObject method dispatch

yes, please. Especially having quite a long time (4.1 until 5.0) where this works but issues a warning sounds like a great transition plan. > On 24 Oct 2017, at 11:02 pm, Slava Pestov via swift-evolution > wrote: > > Hi all, > > Dynamic dispatch of methods through

Re: [swift-evolution] Pitch: Member lookup on String should not find members of NSString

+1, it's currently really non-obvious where these automatic bridges are happening which keeps costing me time. > On 24 Oct 2017, at 11:00 pm, Slava Pestov via swift-evolution > wrote: > > Hi, > > Members of NSString, except those defined in Foundation, are

Re: [swift-evolution] Opaque Pointers in Swift

> On 24 Oct 2017, at 18:23, Johannes Weiß wrote: > > How do people think about this proposed change? I think keeping type information on OpaquePointer would be extremely useful, and definitely improves some of the sharp edges of that type. > this should solve your

Re: [swift-evolution] [draft] Target environment platform condition

Could this be an extra parameter for the os() platform condition? #if os(iOS, simulator) #if os(Android, emulator) -- Ben > On 25 Oct 2017, at 04:05, Graydon Hoare wrote: > > Hi, > > I'd like to propose a variant of a very minor, additive proposal Erica Sadun > posted last year, that cleans

Re: [swift-evolution] [draft] Target environment platform condition

The arguments to platform conditions aren't keywords; it's true that they're unquoted identifiers but they're treated more like contextual keywords or predefined constants: they're only defined in the argument positions of the conditions they're associated with. Fwiw, Haiku is already in the