[swift-evolution] [Proposal] Scoped resources (like C# using statement)
David Owens II
david at owensd.io
Wed Dec 30 13:08:14 CST 2015
+1 to Joe’s comment.
> On Dec 30, 2015, at 10:31 AM, Joe Groff via swift-evolution <swift-evolution at swift.org> wrote:
>> On Dec 30, 2015, at 10:26 AM, Chris Lattner <clattner at apple.com <mailto:clattner at apple.com>> wrote:
>>> On Dec 30, 2015, at 9:53 AM, Joe Groff via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>> On Dec 29, 2015, at 8:55 PM, Kevin Ballard via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>> An alternative solution is to do what Rust and C++ do, which is to use RAII. Which is to say, instead of introducing a new language construct that's explicitly tied to a scope, you just use a struct to represent the resource that you hold (e.g. a File that represents an open file). Of course, this does require some changes to structs, notably the addition of a deinit. And if structs have a deinit, then they also need to have a way to restrict copies. This is precisely what Rust does; any struct in Rust that implements Drop (the equivalent to deinit) loses the ability to be implicitly copied (a second trait called Clone provides a .clone() method that is the normal way to copy such non-implicitly-copyable structs).
>>> deinit doesn't make sense for value types.
>> It would if we extended the model for value types to be richer, e.g. to introduce the notion of "move only” structs.
> Perhaps, but I feel like it's a more natural extension of our existing model to support uniquely-owned classes though, which would give you all the same benefits.
> swift-evolution mailing list
> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution