> On Dec 30, 2015, at 1:22 PM, Kevin Ballard <[email protected]> wrote: > > 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.
At this point, we’re talking about two unspecified and hypothetical models, so of course they’re both equivalent and completely different :-) We should talk about this in more detail later (perhaps next year, perhaps the year after), but I am pretty concerned with saying that unique ownership of classes replaces move-only types. From a programming model perspective (how the programmer thinks about & designs their code) both capabilities are important. You want move-only struct types in various cases and unique ownership of class instances. For example, IMO, a uniquely-owned class instance has to be on the heap, because it would have to convert to a multiply owned reference in many cases, and “moving” a class from the stack to the heap is, uh, complicated. -Chris > > -Kevin > > On Wed, Dec 30, 2015, at 01:18 PM, Chris Lattner wrote: >> >>> On Dec 30, 2015, at 10:31 AM, Joe Groff <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>>> >>>> On Dec 30, 2015, at 10:26 AM, Chris Lattner <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>>> >>>>> On Dec 30, 2015, at 9:53 AM, Joe Groff via swift-evolution >>>>> <[email protected] <mailto:[email protected]>> wrote: >>>>> >>>>> >>>>>> On Dec 29, 2015, at 8:55 PM, Kevin Ballard via swift-evolution >>>>>> <[email protected] <mailto:[email protected]>> 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 >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
