<!DOCTYPE html>
<html>
<head>
<title></title>
</head>
<body><div>That's completely false. All of the Cocoa classes that manage resources absolutely clean them up in deinit. The explicit call to closeFile() on NSFileHandle exists for two reasons:<br></div>
<div> </div>
<div>1. To let you close the file before throwing away the handle (e.g. if you know the handle is being kept alive by something else but still want to close the file right now), and<br></div>
<div>2. Because you can create instances of NSFileHandle that explicitly don't close the handle in dealloc (typically because they don't "own" the file handle), the closeFile() call lets you change your mind and close it anyway.<br></div>
<div> </div>
<div>NSStream doesn't document its deinit behavior, but it definitely closes itself automatically if it's still open when it deinits.<br></div>
<div> </div>
<div>Also, the quoted passage from the Swift documentation is talking about why you might need to implement deinit. In your class's deinit you can close/free any resources that your class manages.<br></div>
<div> </div>
<div>So none of this is at all relevant to any kind of scoped operation.<br></div>
<div> </div>
<div>-Kevin Ballard</div>
<div> </div>
<div>On Tue, Dec 29, 2015, at 10:45 PM, Trent Nadeau via swift-evolution wrote:<br></div>
<blockquote type="cite"><div dir="ltr"><div>I disagree that `do using` would be useless for resources. Essentially no Cocoa resource classes have a `deinit`. NSFileHandle, NSStream, etc. require a close-like call to free the underlying resource. Also, per the Swift documentation about deinitialization:<br></div>
<div> </div>
<div> "Typically you don’t need to perform manual clean-up when your instances are deallocated. However, when you are working with your own resources, you might need to perform some additional clean-up yourself. For example, if you create a custom class to open a file and write some data to it, you might need to close the file before the class instance is deallocated."<br></div>
<div><div> </div>
<div><div>On Wed, Dec 30, 2015 at 1:19 AM, Félix Cloutier <span dir="ltr"><<a href="mailto:felixcca@yahoo.ca">felixcca@yahoo.ca</a>></span> wrote:<br></div>
<blockquote style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204, 204, 204);border-left-style:solid;padding-left:1ex;"><div style="word-wrap:break-word;"><div>My understanding is that you suggest using the "do using" statement for two purposes:<br></div>
<div> </div>
<div><ol><li>to deterministically free resources (files, sockets);<br></li><li>to create a scope with a guarantee about something (locks).<br></li></ol><div> </div>
</div>
<div>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.<br></div>
<div> </div>
<div>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.<br></div>
<div> </div>
<div>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 { ... }`.<br></div>
<div> </div>
<div>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 { ... }`.<br></div>
<div> </div>
<div><span><span class="colour" style="color:rgb(136, 136, 136)"><span style="border-collapse:separate;line-height:normal;-webkit-border-horizontal-spacing:0px;-webkit-border-vertical-spacing:0px;">Félix</span></span></span><br></div>
<div> </div>
<div><blockquote type="cite"><div><div><div>Le 29 déc. 2015 à 23:24:53, Trent Nadeau via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> a écrit :<br></div>
<div> </div>
</div>
</div>
<div><div><div><div style="font-family:LucidaGrande;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;" dir="ltr"><div>While useful, that pattern doesn't seem to compose well. What if you need two locks? Would that be:<br></div>
<div> </div>
<div>lock1.withThisLockHeld {<br></div>
<div> lock2.withThisLockHeld {<br></div>
<div> // statements<br></div>
<div> }<br></div>
<div>}<br></div>
<div> </div>
<div>If so, it seems like it has the "pyramid of doom" issue that prompted allowing `if let` to have multiple bindings.<br></div>
<div> </div>
<div>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.<br></div>
</div>
<div style="font-family:LucidaGrande;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;"><div> </div>
<div><div>On Tue, Dec 29, 2015 at 11:15 PM, Chris Lattner<span></span><span dir="ltr"><<a href="mailto:clattner@apple.com">clattner@apple.com</a>></span><span></span>wrote:<br></div>
<blockquote style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204, 204, 204);border-left-style:solid;padding-left:1ex;"><div><span>On Dec 29, 2015, at 8:02 PM, Trent Nadeau via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>> 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.<br>><br></span><span>> ```swift<br>> do {<br>> lock.enterScope()<br>> defer { lock.exitScope() }<br>><br>> let file = try getFileHandle()<br>> file.enterScope()<br>> defer { file.exitScope() }<br>><br>> // statements<br>> }<br><br></span>We have another pattern that types can use, which is:</div>
<div> </div>
<div>lock.withThisLockHeld {<br></div>
<div> <span></span>… stuff ...<br></div>
<div>}<br></div>
<div> </div>
<div>This can be done today with trailing closures. Other examples of this are “autoreleasepool” and withUnsafePointer (for other reasons).<br></div>
<div><span><span class="colour" style="color:rgb(136, 136, 136)"><br>-Chris<br></span></span></div>
</blockquote></div>
<div> </div>
<div> </div>
<div> </div>
<div>--<span></span><br></div>
<div>Trent Nadeau<br></div>
</div>
</div>
</div>
<div><span><img style="font-family:LucidaGrande;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;min-height:1px !important;width:1px !important;border-top-width:0px !important;border-right-width:0px !important;border-bottom-width:0px !important;border-left-width:0px !important;margin-top:0px !important;margin-right:0px !important;margin-bottom:0px !important;margin-left:0px !important;padding-top:0px !important;padding-right:0px !important;padding-bottom:0px !important;padding-left:0px !important;" border="0" height="1" width="1" alt="" src="https://www.fastmailusercontent.com/proxy/b14eafe3db7cfeb8d2038ca747ca6a27c3f8af384cab7e6ed968ce40f3e3df64/8647470737a3f2f25723030323431303e23647e23756e64676279646e2e65647f27766f2f60756e6f35707e6d396259433265684455633558795148445c66533c6143383a794056684d486975725a77645d674b46563b66315e6c694035346567716e443b4372355e685a716879776e4d2236485142663b4a7764423b465a7f693c6635656333393c68424573725373616857303871555265383d414766637531747d6b4d22364168657b617559335a6672796c666f6835327468574d405c6c644735763b62334268727c423d6975425a485338483278517978646d223242555773733f6a71543f6b67414346696158316e61726d223246447a685875747a716749634c4a543367383d6569624e436957516d223246403f496465676951573649443d23344/open"><span class="font" style="font-family:LucidaGrande"><span class="size" style="font-size:12px"><span></span>_______________________________________________</span></span><br style="font-family:LucidaGrande;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;"><span class="font" style="font-family:LucidaGrande"><span class="size" style="font-size:12px">swift-evolution mailing list</span></span><br style="font-family:LucidaGrande;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;"><a style="font-family:LucidaGrande;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;" href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br style="font-family:LucidaGrande;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;"><a style="font-family:LucidaGrande;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;" href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span></div>
</div>
</blockquote></div>
<div> </div>
</div>
</blockquote></div>
<div> </div>
<div> </div>
<div> </div>
<div>-- <br></div>
<div>Trent Nadeau<br></div>
</div>
</div>
<div><img style="height:1px !important;width:1px !important;border-top-width:0px !important;border-right-width:0px !important;border-bottom-width:0px !important;border-left-width:0px !important;margin-top:0px !important;margin-bottom:0px !important;margin-right:0px !important;margin-left:0px !important;padding-top:0px !important;padding-bottom:0px !important;padding-right:0px !important;padding-left:0px !important;" border="0" height="1" width="1" alt="" src="https://www.fastmailusercontent.com/proxy/15ae7f0d7422ec3f7d78a5c9486c77a99035ab086c582876bdfa03d59fdb18d4/8647470737a3f2f25723030323431303e23647e23756e64676279646e2e65647f27766f2f60756e6f35707e6d3148765176786c673171614a7d2236454230345272776e4759626f426479677173375344657d22324777683f6a44503757505a57795332345d223648605e41537148475232435179683d6c637d22324769545e66795872413d223646703175787e4c483074515c6d677059746b45724335436d2236464c4163364373454e645630315579444562695a58423237713d22324c6f6e497c686469774c4579453e45374c466759797569733548335c49753c656d486076387659533f666c65614c4365573e6d4340703553637936333663507468764c677038613a4754545275797e435373414d23344d23344/open"><br></div>
<div><u>_______________________________________________</u><br></div>
<div>swift-evolution mailing list<br></div>
<div><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br></div>
<div><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div>
</blockquote><div> </div>
</body>
</html>