> 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] >> <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
