Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Sorry, I had some other thread that involved destructors in my head.

But the point is `defer` is still in "spooky action at a distance" category that I generally don't want in programming languages, especially in c.



Defer is not spooky action at a distance. It is an explicit statement that gets executed as written. Unlike (for example, a familiar feature which C doesn’t have) operator overloading… which causes code that looks like one thing (adition for example) behave like another (a function call). Defer does exactly what it says on the tin can (“move this line to the end of the scope”), just like goto does exactly what it claims to do.

Macros (in general) are way spookier than a defer statement.


>move this line to the end of the scope

Where it is invisible! What is so hard about this to understand?

>operator overloading..

Yes, but if we go by your argument, you can say it gets executed exactly as it is written. It is just that it is written (ie overloading) somewhere else ie "at distance"...just like a defer block that could be far from the end of the scope that is trigerring it


> `defer` is still in "spooky action at a distance" category

Agree, this is also why I'm a bit weary of it.

What brings me on the "pro" side is that, defer or not defer, there will need to be some kind of cleanup anyway. It's just a matter of where it is declared, and close to the acquisition is arguably better.

The caveat IMHO is that if a codebase is not consistent in its use, it could be worst.


But the real-world alternatives that people use are:

1. goto, which is "spooky action at a distance" to the nth degree. It's not even safe, you can goto anywhere, even out of scope.

2. cleanup attributes, which are not standard.


>goto, which is "spooky action at a distance" to the nth degree.

it is not.


It is, just the existence of goto makes control flow significantly harder to understand. People complain about exceptions in C++ obfuscating control flow, but then they recreate exceptions using goto. The funny thing is that exceptions are just fancy goto, the assembly is almost the same.

The bigger picture of C as a language is not that it's simple, because it's not simple at all. It's inept. It doesn't give developers the tools to write simple code. So easy things become hard, and we sort of jank together solutions that kind of work but usually don't.

I like to compare it to building a shed with power tools versus only a screwdriver. Is a screwdriver simpler than a power saw and all that? Of course. Now think about building a shed. Is it simpler to do with a screwdriver? No. It's much, much more complex. You have to develop complex processes to make that work, and it's not intuitive at all.

C is a language that already makes use of implicit control flow A LOT. I don't see defer being a problem. The irony is that if C just supported these use cases out-of-the-box, it would be simpler and easier. As a concrete example, consider polymorphism in C versus C++. Both languages can do it, but one provides the tools and one doesn't. In C++ I can go to definition, I can concretely define what polymorphism is allowed and what isn't, and the type system gives me the tools to make it safe. In C, none of that is true, so when we do polymorphism with function pointers, it's much harder to understand what's actually going on, or what could be going on.


It is not. That `GOTO` makes things hard does not shift it to some unrelated category.

> The funny thing is that exceptions are just fancy goto

Not even close.

>I like to compare it to building a shed with power tools versus only a screwdriver.

That analogy is completely wrong in the context.

> it's not intuitive at all.

It is completely intuitive, while the "modern" languages with "helpful" magic is not.

>C is a language that already makes use of implicit control flow A LOT.

> implicit

I don't think it means what you think it means. At least the examples you mention does not justify it.


None of these were arguments. You just said "nuh uh" in more words, which is really just a waste of storage.


>which is really just a waste of storage.

It is, if you choose not to think about those nuh uhs.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: