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 <[email protected]> wrote: >> >>> >>> On Dec 30, 2015, at 10:26 AM, Chris Lattner <[email protected]> >>> wrote: >>> >>>> >>>> On Dec 30, 2015, at 9:53 AM, Joe Groff via swift-evolution <swift- >>>> [email protected]> wrote: >>>> >>>> >>>>> On Dec 29, 2015, at 8:55 PM, Kevin Ballard via swift-evolution <swift- >>>>> [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
