> 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 >> <[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. -Joe
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
