3 ms·

I feel it doesn't make sense to conflate resource management with garbage collection. The cleanup actions here are more like releasing a lock, deleting temporar

I feel it doesn't make sense to conflate resource management with garbage collection. The cleanup actions here are more like releasing a lock, deleting temporary files, or closing a connection. This doesn't lead to a lack of safety. These resources already need to deal with these uninitialised states. For example, consider a lock management object. You shouldn't assume you have the lock just because you have a reference to the manager resource. It's totally normal to have objects that require some sort of initialization.

akoboldfrying 1y ago
You seem to be making the argument that the new "using" doesn't create any new, dangerous behaviours. But I already agree with that -- I'm saying that it doesn't make anything better than it was before (a programmer who forgets to write "try" could equally forget to write "using", so the required level of programmer discipline is unchanged), plus, if you mistakenly persuade yourself that it's safe to write "using" everywhere all the time, you can introduce bugs like locks that are released too early. Why might a programmer persuade themselves of that? Because otherwise "using" has no benefit at all, beyond a slightly sweeter syntax for wrapping the function body in "try ... catch (x) { for (o of objs) o.dispose(); }”. > I feel it doesn't make sense to conflate resource management with garbage collection Memory is just a resource, one that conveniently doesn't require anything to be done urgently when that its lifetime ends (unlike, say, locks). GC is a system for managing that resource -- or any resource with the same non-urgency property. For example, you can imagine a GC-based resource management system for a pool of DB connections. > You shouldn't assume you have the lock just because you have a reference to the manager resource. Some languages make it necessary to code in this way, where you need to always check if something is in a valid state before doing something with it, but that's unfortunate, because there are languages (like C++, which is horrible in so many other ways) where you can maintain the invariant that, if you have a reference to a lock, the associated resource is locked. The general idea -- Make Invalid States Unrepresentable -- is a fantastic way to improve code quality, so we should always be looking for ways to incorporate it into languages that don't yet have it. Parse Don't Validate is the same underlying idea.

akoboldfrying 1y ago

You seem to be making the argument that the new "using" doesn't create any new, dangerous behaviours. But I already agree with that -- I'm saying that it doesn't make anything better than it was before (a programmer who forgets to write "try" could equally forget to write "using", so the required level of programmer discipline is unchanged), plus, if you mistakenly persuade yourself that it's safe to write "using" everywhere all the time, you can introduce bugs like locks that are released too early. Why might a programmer persuade themselves of that? Because otherwise "using" has no benefit at all, beyond a slightly sweeter syntax for wrapping the function body in "try ... catch (x) { for (o of objs) o.dispose(); }”. > I feel it doesn't make sense to conflate resource management with garbage collection Memory is just a resource, one that conveniently doesn't require anything to be done urgently when that its lifetime ends (unlike, say, locks). GC is a system for managing that resource -- or any resource with the same non-urgency property. For example, you can imagine a GC-based resource management system for a pool of DB connections. > You shouldn't assume you have the lock just because you have a reference to the manager resource. Some languages make it necessary to code in this way, where you need to always check if something is in a valid state before doing something with it, but that's unfortunate, because there are languages (like C++, which is horrible in so many other ways) where you can maintain the invariant that, if you have a reference to a lock, the associated resource is locked. The general idea -- Make Invalid States Unrepresentable -- is a fantastic way to improve code quality, so we should always be looking for ways to incorporate it into languages that don't yet have it. Parse Don't Validate is the same underlying idea.