# Property wrapper for automatically closing file descriptors

**URL:** <https://forums.swift.org/t/property-wrapper-for-automatically-closing-file-descriptors/41324>\
**Category:** System\
**Tags:** discussion\
**Created:** [October 20, 2020, 1:47pm UTC](https://forums.swift.org/t/property-wrapper-for-automatically-closing-file-descriptors/41324 "2020-10-20T13:47:18Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![tgymnich](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/tgymnich/32/13511_2.png) [@tgymnich](https://forums.swift.org/u/tgymnich)\
**Post date:** [October 20, 2020, 1:47pm UTC](https://forums.swift.org/t/property-wrapper-for-automatically-closing-file-descriptors/41324/1 "2020-10-20T13:47:18Z")

</div>

Since `FileDescriptor` is not automatically closed on `deinit`, I would like to propose adding a property wrapper that automatically closes the wrapped file descriptor.

Here is my first draft:

```swift
public protocol Cloesable {
    func close() throws
}

extension Optional: Cloesable where Wrapped: Cloesable {
    public func close() throws {
        try self?.close()
    }
}

/// Automatically closes the wrapped file descriptor on deinit.
@propertyWrapper public final class AutoClosing<Descriptor: Cloesable> {
    public var wrappedValue: Descriptor

    public init(wrappedValue: Descriptor) {
        self.wrappedValue = wrappedValue
    }

    deinit {
        try? wrappedValue.close()
    }
}

```

`try? wrappedValue.close()` is obviously not ideal here.

---

<div class="post-metadata">

**Author:** ![Lantua](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/lantua/32/8868_2.png) [@Lantua](https://forums.swift.org/u/Lantua)\
**Post date:** [October 20, 2020, 1:55pm UTC](https://forums.swift.org/t/property-wrapper-for-automatically-closing-file-descriptors/41324/2 "2020-10-20T13:55:43Z")

</div>

Maybe we can add something like [`FileHandle`](https://developer.apple.com/documentation/foundation/filehandle/1408522-init)?

---

<div class="post-metadata">

**Author:** ![Michael\_Ilseman](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/michael_ilseman/32/44640_2.png) [@Michael\_Ilseman](https://forums.swift.org/u/Michael_Ilseman)\
**Post date:** [October 23, 2020, 3:17pm UTC](https://forums.swift.org/t/property-wrapper-for-automatically-closing-file-descriptors/41324/3 "2020-10-23T15:17:33Z")

</div>

Long term, I think we want a move-only `File` type that will close on release and encapsulate the file descriptor.

---

<div class="post-metadata">

**Author:** ![lorentey](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/lorentey/32/1299_2.png) [@lorentey](https://forums.swift.org/u/lorentey)\
**Post date:** [February 6, 2021, 4:53am UTC](https://forums.swift.org/t/property-wrapper-for-automatically-closing-file-descriptors/41324/4 "2021-02-06T04:53:40Z")

</div>

> [@tgymnich](#):
>
> `try? wrappedValue.close()` is obviously not ideal here.

I think this is the key problem with this pattern in general. At the level of abstraction on which System's APIs operate, neither silently ignoring the error nor crashing feels like an appropriate choice. System ought to faithfully reflect the low-level C system APIs that it is adapting, and I suspect that in most cases that includes manual management of resources. (Resources other than memory, that is.)

There is a similar issue with `FileDescriptor.closeAfter` -- when both the closure and `close` throw, only the closure's error gets propagated outside. This makes this function less useful: if I need to, say, log the error instead, I'll need to roll my own version of it, or just write the equivalent code inline.

But `closeAfter` is just a simple convenience method -- it was extremely cheap to add, and it draws minimal attention in the module's API surface. `System` would be just as powerful without this function, but its addition slightly improved usability for a common case at essentially zero cost.

Adding a protocol _plus_ a number of conformances _plus_ a property wrapper class(!) for a convenience feature that has similar scope except with an even more serious flaw seems like a far more difficult sell to me. That said, it may be worth revisiting this once this package covers more system functionality -- a protocol like this may make more sense for something like a pthread mutex, where errors during disposal usually indicate a programming error.