6 ms·

That has both of the problems I mentioned even if it isn't a full language level construct.

• pjmlp 10y ago
  I fail to see how. The resources are only available via the lambda parameters, so the wrapper function controls the lifetime, arena style. Last expression in the block is the return value.
  • dbaupp 10y ago
    The wrapper function controlling the lifetime is exactly why that scheme has both of the problems I mentioned. It all comes down to: how do you write a fn connection() -> DB? You can't (or, at least, it doesn't make sense to) return the parameter from withDBConnection: the whole point is the wrapper function does the clean-up when it is done, invalidating the connection object. The only way to pass the value along is to have `connection` also take a closure, i.e. manual continuation passing style/node.js's "closure-hell". This can, in some cases, be addressed with async/await style sugar, but there's still semantic (mainly around composition) and performance issues with it. Anyways, going back to the data type: if one has a type Foo with a constructor like fn create() -> Foo, and Foo is updated to contain a database connection, that constructor no longer works, and needs to also be converted to use CPS. That is, the interface of the Foo object has be infected by "private" details, meaning needs to to preemptively decide whether there is any chance of each datatype needing to hold one of these CPS objects. (Of course, the code you suggest works fine in Rust now, and is even used for certain special cases, but that is very different to baking it into the language as a whole new syntactic construct.)