> 1. The compiler crash should never happen, obviously, so that's a bug report.
To be more clear - it doesn't matter how screwed up your source could possibly be, the compiler must never crash. If it does, then it's a bug in the compiler. It's quite likely that a slightly more subtle problem in your source would result in incorrect machine code generation. I've actually seen that happen. In my case I knew I was getting bad machine code; increasing the number of characters in certain symbol names lead to the MPW C compiler setting my Mac up the bomb. Michael David Crawford, Consulting Software Engineer mdcrawf...@gmail.com http://www.warplife.com/mdc/ Available for Software Development in the Portland, Oregon Metropolitan Area. On Wed, Apr 29, 2015 at 10:22 AM, Quincey Morris <quinceymor...@rivergatesoftware.com> wrote: > On Apr 29, 2015, at 02:08 , Charles Jenkins <cejw...@gmail.com> wrote: >> >> override func saveToURL( >> url:NSURL, >> ofType typeName:String, >> forSaveOperation saveOperation: >> NSSaveOperationType, >> completionHandler:(NSError!) -> Void >> ) { >> // <snip> Here I prepare my data structures for saving >> >> //super.saveToURL( url, ofType:typeName, forSaveOperation:saveOperation, >> completionHandler:completionHandler ) >> >> super.saveToURL( >> url, >> ofType:typeName, >> forSaveOperation:saveOperation, >> completionHandler:{ >> ( error:NSError! ) -> Void in { >> completionHandler( error ) >> // TODO: If no error, mark data structures as "clean" >> } >> } >> ) >> } > > 1. The compiler crash should never happen, obviously, so that's a bug report. > > 2. The bridged protocol method is apparently wrong. Since the error parameter > is explicitly documented as being nil on success, it should be NSError?. > (Note that it's possible at runtime for an implicitly unwrapped optional (!) > to be nil, and you can test for it being nil, but we saw in your previous > adventure that an app will crash if the Swift runtime tries to enter a Swift > method with a nil value for an implicitly unwrapped optional, at least when > coming from the Obj-C runtime). > > 3. The bridged method signature isn't syntactically correct, though it isn't > exactly wrong either. There's no need for parentheses in '(NSError!)'. A > 1-tuple is by definition the same thing as the element in the tuple, but I > wouldn't be surprised if the compiler doesn't handle this in all cases. > > 4. Similarly, the parentheses in your super invocation aren't necessary, nor > is the default return type (... '( error:NSError! ) -> Void in' ...). > > 5. It's not necessary to open an new brace after 'in', though this shouldn't > be wrong either. > > So, that's a lot of slightly unusual stuff, and the crash could be caused by > any one of them. In Xcode 6.3.1, the following compiles for me without > errors, warnings or a compiler crash: > > override func saveToURL(url: NSURL, ofType typeName: String, > forSaveOperation saveOperation: NSSaveOperationType, completionHandler: > NSError? -> Void) { > super.saveToURL(url, ofType: typeName, forSaveOperation: > saveOperation) {error in /*...*/ return} > } > > See if that works for you. (But don't forget your bug report!) > > > > _______________________________________________ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/cocoa-dev/mdcrawford%40gmail.com > > This email sent to mdcrawf...@gmail.com _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
