2 ms·

While I agree that destructors are unsuitable for C, that’s because for them to be useful you’d have to throw out and redo the entire standard library, so they

While I agree that destructors are unsuitable for C, that’s because for them to be useful you’d have to throw out and redo the entire standard library, so they can’t be usefully retrofit in the language, however > they are much too inflexible because they bind 'behaviour' to types 1. that is the baseline you want, data is not an amorphous and meaningless blob, the default for a file or connection is that you close it, the default for allocated memory is to release it, etc… 2. that also allows much more easily composing such types and semantics, without having to do so by hand 3. and is much more resilient to future evolution, if an item goes from not having a destructor to having one… you probably don’t care, but if it goes from not having a cleanup function (or having a no-op one which you could get away with forgetting to call) to having a non-trivial cleanup function you now have a bug lurking 4. destructors also make conditional cleanups… just work, the repetitive and fiddly mess is handled by the computer, which is kind of the point of computers, rather than having to remember every time that you need to clean the resource on the error path but not on the non-error path, defers easily trigger double-free situations; this also, again, make code more resilient to future evolutions (and associated mistakes) 5. furthermore destructors trivially allow emulating defers, just create a type which does nothing and calls a hook on drop > Data should be 'stupid' and not come with its own hardwired behaviour That’s certainly a great take if you want the job security of having to fix security issues forever.

flohofwoe 4y ago
> ...the default for a file or connection is that you close it... Something like a file or connection is already not just 'plain old data' though. In my mind, 'data' are the pixels in a texture (while the texture itself is an 'object'), or the vertices and indices in a 3D mesh (while the 'mesh' is an object), or the data that's read from or written to files (but not the 'file object' itself). C is all about data manipulation (the 'pixels', 'vertices' and 'indices'), less about managing 'objects'. For objects, constructors and destructors may be useful, but there are plenty cases in C++ where they are not (textures and meshes in a 3D API are actually a good example for where destructors are quite useless, because when the 'owner' of the CPU side texture object is done with the object doesn't mean that the GPU is done with the data that's 'owned' by the CPU side object - traditional destructors can be used of course by delaying the destruction on the CPU side texture object until the GPU is done with the data, but why keep the texture object around when only the pixel data is needed by the GPU, not the actual texture object? A 'defer mechanism' is just the right sweet spot for a C like language IMHO.
- masklinn 4y ago
  > Something like a file or connection is already not just 'plain old data' though. OK? But now you need to… have two different mechanisms, when one can do both? > In my mind, 'data' are the pixels in a texture (while the texture itself is an 'object'), or the vertices and indices in a 3D mesh (while the 'mesh' is an object), or the data that's read from or written to files (but not the 'file object' itself). This “data” does not have a destructor, and thus is not a concern. > C is all about data manipulation (the 'pixels', 'vertices' and 'indices'), less about managing 'objects'. I think that would be news to every C program I’ve written. > there are plenty cases in C++ where they are not In which case you can just not have them, and not care. > A 'defer mechanism' is just the right sweet spot for a C like language IMHO. If by “a C like language” you mean “a language refuses to take any complexity off of the user’s back” then sure.

flohofwoe 4y ago

> ...the default for a file or connection is that you close it... Something like a file or connection is already not just 'plain old data' though. In my mind, 'data' are the pixels in a texture (while the texture itself is an 'object'), or the vertices and indices in a 3D mesh (while the 'mesh' is an object), or the data that's read from or written to files (but not the 'file object' itself). C is all about data manipulation (the 'pixels', 'vertices' and 'indices'), less about managing 'objects'. For objects, constructors and destructors may be useful, but there are plenty cases in C++ where they are not (textures and meshes in a 3D API are actually a good example for where destructors are quite useless, because when the 'owner' of the CPU side texture object is done with the object doesn't mean that the GPU is done with the data that's 'owned' by the CPU side object - traditional destructors can be used of course by delaying the destruction on the CPU side texture object until the GPU is done with the data, but why keep the texture object around when only the pixel data is needed by the GPU, not the actual texture object? A 'defer mechanism' is just the right sweet spot for a C like language IMHO.

masklinn 4y ago
> Something like a file or connection is already not just 'plain old data' though. OK? But now you need to… have two different mechanisms, when one can do both? > In my mind, 'data' are the pixels in a texture (while the texture itself is an 'object'), or the vertices and indices in a 3D mesh (while the 'mesh' is an object), or the data that's read from or written to files (but not the 'file object' itself). This “data” does not have a destructor, and thus is not a concern. > C is all about data manipulation (the 'pixels', 'vertices' and 'indices'), less about managing 'objects'. I think that would be news to every C program I’ve written. > there are plenty cases in C++ where they are not In which case you can just not have them, and not care. > A 'defer mechanism' is just the right sweet spot for a C like language IMHO. If by “a C like language” you mean “a language refuses to take any complexity off of the user’s back” then sure.