<!DOCTYPE html>
<html>
<head>
<title></title>
</head>
<body><div>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.<br></div>
<div> </div>
<div>-Kevin</div>
<div> </div>
<div>On Wed, Dec 30, 2015, at 01:18 PM, Chris Lattner wrote:<br></div>
<blockquote type="cite"><div> </div>
<div><blockquote type="cite"><div>On Dec 30, 2015, at 10:31 AM, Joe Groff <<a href="mailto:jgroff@apple.com">jgroff@apple.com</a>> wrote:<br></div>
<div> </div>
<div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;orphans:auto;text-align:start;text-indent:0px;text-transform:none;white-space:normal;widows:auto;word-spacing:0px;-webkit-text-stroke-width:0px;"><blockquote type="cite"><div><div> </div>
<div>On Dec 30, 2015, at 10:26 AM, Chris Lattner <<a href="mailto:clattner@apple.com">clattner@apple.com</a>> wrote:<br></div>
</div>
<div> </div>
<div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;orphans:auto;text-align:start;text-indent:0px;text-transform:none;white-space:normal;widows:auto;word-spacing:0px;-webkit-text-stroke-width:0px;"><blockquote type="cite"><div><div> </div>
<div>On Dec 30, 2015, at 9:53 AM, Joe Groff via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div>
</div>
<div> </div>
<div><div style="word-wrap:break-word;-webkit-line-break:after-white-space;"><div> </div>
<div><blockquote type="cite"><div>On Dec 29, 2015, at 8:55 PM, Kevin Ballard via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div>
<div> </div>
<div><div><div>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).<br></div>
</div>
</div>
</blockquote><div> </div>
<div>deinit doesn't make sense for value types. <br></div>
</div>
</div>
</div>
</blockquote></div>
<div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;orphans:auto;text-align:start;text-indent:0px;text-transform:none;white-space:normal;widows:auto;word-spacing:0px;-webkit-text-stroke-width:0px;">It would if we extended the model for value types to be richer, e.g. to introduce the notion of "move only” structs.<br></div>
</div>
</blockquote></div>
<div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;orphans:auto;text-align:start;text-indent:0px;text-transform:none;white-space:normal;widows:auto;word-spacing:0px;-webkit-text-stroke-width:0px;">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.<br></div>
</div>
</blockquote></div>
<div>So long as it guarantees no heap allocation for the class instance, ok.<br></div>
<div> </div>
<div>-Chris<br></div>
</blockquote><div> </div>
</body>
</html>