The Next Steps for Single Ownership and RAII

Re:The Next Steps for Single Ownership and RAII by saurik on Thursday July 16, 2020 @10:50PM (#23866476)

The thing this is doing with "named deconstructors" seems to essentially be a form of linear typing, which is already well-modeled; and while the article claims this is "incompatible" with exceptions, I don't think that is true: it only means certain kinds of objects can't be on the stack if an exception were to occur without a "default" deconstructor (similar to a default constructor), but being able to get that scenario as a compile error is actually "cool" (as you can always model exception handling as just an automated expansion of an error propagation monad, at which point the code either would have worked before or it wouldn't have) and so I wouldn't throw the baby out with the bath water so soon.

[ Parent | on HN ]

Re:The Next Steps for Single Ownership and RAII by verdagon on Thursday July 16, 2020 @11:25PM (#23866657)

I'm not familiar with that particular flavor of monads, is that kind of like how Javascript's Promise has a .then() and a .catch()?

Also, someone mentioned yesterday that this is a form of linear typing, since everything must be destructed exactly once. But we would still run into a problem if we did make any objects with no zero-arg destructor...

...except now that I'm typing this out, it occurs to me that we could just use the "Bailing Past Destructors" [1] rule says: hold the error, call the appropriate destructor, and continue returning the error upwards. (Vale would use a Result type, not exceptions)

Wow, the solution was there all along, and I never thought to retrofit it to C++. Perhaps I'll revise the article tonight to take out the mention of exceptions =)

[1] "Vale: The Interesting Parts", https://docs.google.com/document/d/1t0zzW0K9jilbCkuAulZfDlZc... (fair warning, written for language enthusiasts!)

[ Parent | on HN ]