All, Thanks for the advice, but I should have mentioned that I already know about Test Driven Development.
I live in the real world of commercial software development (>3 decades). Here is the real world scenario: 1. Write some code quick — must stay on schedule, there is actually no time to write tests as all, others are waiting (i.e. no tests) 2. Deploy the code, and manually check that it is doing its job (i.e. no tests) 3. Move on to something else more timely or important (i.e. no tests) 4. Times passes, the code is working (i.e. still no tests) Eventually someone comes along to write tests. And writing tests in Go is much easier if the code is broken up into “testable” pieces. So the developer is in the situation of *refactoring code that is known to be working in order to write tests!* — which are rarely going to be comprehensive anyway. The risk is breaking something that isn’t broken! With my language proposal above, adding the *with statements does not modifying the behavior of the code at all* — it should literally compile exactly the same way. Its main benefit is to enable tests to be more easily written without restructuring the existing code. In my opinion, it would be nice if a developer would never have to restructure code in order to write tests. Tests are quite often written well after the code is in production. That is the real world scenario. Imagine that you are doing a code review on a pull request, and the only thing that has been changed is to add *with* statements and tests -- Zero risk! Approved! Done! -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/9aff05ef-1c37-4626-a18d-0df418d2d258%40googlegroups.com.
