3 ms·

> Rust: Drop runs automatically at scope end, so this specific bug simply doesn’t exist. That's why having no auto-destructors is a dead-end. This is the great

> Rust: Drop runs automatically at scope end, so this specific bug simply doesn’t exist. That's why having no auto-destructors is a dead-end. This is the greatest mistake of such languages like Zig or Odin.

dnautics 13d ago
You can statically analyze for leaks.
- Panzerschrek 13d ago
  But with static analysis it's still possible to miss some leaks or to have false-positives. That's why an integrated language mechanism preventing such leaks is much better.
  - dnautics 13d ago
    Yes, so you pick "false positives" instead of "missing some leaks" and you build a way to mark code as "unsafe". This is not fucking rocket science > That's why an integrated language mechanism preventing such leaks is much better. No categorical difference, except one is opt-in. You can even design your static analyzer so it analyses the code of dependencies that haven't opted in.
    - estebank 13d ago
      Making things opt-in means that it will happen less often, making them opt-out that they will happen more often. In this case, on the one hand you have destructors that don't run when they should, and on the other you have destructors running at a more granular level than you'd want sometimes. I know which human failure mode I prefer.
      - dnautics 12d ago
        In practice as long as you stick to using zig std, an analyzer can get quite far
- IshKebab 12d ago
  I doubt that. I mean I'm sure it can catch some cases, but if it worked reliably it would just be a language feature.
  - dnautics 12d ago
    Maybe the authors just don't want to do it? Anyways: its possible, I am building it as a very side project. github.com/ityonemo/clr
delamon 13d ago
They don't play nicely with arena allocators. And arenas is what you reach for if you have clear lifetime bounds: e.g. a single request with arena never de-allocates individual objects, nukes arena when done. That gives you an easy verifiable protection against leaks, data (and cache) locality and deallocation that cost zero cpu cycles.
- tcfhgj 13d ago
  Why not though? Have a boxed object have implemented drop, then when the box leaves some scope the Box will clean up it's stuff (drop implementation if there is any) and deallocate it's memory using the allocator (which the arena will treat as noop).
  - delamon 13d ago
    Yes, that would work. But you would need to carry pointer to allocator inside box and it is extra code to run for every object.
    - tcfhgj 13d ago
      extra code meaning the drop implementation or something else?
      - delamon 13d ago
        Yes, I mean the code in the drop implementation.
        tcfhgj 13d ago
        it isn't really overhead, assuming you don't forget defer ... accidentally
- Panzerschrek 13d ago
  It's technically possible to perform arena-based allocation and still have compiler checks. The compiler just need to track objects allocated with an allocator and prevent destructing the allocator itself as long as there is at least one object using it. It's like view span objects in rust. The compiler knowns that a span is logically connected to the parent object and don't allow destroying it when such span exists.

dnautics 13d ago

You can statically analyze for leaks.

Panzerschrek 13d ago
But with static analysis it's still possible to miss some leaks or to have false-positives. That's why an integrated language mechanism preventing such leaks is much better.
- dnautics 13d ago
  Yes, so you pick "false positives" instead of "missing some leaks" and you build a way to mark code as "unsafe". This is not fucking rocket science > That's why an integrated language mechanism preventing such leaks is much better. No categorical difference, except one is opt-in. You can even design your static analyzer so it analyses the code of dependencies that haven't opted in.
  - estebank 13d ago
    Making things opt-in means that it will happen less often, making them opt-out that they will happen more often. In this case, on the one hand you have destructors that don't run when they should, and on the other you have destructors running at a more granular level than you'd want sometimes. I know which human failure mode I prefer.
    - dnautics 12d ago
      In practice as long as you stick to using zig std, an analyzer can get quite far
IshKebab 12d ago
I doubt that. I mean I'm sure it can catch some cases, but if it worked reliably it would just be a language feature.
- dnautics 12d ago
  Maybe the authors just don't want to do it? Anyways: its possible, I am building it as a very side project. github.com/ityonemo/clr

delamon 13d ago

They don't play nicely with arena allocators. And arenas is what you reach for if you have clear lifetime bounds: e.g. a single request with arena never de-allocates individual objects, nukes arena when done. That gives you an easy verifiable protection against leaks, data (and cache) locality and deallocation that cost zero cpu cycles.

tcfhgj 13d ago
Why not though? Have a boxed object have implemented drop, then when the box leaves some scope the Box will clean up it's stuff (drop implementation if there is any) and deallocate it's memory using the allocator (which the arena will treat as noop).
- delamon 13d ago
  Yes, that would work. But you would need to carry pointer to allocator inside box and it is extra code to run for every object.
  - tcfhgj 13d ago
    extra code meaning the drop implementation or something else?
    - delamon 13d ago
      Yes, I mean the code in the drop implementation.
      - tcfhgj 13d ago
        it isn't really overhead, assuming you don't forget defer ... accidentally
Panzerschrek 13d ago
It's technically possible to perform arena-based allocation and still have compiler checks. The compiler just need to track objects allocated with an allocator and prevent destructing the allocator itself as long as there is at least one object using it. It's like view span objects in rust. The compiler knowns that a span is logically connected to the parent object and don't allow destroying it when such span exists.