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
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
