[swift-evolution] [Proposal] Scoped resources (like C# using statement)

[Kevin Ballard]

A uniquely-owned class that guarantees stack allocation is pretty much
the same thing as a move-only value type, isn't it? The only real
difference I can think of is classes allow for subclassing.

-Kevin

On Wed, Dec 30, 2015, at 01:18 PM, Chris Lattner wrote:
>
>> On Dec 30, 2015, at 10:31 AM, Joe Groff <jgroff at apple.com> wrote:
>>
>>>
>>> On Dec 30, 2015, at 10:26 AM, Chris Lattner <clattner at apple.com>
>>> wrote:
>>>
>>>>
>>>> On Dec 30, 2015, at 9:53 AM, Joe Groff via swift-evolution <swift-
>>>> evolution at swift.org> wrote:
>>>>
>>>>
>>>>> On Dec 29, 2015, at 8:55 PM, Kevin Ballard via swift-evolution <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.
> So long as it guarantees no heap allocation for the class
> instance, ok.
>
> -Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151230/5998e1c6/attachment.html>