Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Defer Technical Specification: It Is Time

thephd.dev

Post reply on HN
Print view View original

21–30 of 77 posts

Re: The Defer Technical Specification: It Is Time

#21

Post by dgunay »

topspin wrote: post #7

Regarding the statements on golang's defer: "the defer call is hoisted to the outside of the for loop in func work" Astonishing. Add that to the list of golang head scratchers. That is one of the biggest "principle of least astonishment" violations I've ever seen. Disclaimer: Not a golang hater. Great language. Used it myself on occasion, although I remain a golang neophyte. Put away the sharp objects.

It's incredibly ugly but you could sort of hack in a smaller-scoped defer using anonymous functions: https://go.dev/play/p/VgnprcObPHz

Re: The Defer Technical Specification: It Is Time

#22

Post by hinkley »

topspin wrote: post #7

Regarding the statements on golang's defer: "the defer call is hoisted to the outside of the for loop in func work" Astonishing. Add that to the list of golang head scratchers. That is one of the biggest "principle of least astonishment" violations I've ever seen. Disclaimer: Not a golang hater. Great language. Used it myself on occasion, although I remain a golang neophyte. Put away the sharp objects.

I love the Principle of Least Astonishment, but I first encountered it in the Ruby book and I gave up reading it halfway through because I kept thinking, "He and I have very different definitions of astonishing..."

Re: The Defer Technical Specification: It Is Time

#23

Post by klodolph »

throw-qqqqq wrote: post #9

Another cool difference between this and Go’s ‘defer’, is that it doesn’t allocate memory on the heap. Go’s ‘defer’ does and it has a small performance cost compared to just calling the .release() or whatever yourself… shrugs At least this was the case last I did benchmarks of my Go code. Dno if they changed that.

Does go’s defer allocate on the heap? I thought it would only do that if necessary.

Re: The Defer Technical Specification: It Is Time

#25

Post by kats »

_kst_ wrote: post #20
kats wrote: post #18

[flagged]

The author is the project editor for the ISO C standard. (And I hardly think that analyzing speculating about the motivation for the author's chosen nickname is constructive.)

Great! I'm a programmer. And I've sure spent too much time on C++isms.

> (And I hardly think that analyzing speculating about the motivation for the author's chosen nickname is constructive.)

Nope! Gets right to it. This is really building C++ (but this time how I want). It adds work for every C programmer who has to check off a whole bunch of small tasks to keep a codebase living for many years.

Re: The Defer Technical Specification: It Is Time

#26

Post by pkaye »

klodolph wrote: post #23
throw-qqqqq wrote: post #9

Another cool difference between this and Go’s ‘defer’, is that it doesn’t allocate memory on the heap. Go’s ‘defer’ does and it has a small performance cost compared to just calling the .release() or whatever yourself… shrugs At least this was the case last I did benchmarks of my Go code. Dno if they changed that.

Does go’s defer allocate on the heap? I thought it would only do that if necessary.

I know they implemented an optimization back in go 1.13. Not sure if that will help.

https://github.com/golang/proposal/blob/master/design/34481-...

Re: The Defer Technical Specification: It Is Time

#27

Post by jayd16 »

Animats wrote: post #4

Ugh. Go's "defer" is reasonably clean because Go is garbage-collected. So you don't have to worry about something being deleted before a queued "defer" runs. That's well-behaved. This is going to be full of ugly, non-obvious problems. Interestingly, it's not really "defer" in the Go sense. It's "finally", in the try/finally sense of C++, using Go-type "defer" syntax". This mostly matters for scope and ownership issue…

> It's "finally", in the try/finally sense of C++

What sense is that? C++ doesn't have finally and the article explicitly calls out how its not like destructors.

Re: The Defer Technical Specification: It Is Time

#28

Post by Animats »

jayd16 wrote: post #27
Animats wrote: post #4

Ugh. Go's "defer" is reasonably clean because Go is garbage-collected. So you don't have to worry about something being deleted before a queued "defer" runs. That's well-behaved. This is going to be full of ugly, non-obvious problems. Interestingly, it's not really "defer" in the Go sense. It's "finally", in the try/finally sense of C++, using Go-type "defer" syntax". This mostly matters for scope and ownership issue…

> It's "finally", in the try/finally sense of C++ What sense is that? C++ doesn't have finally and the article explicitly calls out how its not like destructors.

Right, C++ doesn't have "finally". But "defer" defers to when a "finally" section would run in a language that has it. I think.

Re: The Defer Technical Specification: It Is Time

#29

Post by chrsig »

Jtsummers wrote: post #6

> The central idea behind defer is that, unlike its Go counterpart, defer in C is lexically bound, or “translation-time” only, or “statically scoped”. What that means is that defer runs unconditionally at the end of the block or the scope it is bound to based on its lexical position in the order of the program. The only reasonable way for defer to behave. Function scoped never made sense to me given the wasted potent…

yeah, I've always just extracted the loop body into a new function as a result

Re: The Defer Technical Specification: It Is Time

#30

Post by IshKebab »

Animats wrote: post #28
jayd16 wrote: post #27

Earlier quoted context omitted.

> It's "finally", in the try/finally sense of C++ What sense is that? C++ doesn't have finally and the article explicitly calls out how its not like destructors.

Right, C++ doesn't have "finally". But "defer" defers to when a "finally" section would run in a language that has it. I think.

That's what it does in Go too. This is totally defer in the Go sense (except they fixed the scoping issue).
Post reply on HN