<div dir="ltr">I’m highly supportive of this, but this pitch is incomplete. Unless we restrict stack-classes to be non-escaping, and non copyable, at the minimum we need to force the user to implement a copy initializer as well as <span style="font-family:monospace,monospace">deinit</span>. If we also want to support moves, this could make the compiler diagnostics more complex since now it’s possible for a variable to be deinitialized before the end of a block. Also as a nit, I would rather such a thing use the <span style="font-family:monospace,monospace">struct</span> keyword as I associate the keyword <span style="font-family:monospace,monospace">class</span> in Swift with heap indirection.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 27, 2017 at 10:49 AM, Gwendal Roué via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<br>
It looks like you want compiler guarantees that an object will be "deinited" at the end of a syntactic block:<br>
<br>
func f() {<br>
let a = Object()<br>
...<br>
// <- guarantee that a.deinit is called here<br>
}<br>
<br>
Currently, Swift does not grant such guarantee. If the object gets retained somewhere, its deallocation is postponed:<br>
<br>
var storage: [Object] = []<br>
func f() {<br>
let a = Object()<br>
storage.append(a)<br>
// <- a.deinit is not called here<br>
}<br>
<br>
With your proposal, the code above would not compile.<br>
<br>
The current Swift way to guarantee "cleanup" tasks is the `defer` statement:<br>
<br>
func f() {<br>
let a = Object()<br>
defer { a.cleanup() }<br>
...<br>
}<br>
<br>
But this has several defects: object is not fully responsible of its state, and one can get "zombie" values that stay around:<br>
<br>
var storage: [Object] = []<br>
func f() {<br>
let a = Object()<br>
defer { a.cleanup() } // <- can be forgotten<br>
storage.append(a) // <- storage will contain "zombie" object<br>
}<br>
<br>
So I understand how it looks like Swift does not currently support what C++ programmers are used to when they mix RAII with guaranteed stack allocation. Note, though, that in C++ guaranteed stack allocation comes for the declaration of a value, not from its type.<br>
<br>
Is it the correct context of your pitch? Given the immense C++ experience of Swift designers, this is surely something they know pretty well. I don't know why they did not bring this to Swift. This question itself is an interesting topic!<br>
<br>
Gwendal<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
> Le 27 oct. 2017 à 15:27, Mike Kluev via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> a écrit :<br>
><br>
> if it wasn't already discussed here is the preliminary proposal, if it was then my +1 to the feature.<br>
><br>
> i propose we have an explicit apparatus to denote classes having stack storage.<br>
><br>
> stack class StackObject { // guaranteed to be on stack<br>
> }<br>
><br>
> class NonStackObject { // is not guaranteed to be on stack, can be on heap as well<br>
> }<br>
><br>
> this is for performance reasons. sometimes what we need is “structs with deinit” and as this is not going to happen the next best thing could be “lightweight” classes. this shall be self obvious, here are few examples:<br>
><br>
> stack class StackObject {<br>
> var variable = 0<br>
><br>
> func foo() {<br>
> print(“i am ok to live on stack”)<br>
> }<br>
> }<br>
><br>
> stack class BadObject {<br>
> var variable = 0<br>
><br>
> func foo() {<br>
> DispatchQueue.main.async { // error: can’t be a stack class<br>
> self.variable = 1<br>
> }<br>
> }<br>
> }<br>
><br>
> class NonStackObject {<br>
> …<br>
> }<br>
><br>
> foo() {<br>
> let stackObject = StackObject()<br>
><br>
> DispatchQueue.main.async {<br>
> stackObject.foo() // error: can’t use a stack object in this context<br>
> }<br>
> }<br>
><br>
</div></div><div class="HOEnZb"><div class="h5">> ______________________________<wbr>_________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
<br>
______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
</div></div></blockquote></div><br></div>