2 ms·
Is it the end of the function, or the end of the scope? There's also no reason the compiler couldn't allow the deferred call once the last reference has been u
by mjevans 7y ago
Is it the end of the function, or the end of the scope?
There's also no reason the compiler couldn't allow the deferred call once the last reference has been utilized (though in practice the common and performance minded case probably is to just use it as an additional goroutine that the context passes execution to when it queues any return messages).
- EdSchouten 7y agoThe end of the function: https://golang.org/ref/spec#Defer_statements https://golang.org/ref/spec#Defer_statements
- zozbot234 7y ago> There's also no reason the compiler couldn't allow the deferred call once the last reference has been utilized There's one reason not to do this - preserving the language semantics. Rust's version of RAII drops owned objects at the end of their scope for the same reason, even though it 'could' do better especially given NLL.