My understanding is that you suggest using the "do using" statement for two
purposes:
to deterministically free resources (files, sockets);
to create a scope with a guarantee about something (locks).
The first purpose is very relevant for garbage-collected languages because the
GC generally only monitors memory pressure to decide when to run, and so the GC
won't budge if you're running out of file descriptors even if some could be
reclaimed. However, Swift is not garbage-collected and resources are already
reclaimed deterministically. If you create a Swift object that represents a
file descriptor and don't allow references to escape the function, the object
will be destroyed (and its resources reclaimed) at the latest when the function
returns. In my opinion, this makes a "do using" statement useless for resource
management.
For scopes with guarantees, as Chris said, the most common pattern is to have a
function that accepts a closure. I've seen some pretty serious nesting with `if
let` (which are one very frequent case of scopes with guarantees), but other
than that, I don't see lots of nesting and I've been pretty happy with what the
language can do so far. The only thing I can complain about is that you can't
use break/continue with the current setup.
I see the discrepancy between objects, but I would say that any scope-based
solution will often be just as hard to discover as the current solutions. `do
using AutoreleasePool() { ... }` isn't an improvement over `autoreleasepool {
... }`.
It's better for the lock case, but only if you agree that `do using` is useless
for resource management. Otherwise, if your mutex itself benefits from being
scoped, `do using lock` is probably creating/deleting a mutex, and you'd need
to use `do using Lock(mutex) { ... }` to actually lock it (like with C++
mutex/lock objects), which is as discoverable as `mutex.lock { ... }`.
Félix
> Le 29 déc. 2015 à 23:24:53, Trent Nadeau via swift-evolution
> <[email protected]> a écrit :
>
> While useful, that pattern doesn't seem to compose well. What if you need two
> locks? Would that be:
>
> lock1.withThisLockHeld {
> lock2.withThisLockHeld {
> // statements
> }
> }
>
> If so, it seems like it has the "pyramid of doom" issue that prompted
> allowing `if let` to have multiple bindings.
>
> In addition to the possible indentation and vertical space issue, you need to
> look up if and how each resource type does this. I believe this is a general
> enough pattern that it deserves language support. I think an analogy to the
> current situation would be if each collection type had its own way to iterate
> (Array.forEach, Set.withEachElement, etc.) instead of having for-in.
>
> On Tue, Dec 29, 2015 at 11:15 PM, Chris Lattner <[email protected]
> <mailto:[email protected]>> wrote:
> On Dec 29, 2015, at 8:02 PM, Trent Nadeau via swift-evolution
> <[email protected] <mailto:[email protected]>> wrote:
> > Doing this manually is possible using `defer` statements among other
> > options, but this is error prone as a `defer` can be forgotten,
> > `lock`/`unlock` calls for two locks can be switched due to a typo, etc.
> > Having a dedicated language construct for this common case makes it easier
> > to read and write while making code shorter and clearer.
> >
> > ```swift
> > do {
> > lock.enterScope()
> > defer { lock.exitScope() }
> >
> > let file = try getFileHandle()
> > file.enterScope()
> > defer { file.exitScope() }
> >
> > // statements
> > }
>
> We have another pattern that types can use, which is:
>
> lock.withThisLockHeld {
> … stuff ...
> }
>
> This can be done today with trailing closures. Other examples of this are
> “autoreleasepool” and withUnsafePointer (for other reasons).
>
> -Chris
>
>
>
>
> --
> Trent Nadeau
> _______________________________________________
> swift-evolution mailing list
> [email protected] <mailto:[email protected]>
> https://lists.swift.org/mailman/listinfo/swift-evolution
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
