5 ms·

I tried to love Zig but the lack of destructors are killing me! They're such a useful tool for resource management, and apparently they weren't added in order t

I tried to love Zig but the lack of destructors are killing me! They're such a useful tool for resource management, and apparently they weren't added in order to make all control flow "explicit" or something.

jorangreef 8y ago
Take a look at Zig's "defer" and "errdefer": https://ziglang.org/documentation/master/#defer https://ziglang.org/documentation/master/#defer
- gmueckl 8y ago
  This seems equivalent to scope(exit)/scope(success)/scope(failure) in D. The drawback of this construct is that you need to repeat 2 or 3 lines of code each time you need safe cleanup or a commit/abort type of construct. This can become pretty repetitive pretty fast.
  - Paul_Diraq 8y ago
    I wish D had copied pythons with statement (without the scope escape) and not used the with statement for destructuring. The nicest thing: you can throw in the exit method without the runtime falling over itself.
    - gmueckl 8y ago
      I totally missed that Python has this. This seems like the saner sibling of C#'s using/IDisposable construct. You can do a kind of RAII in D when you use structs instead of classes because these are stack allocated and have a suitable lifetime.
- edflsafoiewq 8y ago
  They are not comparable to RAII, see my comment above. Even the fact it has to bifurcate into defer and errdefer suggests that it lacks the generality to replace a totalizing resource management solution.
  - notacoward 8y ago
    No, they're not the same as your beloved RAII, but this isn't an object-oriented language so it doesn't have destructors. For the third time, what better solution do you propose for a non-OO language?
notacoward 8y ago
I've never actually used Zig (yet), but I think their choice is reasonable. It's not an object oriented language. Using destructors for resource management in such languages is great, but I've also seen a lot of C++ code that abuses the object-lifetime machinery. The most common is lock pseudo-objects, which "exist" only so that they can be released via a destructor when they go out of scope. Those aren't real objects. They don't contain any data. They're abstractions, which should be dealt with with other guard/context language structures. I'll admit that "defer" is a bit low-level, but it does handle most resource-release use cases in a way that's consistent with the rest of Zig. What non-object-oriented approach would you suggest instead?
- jcelerier 8y ago
  > Using destructors for resource management in such languages is great, but I've also seen a lot of C++ code that abuses the object-lifetime machinery. That's not abuse, that's the most important pattern in C++ (RAII). You mustn't think of C++ "objects" as Java or C# or Smalltalk objects - they are not, they are deterministic resource managers before everything.
  - notacoward 8y ago
    > You mustn't think of C++ "objects" as Java or C# or Smalltalk objects As long as people persist in calling them objects, and use all of the other object-oriented concepts/terminology such as classes and inheritance, people will expect them to be objects. That's not unreasonable. It's absurd to look down your nose at people who are taking you at your word. These other uses are hacks. If you want to be able to attach something to a scope that's great, actually it's a wonderful idea, but just be honest about it. Make scopes a first-class concept, give things names that reflect their scope-oriented meaning and usage. Python's "with" is a step in the right direction; even though the implementation uses objects, they're objects that implement a specific interface (not just creation/destruction) and their usage is distinct. That separation allows scope-based semantics to evolve independently of object-lifetime semantics, which are already muddled by things like lambdas, futures, and coroutines. Tying them together might be an important pattern in C++, but it's also a mistake. Not the first, not the last. Making mistakes mandatory has always been the C++ way.

jorangreef 8y ago

Take a look at Zig's "defer" and "errdefer": https://ziglang.org/documentation/master/#defer https://ziglang.org/documentation/master/#defer

gmueckl 8y ago
This seems equivalent to scope(exit)/scope(success)/scope(failure) in D. The drawback of this construct is that you need to repeat 2 or 3 lines of code each time you need safe cleanup or a commit/abort type of construct. This can become pretty repetitive pretty fast.
- Paul_Diraq 8y ago
  I wish D had copied pythons with statement (without the scope escape) and not used the with statement for destructuring. The nicest thing: you can throw in the exit method without the runtime falling over itself.
  - gmueckl 8y ago
    I totally missed that Python has this. This seems like the saner sibling of C#'s using/IDisposable construct. You can do a kind of RAII in D when you use structs instead of classes because these are stack allocated and have a suitable lifetime.
edflsafoiewq 8y ago
They are not comparable to RAII, see my comment above. Even the fact it has to bifurcate into defer and errdefer suggests that it lacks the generality to replace a totalizing resource management solution.
- notacoward 8y ago
  No, they're not the same as your beloved RAII, but this isn't an object-oriented language so it doesn't have destructors. For the third time, what better solution do you propose for a non-OO language?

notacoward 8y ago

I've never actually used Zig (yet), but I think their choice is reasonable. It's not an object oriented language. Using destructors for resource management in such languages is great, but I've also seen a lot of C++ code that abuses the object-lifetime machinery. The most common is lock pseudo-objects, which "exist" only so that they can be released via a destructor when they go out of scope. Those aren't real objects. They don't contain any data. They're abstractions, which should be dealt with with other guard/context language structures. I'll admit that "defer" is a bit low-level, but it does handle most resource-release use cases in a way that's consistent with the rest of Zig. What non-object-oriented approach would you suggest instead?

jcelerier 8y ago
> Using destructors for resource management in such languages is great, but I've also seen a lot of C++ code that abuses the object-lifetime machinery. That's not abuse, that's the most important pattern in C++ (RAII). You mustn't think of C++ "objects" as Java or C# or Smalltalk objects - they are not, they are deterministic resource managers before everything.
- notacoward 8y ago
  > You mustn't think of C++ "objects" as Java or C# or Smalltalk objects As long as people persist in calling them objects, and use all of the other object-oriented concepts/terminology such as classes and inheritance, people will expect them to be objects. That's not unreasonable. It's absurd to look down your nose at people who are taking you at your word. These other uses are hacks. If you want to be able to attach something to a scope that's great, actually it's a wonderful idea, but just be honest about it. Make scopes a first-class concept, give things names that reflect their scope-oriented meaning and usage. Python's "with" is a step in the right direction; even though the implementation uses objects, they're objects that implement a specific interface (not just creation/destruction) and their usage is distinct. That separation allows scope-based semantics to evolve independently of object-lifetime semantics, which are already muddled by things like lambdas, futures, and coroutines. Tying them together might be an important pattern in C++, but it's also a mistake. Not the first, not the last. Making mistakes mandatory has always been the C++ way.