As an intermediate checkpoint for this discussion, it sounds like there are two use cases for DelayedInit:
- “life-cycle management”: capturing user code and allowing custom user-specified code to run before and after (e.g., in specs2 and ScalaTest)
The ScalaTest usage of DelayedInit also nicely explains how to avoid using DelayedInit by putting the code that needs to be intercepted in a method
- “scope management”, which would likely be subsumed by implicit function types or “static scope injection”: implicit function types replace scoping by availability of implicits, which may result in name clashes
Assuming this is an exhaustive summary, I propose we move to accept dropping DelayedInit, if those in favor of dropping it can show a compelling way to implement these two use cases.