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

[C. Keith Ray via swift-evolution]

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
return "foo \(self?.i)"
}
return local
}
func foo2() -> ()->String {
let local : () -> String = {
return "foo2 \(self.i)"
}
return local
}
let i : Int
init(_ i: Int) { self.i = i }
}
var a = A(2)
let b = a.foo()
a = A(4)
print(b()) // prints "foo nil"

let b2 = a.foo2()
a = A(6)
print(b2()) // prints "foo2 4"

--
C. Keith Ray

* https://leanpub.com/wepntk <- buy my book?
* http://www.thirdfoundationsw.com/keith_ray_resume_2014_long.pdf
* http://agilesolutionspace.blogspot.com/

> On Oct 25, 2017, at 1:21 PM, David Hart via swift-evolution 
>  wrote:
> 
> class A { func foo() { func local() -> Int { [weak self] in } } }
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Kelvin Ma via swift-evolution]

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 can’t find the thread (if anybody could
> point me to it, I’d appreciate it). Basically, here’s an example of the
> leak:
>
> class A {
> func foo() {
> func local() {
> bar()
> }
>
> methodWithEscapingClosure { [unowned self] _ in
> self.bar()
> local() // this leaks because local captures self}
> }
>
> func bar() {
> }
> }
>
>
> Its sneaky because local’s capturing of self is not obvious if you’ve
> trained your brain to watch out for calls prefixed with self. I would
> suggest having the compiler force users to make self capturing explicit,
> the same way it does for closures:
>
> class A {
> func foo() {
> func local() {
> bar() // error: Call to method ‘bar' in function ‘local' requires 
> explicit 'self.' to make capture semantics explicit
> }
>   // ...
> }
> }
>
>
> What do you think?
>
> David.
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Alex Lynch via swift-evolution]

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:

> 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@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 can’t find the thread (if anybody could
> point me to it, I’d appreciate it). Basically, here’s an example of the
> leak:
>
> class A {
> func foo() {
> func local() {
> bar()
> }
>
> methodWithEscapingClosure { [unowned self] _ in
> self.bar()
> local() // this leaks because local captures self}
> }
>
> func bar() {
> }
> }
>
>
> Its sneaky because local’s capturing of self is not obvious if you’ve
> trained your brain to watch out for calls prefixed with self. I would
> suggest having the compiler force users to make self capturing explicit,
> the same way it does for closures:
>
>
> I think this is a good idea.  Ideally the proposal would also allow
> explicit capture lists in local functions.
>
>
> Ideally, yes. But the only sensible syntax I can come up for that seems
> odd in the context of functions:
>
> class A {
> func foo() {
> func local() -> Int { [weak self] in
> }
> }
> }
>
>
> Don’t you think?
>
>
> You could leave the "in" off, but it's only a little weird to have it, and
> the inconsistency would probably be worse.
>
> John.
>
>
> David.
>
> John.
>
>
> class A {
> func foo() {
> func local() {
> bar() // error: Call to method ‘bar' in function ‘local' requires 
> explicit 'self.' to make capture semantics explicit
> }
>   // ...
> }
> }
>
>
> What do you think?
>
> David.
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Kelvin Ma via swift-evolution]

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 swift-evolution <
swift-evolution@swift.org> wrote:

>
> > On 25 Oct 2017, at 15:29, Matthew Johnson via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> >
> >
> > Sent from my iPad
> >
> >> On Oct 24, 2017, at 5:55 PM, Slava Pestov via swift-evolution <
> swift-evolution@swift.org> 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 devote as much time to maintaining it going
> forward.
> >
> > I think the point is that some of the APIs should continue to be
> offered, but directly rather than via NSString.  We need an analysis of
> what APIs are affected that includes recommendations on which to deprecate
> and which to replace.  We can’t make an informed decision without that.
>
> This is also closely linked to the new String APIs which the String
> Manifesto touched upon but never got implemented. It’d be nice to know what
> plans the Standard Library team has in that regard for Swift 5.
>
> >>
> >> Slava
> >>
> >>> On Oct 24, 2017, at 3:54 PM, Philippe Hausler 
> wrote:
> >>>
> >>> I think any serious proposal with the removal of APIs would need to
> consider source compatibility and to do so you should likely audit the API
> surface area that is being offered (and replace it via the
> NSStringAPI.swift extension)
> >>>
>  On Oct 24, 2017, at 3:12 PM, Slava Pestov via swift-evolution <
> swift-evolution@swift.org> wrote:
> 
>  Perhaps you could write up a proposal to outline the missing
> functionality :-)
> 
>  Slava
> 
> > On Oct 24, 2017, at 3:09 PM, Jonathan Hull  wrote:
> >
> > I would feel better about it if String gained a lot of the utility
> of NSString (so that we don’t have to go to NSString all the time for
> methods)
> >
> > Thanks,
> > Jon
> >
> >> On Oct 24, 2017, at 3:00 PM, Slava Pestov via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>
> >> Hi,
> >>
> >> Members of NSString, except those defined in Foundation, are
> available on values of type String. For example,
> >>
> >> extension NSString {
> >> @objc func foo() {}
> >> }
> >>
> >> let s: String = “hello”
> >>
> >> s.foo()
> >>
> >> We don’t do this for any other bridged types, for instance NSArray
> methods are not imported as Array methods. It’s literally a special case in
> the type checker for member lookup on String.
> >>
> >> This behavior doesn’t really much sense conceptually and it was put
> in as a stop-gap in Swift 1 to beef up the String API. I would like to
> phase it out as follows:
> >>
> >> - Unconditional warning in Swift 4.1, with a fixit to insert an ‘as
> NSString’ cast
> >> - Error in Swift 5 with -swift-version 5
> >>
> >> What does everyone think about this?
> >>
> >> Slava
> >> ___
> >> swift-evolution mailing list
> >> swift-evolution@swift.org
> >> https://lists.swift.org/mailman/listinfo/swift-evolution
> >
> 
>  ___
>  swift-evolution mailing list
>  swift-evolution@swift.org
>  https://lists.swift.org/mailman/listinfo/swift-evolution
> >>>
> >>
> >> ___
> >> swift-evolution mailing list
> >> swift-evolution@swift.org
> >> https://lists.swift.org/mailman/listinfo/swift-evolution
> >
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Standard error?

[Kelvin Ma via swift-evolution]

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.
> 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
> represents standard error that could go there.
>
> Is there a TextOutputStream object for standard error? Or does that have
> to be added? I wonder if it should be a global or a type-level property
> somewhere?
>
> Sent from my iPad
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[John McCall via swift-evolution]

> 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 
>>> > 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 thread (if anybody could 
>>> point me to it, I’d appreciate it). Basically, here’s an example of the 
>>> leak:
>>> 
>>> class A {
>>> func foo() {
>>> func local() {
>>> bar()
>>> }
>>> 
>>> methodWithEscapingClosure { [unowned self] _ in
>>> self.bar()
>>> local() // this leaks because local captures self
>>> }
>>> }
>>> 
>>> func bar() {
>>> }
>>> }
>>> 
>>> Its sneaky because local’s capturing of self is not obvious if you’ve 
>>> trained your brain to watch out for calls prefixed with self. I would 
>>> suggest having the compiler force users to make self capturing explicit, 
>>> the same way it does for closures:
>> 
>> I think this is a good idea.  Ideally the proposal would also allow explicit 
>> capture lists in local functions.
> 
> Ideally, yes. But the only sensible syntax I can come up for that seems odd 
> in the context of functions:
> 
> class A {
> func foo() {
> func local() -> Int { [weak self] in
> }
> }
> }
> 
> Don’t you think?

You could leave the "in" off, but it's only a little weird to have it, and the 
inconsistency would probably be worse.

John.

> 
> David.
> 
>> John.
>> 
>>> 
>>> class A {
>>> func foo() {
>>> func local() {
>>> bar() // error: Call to method ‘bar' in function ‘local' 
>>> requires explicit 'self.' to make capture semantics explicit
>>> }
>>> 
>>> // ...
>>> }
>>> }
>>> 
>>> What do you think?
>>> 
>>> David.
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Standard error?

[Daryle Walker via swift-evolution]

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 represents standard 
error that could go there. 

Is there a TextOutputStream object for standard error? Or does that have to be 
added? I wonder if it should be a global or a type-level property somewhere?

Sent from my iPad
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Hart via swift-evolution]

> 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 behavior would be 
>> preserved until/if we remove -swift-version 4 mode. By deprecating it 
>> though, we won’t have to devote as much time to maintaining it going forward.
> 
> I think the point is that some of the APIs should continue to be offered, but 
> directly rather than via NSString.  We need an analysis of what APIs are 
> affected that includes recommendations on which to deprecate and which to 
> replace.  We can’t make an informed decision without that.

This is also closely linked to the new String APIs which the String Manifesto 
touched upon but never got implemented. It’d be nice to know what plans the 
Standard Library team has in that regard for Swift 5.

>> 
>> Slava
>> 
>>> On Oct 24, 2017, at 3:54 PM, Philippe Hausler  wrote:
>>> 
>>> I think any serious proposal with the removal of APIs would need to 
>>> consider source compatibility and to do so you should likely audit the API 
>>> surface area that is being offered (and replace it via the 
>>> NSStringAPI.swift extension)
>>> 
 On Oct 24, 2017, at 3:12 PM, Slava Pestov via swift-evolution 
  wrote:
 
 Perhaps you could write up a proposal to outline the missing functionality 
 :-)
 
 Slava
 
> On Oct 24, 2017, at 3:09 PM, Jonathan Hull  wrote:
> 
> I would feel better about it if String gained a lot of the utility of 
> NSString (so that we don’t have to go to NSString all the time for 
> methods)
> 
> Thanks,
> Jon
> 
>> On Oct 24, 2017, at 3:00 PM, Slava Pestov via swift-evolution 
>>  wrote:
>> 
>> Hi,
>> 
>> Members of NSString, except those defined in Foundation, are available 
>> on values of type String. For example,
>> 
>> extension NSString {
>> @objc func foo() {}
>> }
>> 
>> let s: String = “hello”
>> 
>> s.foo()
>> 
>> We don’t do this for any other bridged types, for instance NSArray 
>> methods are not imported as Array methods. It’s literally a special case 
>> in the type checker for member lookup on String.
>> 
>> This behavior doesn’t really much sense conceptually and it was put in 
>> as a stop-gap in Swift 1 to beef up the String API. I would like to 
>> phase it out as follows:
>> 
>> - Unconditional warning in Swift 4.1, with a fixit to insert an ‘as 
>> NSString’ cast
>> - Error in Swift 5 with -swift-version 5
>> 
>> What does everyone think about this?
>> 
>> Slava
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
 
 ___
 swift-evolution mailing list
 swift-evolution@swift.org
 https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Hart via swift-evolution]

> 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 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:
>> 
>> class A {
>> func foo() {
>> func local() {
>> bar()
>> }
>> 
>> methodWithEscapingClosure { [unowned self] _ in
>> self.bar()
>> local() // this leaks because local captures self
>> }
>> }
>> 
>> func bar() {
>> }
>> }
>> 
>> Its sneaky because local’s capturing of self is not obvious if you’ve 
>> trained your brain to watch out for calls prefixed with self. I would 
>> suggest having the compiler force users to make self capturing explicit, the 
>> same way it does for closures:
> 
> I think this is a good idea.  Ideally the proposal would also allow explicit 
> capture lists in local functions.

Ideally, yes. But the only sensible syntax I can come up for that seems odd in 
the context of functions:

class A {
func foo() {
func local() -> Int { [weak self] in
}
}
}

Don’t you think?

David.

> John.
> 
>> 
>> class A {
>> func foo() {
>> func local() {
>> bar() // error: Call to method ‘bar' in function ‘local' 
>> requires explicit 'self.' to make capture semantics explicit
>> }
>> 
>>  // ...
>> }
>> }
>> 
>> What do you think?
>> 
>> David.
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Howard Lovatt via swift-evolution]

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. I’m tired of fighting 
> with command-line mumbo jumbo just to setup and manage dependencies. SPM 
> should pave the way for high-level or junior devs to easily handle their 
> dependencies in the IDE of their choice.
> 
>> On 24 Oct 2017, at 13:46, Adrian Kashivskyy via swift-evolution 
>>  wrote:
>> 
>> I would like Xcode integration 
>> 
>> The last thing I want from a platform-agnostic open-source package manager 
>> is built-in integration with a single-platform commercial closed-source IDE. 
>> 
>> 
>> I think this should be done independently by DT team, without any special 
>> favouritism by SPM.
>> 
>> ——
>> Adrian Kashivskyy
>> 
>>> On 23 Oct 2017, 19:41 +0200, Jean-Christophe Pastant via swift-evolution 
>>> , wrote:
>>> Hi,
>>> 
>>> Is there any news about features that are willling to be integrated into 
>>> SPM 5?
>>> Those I see the most relevant:
>>> - iOS support
>>> - Some kind of configuration/settings support (debug, release, ...)
>>> 
>>> I'd like to hear about it from maintainers, especially if there's a 
>>> priority order we should follow.
>>> 
>>> Regards,
>>> 
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> David James
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Tony Allevato via swift-evolution]

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 code (one with a closure, one with a nested function) and can
only address the capturing semantics in one of them. Unifying these seems
like a good idea.

On Wed, Oct 25, 2017 at 10:12 AM David Sweeris via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Oct 25, 2017, at 4: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 can’t find the thread (if anybody could
> point me to it, I’d appreciate it). Basically, here’s an example of the
> leak:
>
> class A {
> func foo() {
> func local() {
> bar()
> }
>
> methodWithEscapingClosure { [unowned self] _ in
> self.bar()
> local() // this leaks because local captures self}
> }
>
> func bar() {
> }
> }
>
>
> Its sneaky because local’s capturing of self is not obvious if you’ve
> trained your brain to watch out for calls prefixed with self. I would
> suggest having the compiler force users to make self capturing explicit,
> the same way it does for closures:
>
> class A {
> func foo() {
> func local() {
> bar() // error: Call to method ‘bar' in function ‘local' requires 
> explicit 'self.' to make capture semantics explicit
> }
>   // ...
> }
> }
>
>
> What do you think?
>
>
> Works for me
>
> - Dave Sweeris
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Max Moiseev via swift-evolution]

> 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 address. Not the impurity of the 
>> function, not the performance, but the potential to misuse.
> But do you think filterMap can’t be misused? I don’t know why people choose 
> flatMap instead of map, but they might as well just switch to filterMap.
Oh I’m sure they will. But I hope it will be harder, because we will have a 
deprecated overload of a flatMap that will provide a helpful message and guide 
people to use map instead.
> 
>>> Maybe Scala chose better name for the concept, but the Swift definition is 
>>> consistent as it is now.
>> collect does not say anything about the transformation (A => B) that happens 
>> along the way…
> „collectResults“ is probably clearer… but I guess Scala-folks choose to 
> prefer a single word.
Let’s not forget about the types. Function type is an essential piece of 
information that should accompany it’s name. With a function type being 
(LIst[A], PartialFunction[A, B]) => List[B] the name is almost not needed, 
there is pretty much one way of implementing this function (if we forget about 
trivial and wrong implementations that, for example, return an empty list all 
the time, of perform arbitrary side-effects).

> But when it’s about clear naming, we probably should talk about 
> „applyFunctionAndCollectUnwrappedResults“, because filtering has no obvious 
> connection to nil-values.
> Even worse, I think filter is the wrong word in this context, because that’s 
> what I’d expect from such a function:
> Sequence.filterMap(_: (Element) -> U?) -> [U?]
> 
> In this case, the result would only contain those Optionals that contain a 
> value — or there could be a parameter for the filter, defaulted to a check 
> for nil.
> 
>>> So, if you remove the third overload, the second one imho should be 
>>> renamed, too.
>> Honestly, I don’t see why. Can you elaborate? The second one is perfectly 
>> consistent, it does not mix two different functor instances in the same 
>> function.
> As it is now, both Sequence and Optional are very similar — they are 
> container types that may be empty.
> When you say that one incarnation of flatMap that deals with Optionals is 
> wrong, imho it’s cleaner to break that connection completely, and make it a 
> Collection-only thing.
> Overload 2 is kind of a special case of the third one.
I was actually thinking in the opposite direction ;-) As in, adding more 
functions from Collection to Optional. filter can be useful, count, isEmpty, 
forEach… I’m not saying that it will conform to the Collection protocol, but I 
can see how sometimes `opt.filter { $0 > 0 }` is a better option than `if let v 
= opt, x > 0 { … } else { … }

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Sweeris via swift-evolution]

> 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 the thread (if anybody could point me 
> to it, I’d appreciate it). Basically, here’s an example of the leak:
> 
> class A {
> func foo() {
> func local() {
> bar()
> }
> 
> methodWithEscapingClosure { [unowned self] _ in
> self.bar()
> local() // this leaks because local captures self
> }
> }
> 
> func bar() {
> }
> }
> 
> Its sneaky because local’s capturing of self is not obvious if you’ve trained 
> your brain to watch out for calls prefixed with self. I would suggest having 
> the compiler force users to make self capturing explicit, the same way it 
> does for closures:
> 
> class A {
> func foo() {
> func local() {
> bar() // error: Call to method ‘bar' in function ‘local' requires 
> explicit 'self.' to make capture semantics explicit
> }
> 
>   // ...
> }
> }
> 
> What do you think?

Works for me

- Dave Sweeris

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[John McCall via swift-evolution]

> 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 thread (if anybody could point me 
> to it, I’d appreciate it). Basically, here’s an example of the leak:
> 
> class A {
> func foo() {
> func local() {
> bar()
> }
> 
> methodWithEscapingClosure { [unowned self] _ in
> self.bar()
> local() // this leaks because local captures self
> }
> }
> 
> func bar() {
> }
> }
> 
> Its sneaky because local’s capturing of self is not obvious if you’ve trained 
> your brain to watch out for calls prefixed with self. I would suggest having 
> the compiler force users to make self capturing explicit, the same way it 
> does for closures:

I think this is a good idea.  Ideally the proposal would also allow explicit 
capture lists in local functions.

John.

> 
> class A {
> func foo() {
> func local() {
> bar() // error: Call to method ‘bar' in function ‘local' requires 
> explicit 'self.' to make capture semantics explicit
> }
> 
>   // ...
> }
> }
> 
> What do you think?
> 
> David.
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Charles Srstka via swift-evolution]

> 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 change 
> wouldn’t go through Swift-Evolution.
> 
> So in theory, if Swift 5 decides to get rid of the AnyObject dispatch, the 
> Cocoa teams at Apple could work around that by introducing “@objc protocol 
> IntegerTagged”, and introducing a migrator pass to look for '(sender as 
> AnyObject).tag’ and rewrite it as `(sender as! IntegerTagged)?.tag.

The Swift team and the Cocoa team communicate with each other, though? I ask 
because there have been some changes to the Cocoa frameworks in the past (see 
below) that were clearly made in the interest of improving Swift interop, and 
also because the Swift bug tracker has a field for Radar report IDs.

FWIW, I filed a Radar last year on this (rdar://29623107 )

> If the ‘tag’ property is the only reason to keep AnyObject dispatch, I don’t 
> think it’s worth its weight in the language.

Potentially there could be more; what would need to be done would be to dig 
through the documentation and find all the methods that returned untyped proxy 
objects. NSTreeNode’s arrangedObjects *was* one of these until very recently; 
prior to 10.13, it returned an ‘id’ which responded to a couple of methods 
described in the documentation. They finally changed it in High Sierra to 
return an NSTreeNode, because using it had been very obnoxious in Swift. My 
intuition is that there may be more APIs like this in the frameworks that 
return proxy objects like this, although I can’t remember any specifically off 
the top of my head right now. Any such methods would need to be fixed, though, 
because without the AnyObject behavior, these objects would become completely 
unusable—even the “extension on NSObject” trick isn’t guaranteed to work, since 
objects typed ‘id’ are not guaranteed to be derived from NSObject (they could, 
for instance, be NSProxy).

Charles

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[BJ Homer via swift-evolution]

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 decides to get rid of the AnyObject dispatch, the 
Cocoa teams at Apple could work around that by introducing “@objc protocol 
IntegerTagged”, and introducing a migrator pass to look for '(sender as 
AnyObject).tag’ and rewrite it as `(sender as! IntegerTagged)?.tag.

If the ‘tag’ property is the only reason to keep AnyObject dispatch, I don’t 
think it’s worth its weight in the language.

-BJ

> On Oct 25, 2017, at 8:28 AM, Charles Srstka via swift-evolution 
>  wrote:
> 
> 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 make 
>> NSObject conform to it.
>> 
>> Slava
>> 
>>> On Oct 24, 2017, at 4:05 PM, Charles Srstka >> > wrote:
>>> 
 On Oct 24, 2017, at 5:02 PM, Slava Pestov via swift-evolution 
 > wrote:
 
 Thoughts? Does anyone actually rely on this feature, instead of just 
 stumbling on it by accident once in a while?
>>> 
>>> The main thing I can think of off the top of my head is getting the tag 
>>> from the sender in an IBAction:
>>> 
>>> @IBAction private func someAction(_ sender: Any?) {
>>> guard let tag = (sender as AnyObject?)?.tag as Int? else { return }
>>> 
>>> ...
>>> }
>>> 
>>> Unfortunately given how many unrelated Cocoa objects there are that 
>>> implement -tag, it’s not really practical to implement this without the 
>>> AnyObject dispatch. If a TagContaining protocol could be introduced and all 
>>> the objects that implement -tag could be made to conform to it, then that 
>>> would work around the problem (I believe I pitched this at some point long 
>>> ago, but without catching any interest).
>>> 
>>> Charles
>>> 
>> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Charles Srstka via swift-evolution]

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 make 
> NSObject conform to it.
> 
> Slava
> 
>> On Oct 24, 2017, at 4:05 PM, Charles Srstka > > wrote:
>> 
>>> On Oct 24, 2017, at 5:02 PM, Slava Pestov via swift-evolution 
>>> > wrote:
>>> 
>>> Thoughts? Does anyone actually rely on this feature, instead of just 
>>> stumbling on it by accident once in a while?
>> 
>> The main thing I can think of off the top of my head is getting the tag from 
>> the sender in an IBAction:
>> 
>> @IBAction private func someAction(_ sender: Any?) {
>> guard let tag = (sender as AnyObject?)?.tag as Int? else { return }
>> 
>> ...
>> }
>> 
>> Unfortunately given how many unrelated Cocoa objects there are that 
>> implement -tag, it’s not really practical to implement this without the 
>> AnyObject dispatch. If a TagContaining protocol could be introduced and all 
>> the objects that implement -tag could be made to conform to it, then that 
>> would work around the problem (I believe I pitched this at some point long 
>> ago, but without catching any interest).
>> 
>> Charles
>> 
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Matthew Johnson via swift-evolution]

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 devote as much time to maintaining it going forward.

I think the point is that some of the APIs should continue to be offered, but 
directly rather than via NSString.  We need an analysis of what APIs are 
affected that includes recommendations on which to deprecate and which to 
replace.  We can’t make an informed decision without that.

> 
> Slava
> 
>> On Oct 24, 2017, at 3:54 PM, Philippe Hausler  wrote:
>> 
>> I think any serious proposal with the removal of APIs would need to consider 
>> source compatibility and to do so you should likely audit the API surface 
>> area that is being offered (and replace it via the NSStringAPI.swift 
>> extension)
>> 
>>> On Oct 24, 2017, at 3:12 PM, Slava Pestov via swift-evolution 
>>>  wrote:
>>> 
>>> Perhaps you could write up a proposal to outline the missing functionality 
>>> :-)
>>> 
>>> Slava
>>> 
 On Oct 24, 2017, at 3:09 PM, Jonathan Hull  wrote:
 
 I would feel better about it if String gained a lot of the utility of 
 NSString (so that we don’t have to go to NSString all the time for methods)
 
 Thanks,
 Jon
 
> On Oct 24, 2017, at 3:00 PM, Slava Pestov via swift-evolution 
>  wrote:
> 
> Hi,
> 
> Members of NSString, except those defined in Foundation, are available on 
> values of type String. For example,
> 
> extension NSString {
> @objc func foo() {}
> }
> 
> let s: String = “hello”
> 
> s.foo()
> 
> We don’t do this for any other bridged types, for instance NSArray 
> methods are not imported as Array methods. It’s literally a special case 
> in the type checker for member lookup on String.
> 
> This behavior doesn’t really much sense conceptually and it was put in as 
> a stop-gap in Swift 1 to beef up the String API. I would like to phase it 
> out as follows:
> 
> - Unconditional warning in Swift 4.1, with a fixit to insert an ‘as 
> NSString’ cast
> - Error in Swift 5 with -swift-version 5
> 
> What does everyone think about this?
> 
> Slava
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
 
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Hart via swift-evolution]

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:

class A {
func foo() {
func local() {
bar()
}

methodWithEscapingClosure { [unowned self] _ in
self.bar()
local() // this leaks because local captures self
}
}

func bar() {
}
}

Its sneaky because local’s capturing of self is not obvious if you’ve trained 
your brain to watch out for calls prefixed with self. I would suggest having 
the compiler force users to make self capturing explicit, the same way it does 
for closures:

class A {
func foo() {
func local() {
bar() // error: Call to method ‘bar' in function ‘local' requires 
explicit 'self.' to make capture semantics explicit
}

// ...
}
}

What do you think?

David.

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Tino via swift-evolution]

>> 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, but the potential to misuse.
But do you think filterMap can’t be misused? I don’t know why people choose 
flatMap instead of map, but they might as well just switch to filterMap.

>> Maybe Scala chose better name for the concept, but the Swift definition is 
>> consistent as it is now.
> collect does not say anything about the transformation (A => B) that happens 
> along the way…
„collectResults“ is probably clearer… but I guess Scala-folks choose to prefer 
a single word.
But when it’s about clear naming, we probably should talk about 
„applyFunctionAndCollectUnwrappedResults“, because filtering has no obvious 
connection to nil-values.
Even worse, I think filter is the wrong word in this context, because that’s 
what I’d expect from such a function:
Sequence.filterMap(_: (Element) -> U?) -> [U?]

In this case, the result would only contain those Optionals that contain a 
value — or there could be a parameter for the filter, defaulted to a check for 
nil.

>> So, if you remove the third overload, the second one imho should be renamed, 
>> too.
> Honestly, I don’t see why. Can you elaborate? The second one is perfectly 
> consistent, it does not mix two different functor instances in the same 
> function.
As it is now, both Sequence and Optional are very similar — they are container 
types that may be empty.
When you say that one incarnation of flatMap that deals with Optionals is 
wrong, imho it’s cleaner to break that connection completely, and make it a 
Collection-only thing.
Overload 2 is kind of a special case of the third one.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Johannes Weiß via swift-evolution]

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 AnyObject is a source of implementation 
> complexity, has many known bugs which we are not going to fix, and no longer 
> makes sense now in an id-as-Any world; AnyObject is not the ‘common currency’ 
> type for arbitrary Objective-C objects anymore.
> 
> I would like to propose we deprecate it as follows:
> 
> - Unconditional warning in Swift 4.1, with a fixit to add an ‘as’ cast to 
> cast the base value to the right type
> - Error in Swift 5 in -swift-version 5 mode
> 
> Thoughts? Does anyone actually rely on this feature, instead of just 
> stumbling on it by accident once in a while?
> 
> Slava
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Johannes Weiß via swift-evolution]

+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 available on 
> values of type String. For example,
> 
> extension NSString {
>  @objc func foo() {}
> }
> 
> let s: String = “hello”
> 
> s.foo()
> 
> We don’t do this for any other bridged types, for instance NSArray methods 
> are not imported as Array methods. It’s literally a special case in the type 
> checker for member lookup on String.
> 
> This behavior doesn’t really much sense conceptually and it was put in as a 
> stop-gap in Swift 1 to beef up the String API. I would like to phase it out 
> as follows:
> 
> - Unconditional warning in Swift 4.1, with a fixit to insert an ‘as NSString’ 
> cast
> - Error in Swift 5 with -swift-version 5
> 
> What does everyone think about this?
> 
> Slava
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Opaque Pointers in Swift

[Cory Benfield via swift-evolution]

> 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 problem:
> 
> - when you receive a pointer from the C library, store it as OpaquePointer
>let myOpaquePointer: OpaquePointer = 
> OpaquePointer(c_library_create_function())
>  which now should work regardless of whether you're linking the old or the 
> new version of the C library
> - when you pass a pointer to the C library:
>c_library_consuming_function(.init(myOpaquePointer))
>  which should (modulo it doesn't right now 
> https://bugs.swift.org/browse/SR-6211) select the right initialiser for you, 
> only it doesn’t 

Yeah, this approach is probably acceptable. I’m going to stop short of calling 
it “good”, because frankly it remains a pretty unfortunate hack. It would be 
nicer if there was a way to tell the Swift compiler that the user should never 
initialise the structure, regardless of whether it’s opaque (that is, to tell 
the Swift compiler that when it sees SSL_CTX * it should translate that to 
OpaquePointer instead of UnsafePointer), but I will concede 
that adding support for that case is likely to be a bit too niche for the 
community to have much interest.

In the absence of that better version, your proposed interface will get the job 
done without being too gross. Thanks!

Cory

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ben Rimmington via swift-evolution]

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 up a slightly messy idiomatic use of 
> conditional compilation in libraries. The effects should be quite limited; 
> I'd call it a "standard library" addition except that the repertoire of 
> compiler-control statements isn't strictly part of the stdlib.
> 
> Proposal is here: 
> https://gist.github.com/graydon/809af2c726cb1a27af64435e47ef4e5d
> 
> Implementation (minus fixits) is here: 
> https://github.com/graydon/swift/commit/16493703ea297a1992ccd0fc4d2bcac7d078c982
> 
> Feedback appreciated,
> 
> -Graydon
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Graydon Hoare via swift-evolution]

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 list of accepted identifiers for the os() 
condition (proposal updated to reflect this):

https://github.com/apple/swift/blob/master/lib/Basic/LangOptions.cpp#L28 


-Graydon

> On Oct 24, 2017, at 8:49 PM, David Sweeris  wrote:
> 
> One quick question... WRT `os()`, should that take a string instead of some 
> keywordish thing? There's at least one OS which has a Swift port, but doesn't 
> show up on that list (Haiku: 
> https://www.haiku-os.org/blog/return0e/2017-08-28_gsoc_2017_porting_swift_to_haiku_-_final_report/
>  
> )
> 
> - Dave Sweeris
> 
>> On Oct 24, 2017, at 8:05 PM, Graydon Hoare via swift-evolution 
>> > wrote:
>> 
>> Hi,
>> 
>> I'd like to propose a variant of a very minor, additive proposal Erica Sadun 
>> posted last year, that cleans up a slightly messy idiomatic use of 
>> conditional compilation in libraries. The effects should be quite limited; 
>> I'd call it a "standard library" addition except that the repertoire of 
>> compiler-control statements isn't strictly part of the stdlib.
>> 
>> Proposal is here: 
>> https://gist.github.com/graydon/809af2c726cb1a27af64435e47ef4e5d 
>> 
>> 
>> Implementation (minus fixits) is here: 
>> https://github.com/graydon/swift/commit/16493703ea297a1992ccd0fc4d2bcac7d078c982
>>  
>> 
>> 
>> Feedback appreciated,
>> 
>> -Graydon
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution