Re: [swift-evolution] Cancelable named defer statements
Its probably better to use a Boolean variable close_file to "cancel" it, rather than change the entire language. func openFile(kind: String) -> UnsafeMutablePointer? { var file = fopen("MyFile.txt", "r") var close_file = true defer { if close_file { fclose(file) }} // <-- if fileIsNotValid(file) { return nil } if fileDoesNotContainsData(file, kind) { return nil } if fileDataOutOfDate(file) { return nil } // Prevent the deferred handler from closing the file close_file = false // <-- return file } On Sat, Jan 7, 2017 at 1:20 PM Rien via swift-evolution < swift-evolution@swift.org> wrote: > Is there any interest in a proposal to introduce a named defer statement > that can be cancelled? > > Lately I find myself writing this kind of code: > > func openFile(kind: String) -> UnsafeMutablePointer? { > > > var file = fopen("MyFile.txt", "r") > > > var closeFile = true > > defer { if closeFile { fclose(file) } } > > > if fileIsNotValid(file) { return nil } > > if fileDoesNotContainsData(file, kind) { return nil } > > > if fileDataOutOfDate(file) { return nil } > > > // Prevent the deferred handler from closing the file > closeFile = false > > return file > } > > Which imo would be much cleaner if we were able to write: > > func openFile(kind: String) -> UnsafeMutablePointer? { > > var file = fopen("MyFile.txt", "r") > > CLOSE_FILE: defer { fclose(file) } > > if fileIsNotValid(file) { return nil } > > if fileDoesNotContainsData(file, kind) { return nil } > > if fileDataOutOfDate(file) { return nil } > > // Prevent the deferred handler from closing the file > cancel CLOSE_FILE > > return file > } > > Regards, > Rien > > Site: http://balancingrock.nl > Blog: http://swiftrien.blogspot.com > Github: http://github.com/Swiftrien > Project: http://swiftfire.nl > ___ > 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] Cancelable named defer statements
A closure assigned to a variable is already a named handler… Make it optional and it’s now a cancelable named handler… Put it in a defer block and you have exactly what you want, a cancelable named defer handler… func doSomething(input: String) -> String? { // Create a cancelable named defer handler var namedDeferHandler: (() -> Void)? = { print("It didn't work, but I've taken care of any cleaning up.") } defer { namedDeferHandler?() } // Check the input if input == "" { return nil } // Cancel the named defer handler namedDeferHandler = nil return "It worked!" } It’s very flexible, you can have multiple handlers and cancel only some of them, include some non-optional code in the defer block itself, etc. On Sat, 7 Jan 2017 at 18:45 Charles Srstka via swift-evolution < swift-evolution@swift.org> wrote: > > On Jan 7, 2017, at 12:40 PM, D. Felipe Torres via swift-evolution < > swift-evolution@swift.org> wrote: > > > > Any cancelable defer addition we could come up with will need a > flag/state to indicate so, which won't be that much different from what you > wrote. > > > > Having said that, for your example may I suggest this approach instead: > > > > func openFile(kind: String) -> UnsafeMutablePointer? { > > > > var file = fopen("MyFile.txt", "r") > > guard fileIsValid(file) > > && fileContainsData(file, kind) > > && !fileDataOutOfDate(file) else { > > fclose(file) > > } > > > > return file > > } > > Or: > > func openFile(kind: String) -> UnsafeMutablePointer? { > var file = fopen("MyFile.txt", "r”) > > do { > if fileIsNotValid(file) { throw MyError.fileIsNotValid } > > if fileDoesNotContainsData(file, kind) { throw > MyError.doesNotContainData } > > if fileDataOutOfDate(file) { throw MyError.dataOutOfDate } > > return file > } catch { > fclose(file) > } > } > > 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] Cancelable named defer statements
> On Jan 7, 2017, at 12:40 PM, D. Felipe Torres via swift-evolution > wrote: > > Any cancelable defer addition we could come up with will need a flag/state to > indicate so, which won't be that much different from what you wrote. > > Having said that, for your example may I suggest this approach instead: > > func openFile(kind: String) -> UnsafeMutablePointer? { > > var file = fopen("MyFile.txt", "r") > guard fileIsValid(file) > && fileContainsData(file, kind) > && !fileDataOutOfDate(file) else { > fclose(file) > } > > return file > } Or: func openFile(kind: String) -> UnsafeMutablePointer? { var file = fopen("MyFile.txt", "r”) do { if fileIsNotValid(file) { throw MyError.fileIsNotValid } if fileDoesNotContainsData(file, kind) { throw MyError.doesNotContainData } if fileDataOutOfDate(file) { throw MyError.dataOutOfDate } return file } catch { fclose(file) } } Charles ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
Re: [swift-evolution] Cancelable named defer statements
Any cancelable defer addition we could come up with will need a flag/state to indicate so, which won't be that much different from what you wrote. Having said that, for your example may I suggest this approach instead: func openFile(kind: String) -> UnsafeMutablePointer? { var file = fopen("MyFile.txt", "r") guard fileIsValid(file) && fileContainsData(file, kind) && !fileDataOutOfDate(file) else { fclose(file) } return file } On Sat, Jan 7, 2017 at 7:20 PM, Rien via swift-evolution < swift-evolution@swift.org> wrote: > Is there any interest in a proposal to introduce a named defer statement > that can be cancelled? > > Lately I find myself writing this kind of code: > > func openFile(kind: String) -> UnsafeMutablePointer? { > > > var file = fopen("MyFile.txt", "r") > > > var closeFile = true > > defer { if closeFile { fclose(file) } } > > > if fileIsNotValid(file) { return nil } > > if fileDoesNotContainsData(file, kind) { return nil } > > > if fileDataOutOfDate(file) { return nil } > > > // Prevent the deferred handler from closing the file > closeFile = false > > return file > } > > Which imo would be much cleaner if we were able to write: > > func openFile(kind: String) -> UnsafeMutablePointer? { > > var file = fopen("MyFile.txt", "r") > > CLOSE_FILE: defer { fclose(file) } > > if fileIsNotValid(file) { return nil } > > if fileDoesNotContainsData(file, kind) { return nil } > > if fileDataOutOfDate(file) { return nil } > > // Prevent the deferred handler from closing the file > cancel CLOSE_FILE > > return file > } > > Regards, > Rien > > Site: http://balancingrock.nl > Blog: http://swiftrien.blogspot.com > Github: http://github.com/Swiftrien > Project: http://swiftfire.nl > > ___ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution > > -- ++ Diego Torres. Phone (Mobile Germany): +49 157 30070985 Phone (Landline Chile): +56 2 29790978 Web: dtorres.me ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
Re: [swift-evolution] Cancelable named defer statements
-1. Much of the utility of `defer` is that it's guaranteed to execute. As you demonstrate, it's possible to capture a flag and choose not to do something within the defer block itself. We don't need sugar for that. On Sat, Jan 7, 2017 at 12:20 PM, Rien via swift-evolution < swift-evolution@swift.org> wrote: > Is there any interest in a proposal to introduce a named defer statement > that can be cancelled? > > Lately I find myself writing this kind of code: > > func openFile(kind: String) -> UnsafeMutablePointer? { > > > var file = fopen("MyFile.txt", "r") > > > var closeFile = true > > defer { if closeFile { fclose(file) } } > > > if fileIsNotValid(file) { return nil } > > if fileDoesNotContainsData(file, kind) { return nil } > > > if fileDataOutOfDate(file) { return nil } > > > // Prevent the deferred handler from closing the file > closeFile = false > > return file > } > > Which imo would be much cleaner if we were able to write: > > func openFile(kind: String) -> UnsafeMutablePointer? { > > var file = fopen("MyFile.txt", "r") > > CLOSE_FILE: defer { fclose(file) } > > if fileIsNotValid(file) { return nil } > > if fileDoesNotContainsData(file, kind) { return nil } > > if fileDataOutOfDate(file) { return nil } > > // Prevent the deferred handler from closing the file > cancel CLOSE_FILE > > return file > } > > Regards, > Rien > > Site: http://balancingrock.nl > Blog: http://swiftrien.blogspot.com > Github: http://github.com/Swiftrien > Project: http://swiftfire.nl > > ___ > 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] Cancelable named defer statements
Is there any interest in a proposal to introduce a named defer statement that can be cancelled? Lately I find myself writing this kind of code: func openFile(kind: String) -> UnsafeMutablePointer? { var file = fopen("MyFile.txt", "r") var closeFile = true defer { if closeFile { fclose(file) } } if fileIsNotValid(file) { return nil } if fileDoesNotContainsData(file, kind) { return nil } if fileDataOutOfDate(file) { return nil } // Prevent the deferred handler from closing the file closeFile = false return file } Which imo would be much cleaner if we were able to write: func openFile(kind: String) -> UnsafeMutablePointer? { var file = fopen("MyFile.txt", "r") CLOSE_FILE: defer { fclose(file) } if fileIsNotValid(file) { return nil } if fileDoesNotContainsData(file, kind) { return nil } if fileDataOutOfDate(file) { return nil } // Prevent the deferred handler from closing the file cancel CLOSE_FILE return file } Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Swiftrien Project: http://swiftfire.nl ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution