Re: [swift-users] @escaping may only be applied to parameters of function type

[Michael Ilseman via swift-users]

> On Sep 13, 2016, at 8:16 PM, Michael Ilseman via swift-users 
>  wrote:
> 
> 
>> On Sep 13, 2016, at 8:14 PM, Rick Mann  wrote:
>> 
>> But the Apple declaration (accessible via Xcode) of the method it's based on 
>> looks like this:
>> 
>> open func enumerator(at url: URL,
>>   includingPropertiesForKeys keys: [URLResourceKey]?,
>>   options mask: FileManager.DirectoryEnumerationOptions = [],
>>   errorHandler handler: (@escaping (URL, Error) -> Bool)? = nil)
>>   -> FileManager.DirectoryEnumerator?
>> 
>> handler is optional, but has @escaping. Is this an artifact of how Xcode 
>> presents system header files?
>> 
> 
> That’s certainly funky. Might be that or a bug in the AST printer.
> 

Definitely a bug in the AST printer

>> 
>>> On Sep 13, 2016, at 20:11 , Michael Ilseman  wrote:
>>> 
>>> TL;DR: The optional is already escaping, due to the fact that “T?" is sugar 
>>> for Optional, and the noescape-by-default rule only applies to types in 
>>> immediate parameter position. Current Swift master has much better 
>>> diagnostics for this case.
>>> 
>>> There is not currently a general solution involving escapability of closure 
>>> types used a generic parameters or tuple members, though such a thing would 
>>> be useful in Swift 4.
>>> 
 On Sep 13, 2016, at 7:42 PM, Shawn Erickson via swift-users 
  wrote:
 
 The following is the earlier thread I was talking about. 
 
 [swift-users] Swift 3 (Xcode 8 GM) issue with @escaping 
 
 -Shawn
 
 On Tue, Sep 13, 2016 at 7:31 PM Shawn Erickson  wrote:
 I hit this issue as well. I had an early email on this list regarding do 
 this topic, not in a situation to search for it. It is a short coming in 
 how escaping can be applied to things like optional closures.
 
 I was in the process of authoring an email for swift evolution about it 
 and haven't yet gotten around to filing a defect about it.
 
 -Shawn
 On Tue, Sep 13, 2016 at 7:27 PM Rick Mann via swift-users 
  wrote:
 I'm trying to write this function. The errorHandler: parameter is modeled 
 after the NSFileManager enumerate() function. If I include the @escaping 
 you see there, I get the error "@escaping may only be applied to 
 parameters of function type".
 
 The second parameter, iterator:, seems to have no problems with @escaping.
 
 func
 iterate(directory inURL: URL?,
   includingPropertiesForKeys: [URLResourceKey]? = nil,
   options: FileManager.DirectoryEnumerationOptions = [],
   errorHandler inErrorHandler: (@escaping (URL, Error) -> Bool)? = nil,
   iterator inIterator: (@escaping (URL) throws -> ())) rethrows
 {
 }
 
 I'm not sure why I can't apply @escaping here. Can anyone enlighten me? 
 Thank you.
 
 --
 Rick Mann
 rm...@latencyzero.com
 
 
 ___
 swift-users mailing list
 swift-users@swift.org
 https://lists.swift.org/mailman/listinfo/swift-users
 ___
 swift-users mailing list
 swift-users@swift.org
 https://lists.swift.org/mailman/listinfo/swift-users
>>> 
>> 
>> 
>> -- 
>> Rick Mann
>> rm...@latencyzero.com
>> 
>> 
> 
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

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

Re: [swift-users] @escaping may only be applied to parameters of function type

[Michael Ilseman via swift-users]

> On Sep 13, 2016, at 8:37 PM, Shawn Erickson  wrote:
> 
> I am in the process of updating to Xcode 8 release so I can't confirm at the 
> moment but I am fairly sure I hit a situation with being asked to implement a 
> func from a protocol that got autocompleted with @escape nested as shown. It 
> would then of course complain that wasn't valid. If I fixed it I don't think 
> it was considered being implemented (it could only be an issue as noted in my 
> prior thread related to default implementation not being picked up).
> 
> I will start a discussion about @escaping on the evolution list (hopefully 
> soon). The main issue I see – beyond quirks like this – is that the proposal 
> stated that closures would become noescape by default.

Link for those following along at home: 
https://github.com/apple/swift-evolution/blob/master/proposals/0103-make-noescape-default.md

Practically every occurrence of the word “closure” is immediately proceeded by 
“argument” or “argument to function”. Thus, it does not apply to stored members 
of structs, enum payloads, etc. I don’t like this either, but that is the 
current situation. Additionally, withoutActuallyEscaping is not implemented yet 
either, though I am looking into that.

This gets muddy and non-intuitive very quickly, especially with syntactic sugar 
and the overall prevalence of optionals (especially when importing from ObjC!). 
In a pure Swift world, the most effective workaround (though I haven’t tested 
this myself) if one wants non-escaping optional closure arguments, is to use 
function overloading for the interface, but that’s not particularly fun 
(although withoutActuallyEscaping could help a tiny bit). In a mixed world, 
there is outright breakage around the seams, and I’m investigating what all the 
issues there are (I suspect many are compiler bugs, rather than language bugs).

I would be in favor (and can help you champion) an escaping rule that 
propagates through generic parameters and non-nominal-type members. 

> I had existing code that applied @noescape against optional closures as well 
> as tuples with closures, etc. which was happy and appeared to honor 
> @noescape. I had expected closures in all "constructs" to be considered 
> noescape after this change (what I got from reading the proposal) however in 
> some situations they are considered escaping now when in fact in the past 
> @noescape was able to be applied to state otherwise. It is possible that 
> @noescape wasn't actually doing anything in those cases but it seemed like it 
> was working to me.
> 
> So now I have code that I can't make work since it was meant to be noescape 
> yet it is now considered escaping implicitly. If I try to fix this code I get 
> complaints about things expected to escape and/or things needed to not escape 
> (hard to explain with examples). I can likely rework the code to get it 
> working again but expect to lose some of the desired implementation.
> 
> -Shawn
> 
> On Tue, Sep 13, 2016 at 8:16 PM Michael Ilseman  > wrote:
> 
> > On Sep 13, 2016, at 8:14 PM, Rick Mann  > > wrote:
> >
> > But the Apple declaration (accessible via Xcode) of the method it's based 
> > on looks like this:
> >
> > open func enumerator(at url: URL,
> >includingPropertiesForKeys keys: [URLResourceKey]?,
> >options mask: FileManager.DirectoryEnumerationOptions = [],
> >errorHandler handler: (@escaping (URL, Error) -> Bool)? = nil)
> >-> FileManager.DirectoryEnumerator?
> >
> > handler is optional, but has @escaping. Is this an artifact of how Xcode 
> > presents system header files?
> >
> 
> That’s certainly funky. Might be that or a bug in the AST printer.
> 
> >
> >> On Sep 13, 2016, at 20:11 , Michael Ilseman  >> > wrote:
> >>
> >> TL;DR: The optional is already escaping, due to the fact that “T?" is 
> >> sugar for Optional, and the noescape-by-default rule only applies to 
> >> types in immediate parameter position. Current Swift master has much 
> >> better diagnostics for this case.
> >>
> >> There is not currently a general solution involving escapability of 
> >> closure types used a generic parameters or tuple members, though such a 
> >> thing would be useful in Swift 4.
> >>
> >>> On Sep 13, 2016, at 7:42 PM, Shawn Erickson via swift-users 
> >>> > wrote:
> >>>
> >>> The following is the earlier thread I was talking about.
> >>>
> >>> [swift-users] Swift 3 (Xcode 8 GM) issue with @escaping
> >>>
> >>> -Shawn
> >>>
> >>> On Tue, Sep 13, 2016 at 7:31 PM Shawn Erickson  >>> > wrote:
> >>> I hit this issue as well. I had an early email on this list regarding do 
> >>> this topic, not in a situation to search for it. It is a short coming in 
> >>> how escaping can be applied 

Re: [swift-users] Swift and Xcode along with Playgrounds is full of bugs

[Jens Alfke via swift-users]

> On Sep 14, 2016, at 7:50 AM, Patrice Kouame via swift-users 
>  wrote:
> 
> 1. File those bugs and issues in radar, but lower your expectations a bit.  
> That’s how I usually vent my frustrations.  Just imagine the thousands they 
> have to sift through...
> 2. Be constructive: if possible provide some workarounds, even sloppy ones - 
> don’t be shy and engage discussion
> 3. Have a thick skin: welcome some constructive criticism

I can also add: challenge yourself to diagnose the problem. Even if you don’t 
know the innards of the compiler or runtime. I’m a technology owner and help 
support developers using it, and I find that many times people report bugs or 
ask for help without having done all they could to analyze the problem. 
Sometimes this is a dead end, but often you can uncover more information that 
can greatly help the engineers fix the bug, and sometimes you can find 
workarounds that get you unblocked.

Some advice based on stuff I see in my project’s forums:

— Read error messages carefully. Sometimes people report that “it won’t 
compile” or “it crashed” and append a dump of the log, without noticing that 
the log includes a message that pretty clearly identifies what they did wrong.
— Look for clues in crash logs / backtraces. Even if you don’t know how the 
software is implemented or have the source code, just looking at the function 
names in a backtrace or crash can give you clues about what it’s doing, which 
might help you find workarounds.
— Try to boil a problem down to a simpler case. Ideally something you can do in 
a playground.
— Learn common crash/error patterns. I can’t think of any Swift-specific ones 
at the moment, but a super common Objective-C one is the crash in 
`objc_msgsend`, which an experienced developer knows the program must have 
messaged either a deallocated object, or a bogus object reference.
— Treat debugging as a science. Act like a scientist. Examine the evidence, 
form hypotheses, invent experiments to test the hypotheses. “If this variable 
is being clobbered, maybe it’s because this method is called re-entrantly? I 
can add a flag to it to test for a re-entrant call…”

—Jens___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Swift and Xcode along with Playgrounds is full of bugs

[Gerard Iglesias via swift-users]

The Art of Diplomacy…

Keep doing the great work, lot of us have to much work in our job and/or not 
the skills (my case) to help you in this so interesting journey.

Thanx

Gerard

> On 14 Sep 2016, at 05:56, Chris Lattner via swift-users 
> > wrote:
> 
> On Sep 13, 2016, at 5:34 PM, Shyamal Chandra  > wrote:
>> Hi Chris,
>> 
>> Here is a forum question that I posted a while back.  The latest post says 
>> to file a bug under the bug report.  
>> 
>> Here's the post:
>> 
>> https://forums.developer.apple.com/thread/61953 
>>  (Playgrounds error)
> 
> Thanks for the link.  Contrary to your claims, it appears that you promptly 
> got a response from an Apple employee, and it appears that you didn’t follow 
> his instructions to file a radar in bugreporter.apple.com 
> .
> 
> Now that Xcode 8 has shipped to the Mac App Store today, I’d suggest you 
> download that and try it.  There are a number of bugs that are fixed between 
> beta 6 and the final release, and that may include this one.
> 
>> I was doing something "simple" in Playgrounds and my version of Playgrounds 
>> doesn't function properly because it is emitting an error when I write 
>> bug-free code.  Why is Playgrounds so flaky?  Sometimes, it shows the output 
>> on the right side; sometime, it doesn’t.
> 
> Two simple and obvious answers come to mind: you are running 
> advertised-as-beta software, and even shipping software does have bugs.
> 
>> I have had mixed success with the bug reporter tool from Apple; most of the 
>> time, they ask for the system diagnostics and then, tell you to update your 
>> version.  Sometimes, they just close the issue and nothing happens.
> 
> 
> I understand that you claim to have had problems with 
> Radar/bugreporter.apple.com , but again I can 
> see no evidence of you ever filing a bug in it (and you haven’t provided me 
> any radar numbers to cross reference), so there isn’t much I can do to help 
> you.  Needless to say, we do actually need the system diagnostics in order to 
> reproduce issues like this, as you found on the forum, your issue doesn’t 
> reproduce trivially for other folks.
> 
> 
> Finally, as others have pointed out, your approach on this thread hasn’t been 
> particularly constructive.  Despite your apparent expectation, Apple has not 
> signed up to fix any and every bug reported against Swift.  That said, we all 
> want to build a strong community, and if you are interested in working in a 
> helpful and productive way we would love for you to be part of that 
> community.  On the other hand, if you find that Swift on Linux isn’t ready 
> for you today and that you don’t want to invest effort in it, then perhaps it 
> is best for you to come back at some point later in the future.
> 
> Thanks,
> 
> -Chris
> 
>> 
>> 
>> Thanks!
>> 
>> Best,
>> 
>> Shyamal Chandra
>> shyam...@gmail.com 
>> Linkedin: http://www.linkedin.com/in/shyamalc 
>> 
>> Phone: 620-719-9064
>> 
>> On Tue, Sep 13, 2016 at 7:02 PM, Chris Lattner > > wrote:
>> On Sep 12, 2016, at 3:03 PM, Shyamal Chandra via swift-users 
>> > wrote:
>> > Hope you are doing well!
>> >
>> > Swift is very volatile language that keeps on changing with every new 
>> > version of Xcode.  When you are trying to run old code with different 
>> > syntax, you run into problems because the code is no longer compatible.  
>> > Instead of moving onto Swift 3, 4, and 5 (with different syntax), why 
>> > don't you standardize the library and language operations and functions 
>> > for the different package and frameworks included with Xcode
>> 
>> The subject line of this message seems like it is intended to be 
>> provocative, not helpful.
>> 
>> Despite that, you’ll be happy to know that the goal of Swift 4 is to be 
>> source compatible with Swift 3, so the concerns that you are complaining 
>> about are historic, not future problems.
>> 
>> > because I have already submitted multiple bugs to the bug report that are 
>> > with the official release of Xcode and I am very disappointed with the 
>> > software quality.
>> 
>> I don’t see any radars filed by you in the system, but perhaps they are just 
>> under a different name.  In any case, thank you for filing bugs, we do read 
>> and care about them!  Please send me the radar numbers (off list if you 
>> prefer) and I’ll take a look.
>> 
>> -Chris
>> 
>> 
> 
> ___
> swift-users mailing list
> swift-users@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-users 
>