5 ms·

> defer: Declarative control flow that obviates the need for RAII. I feel like RAII is a term that has expanded to mean more than it means on its face. Maybe s

> defer: Declarative control flow that obviates the need for RAII. I feel like RAII is a term that has expanded to mean more than it means on its face. Maybe someone more familiar with the larger meaning of the term could help me understand? How does a defer capability have anything to do with initializing a resource upon allocation?

Rusky 4y ago
It's had those extra connotations from the start- the whole reason to tie allocation to initialization is so that you can also tie deallocation to destruction, making it automatic and thus less error-prone. "RAII" is mostly just a confusing name for "destructors."
syrrim 4y ago
In C you have a system of memory allocation tied to scoping. A statement like "int x[10];" allocates memory such that when x goes out of scope, the memory is deallocated. RAII generalizes the concept so that when the variable comes in scope, some initializer function is called, and when it goes out of scope some destructor is called. This allows us to use it for dynamic arrays (unlike VLAs in C), hash tables, etc. We can replicate the system by simply calling the initializer when the var comes in scope, and the destructor when it goes out of scope. However, this creates the problem that the two statements are far apart from one another, and thus there is a chance that they might grow out of sync as the code changes. Defer allows us to cause some action to occur when the variable goes out of scope, but declare this at the site where we perform initialization, thus grouping the two together and making it easier to modify them in tandem.
pie_flavor 4y ago
As with most C++ terms, it means something completely perpendicular to what it implies. In general it means that deterministic destructors release a resource at the moment the value representing it goes out of scope, e.g. deallocating memory or closing a file handle. IMO Odin is very wrong on this point: the important thing about destructors is that you know where to find them, so e.g. you can have closures that know how to free their captures when they are freed. There's nothing like that for Odin.
- unsafecast 4y ago
  Odin doesn't even have closures, or any feature that requires this kind of RAII. The whole point here is that the language doesn't deallocate for you.
  - pie_flavor 4y ago
    I know. You say that like it's a good thing.
    - unsafecast 4y ago
      There's value in having a straightforward language where you know what's going to happen at any given moment. It's not good for everyone (and -thing), but languages like these have to exist, and they're needed for good reasons.
      - pie_flavor 4y ago
        If I call a closure, I know what's going to happen - the closure is going to get called. Unless you are talking about the virtual jump, in which case that ship has sailed because Odin has function pointers. This is an allergic reaction to anything more useful than C, not a real complaint.
- _gabe_ 4y ago
  > the important thing about destructors is that you know where to find them The problem isn't that programmers have trouble finding a destructor. The problem is it's not apparent looking at any snippet of C++ code which objects have destructors running additional cleanup logic or other extra code without looking up each class declaration and verifying. I believe Odin is trying to solve this by forcing the programmer to make this code explicit, but reduce the number of footguns by allowing the programmer to keep the initialization and free close to each other.
  - Rusky 4y ago
    But this just shifts the problem. Now it's not apparent looking at any snippet of Odin code which objects should have cleanup logic but don't, without looking up each type and reading its documentation.

Rusky 4y ago

It's had those extra connotations from the start- the whole reason to tie allocation to initialization is so that you can also tie deallocation to destruction, making it automatic and thus less error-prone. "RAII" is mostly just a confusing name for "destructors."

syrrim 4y ago

In C you have a system of memory allocation tied to scoping. A statement like "int x[10];" allocates memory such that when x goes out of scope, the memory is deallocated. RAII generalizes the concept so that when the variable comes in scope, some initializer function is called, and when it goes out of scope some destructor is called. This allows us to use it for dynamic arrays (unlike VLAs in C), hash tables, etc. We can replicate the system by simply calling the initializer when the var comes in scope, and the destructor when it goes out of scope. However, this creates the problem that the two statements are far apart from one another, and thus there is a chance that they might grow out of sync as the code changes. Defer allows us to cause some action to occur when the variable goes out of scope, but declare this at the site where we perform initialization, thus grouping the two together and making it easier to modify them in tandem.

pie_flavor 4y ago

As with most C++ terms, it means something completely perpendicular to what it implies. In general it means that deterministic destructors release a resource at the moment the value representing it goes out of scope, e.g. deallocating memory or closing a file handle. IMO Odin is very wrong on this point: the important thing about destructors is that you know where to find them, so e.g. you can have closures that know how to free their captures when they are freed. There's nothing like that for Odin.

unsafecast 4y ago
Odin doesn't even have closures, or any feature that requires this kind of RAII. The whole point here is that the language doesn't deallocate for you.
- pie_flavor 4y ago
  I know. You say that like it's a good thing.
  - unsafecast 4y ago
    There's value in having a straightforward language where you know what's going to happen at any given moment. It's not good for everyone (and -thing), but languages like these have to exist, and they're needed for good reasons.
    - pie_flavor 4y ago
      If I call a closure, I know what's going to happen - the closure is going to get called. Unless you are talking about the virtual jump, in which case that ship has sailed because Odin has function pointers. This is an allergic reaction to anything more useful than C, not a real complaint.
_gabe_ 4y ago
> the important thing about destructors is that you know where to find them The problem isn't that programmers have trouble finding a destructor. The problem is it's not apparent looking at any snippet of C++ code which objects have destructors running additional cleanup logic or other extra code without looking up each class declaration and verifying. I believe Odin is trying to solve this by forcing the programmer to make this code explicit, but reduce the number of footguns by allowing the programmer to keep the initialization and free close to each other.
- Rusky 4y ago
  But this just shifts the problem. Now it's not apparent looking at any snippet of Odin code which objects should have cleanup logic but don't, without looking up each type and reading its documentation.