I picked up a Scala “want” from this video: https://www.youtube.com/watch?v=QM1iUe6IofM
In it, he talks about being able to write an in-place function which is blind to (blocked from) all the scope context surrounding it, only allowing the function to operate on whatever is passed within its parameter list(s). Apparently, this doesn’t exist in any current language, which I found fairly amazing.
My own context for wanting this is, I ran into a pernicious bug in my own code where, due to the nature of the self-relation, I needed to selectively reverse this and that within a method to vastly reduce the search space, mapping them to left and right. And when refactoring for the change, I missed a single implied preceding “this” on a method (where it needed to now be “left.”). Not knowing about the miss, the undesired effect was it produced a quizzical and unexpected combinatorial explosion on the resulting use. After many hours of head scratching, I finally lifted the entire method out to a completely new empty “object”. And then the method immediately popped out as unresolved.
So, given this idea of having a function definition cancel all scope assumptions and only rely on its passed parameters would have easily caught this. And, such a function definition also has the refactoring bonus of encouraging a “referentially pure function” which might grow to be something larger and more useful as the context within which it was produced continues to expand and grow.
Given complexity of all the many things being “injected” into a function in Scala, having something reverse the assumptions would be very valueable to me. Additionally, there could be a refactoring idea where this kind of function could be produced from an existing inline def with a “force all parameters explicitly” which would then produce a pure referential function where everything upon which it depends can be seen in the parameter list. It would be a nice mechanism for those of us who have to do maintenance following other advanced coders to see what kinds of dependencies with which we are working. This is like the “implicit” problem, writ large.