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 file
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
> 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 appro
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
-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.o
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 closeF