On Sun, Mar 1, 2020 at 3:17 PM Warren Stephens <wsteph...@prognoshealth.com> wrote:
> 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. > This seems to contradict how you described the suggestion above. Specifically, you wrote mystep2 with: lines, thing2 // <---------- hide all local variables from above except for lines and thing2 I think this actually does have the potential to change the behavior of code. For example, consider this code: a, e := F() x := &e //with a: b, e := G() y := &e fmt.Println(x == y) Inserting the `with` statement, AIUI, would change the output of this program from "true", to "false". Because before the change, the short assignment did not declare a new `e`, but after the change, `e` is made invisible to the code after, so a new variable (with a different address) is declared. Now, this is a toy example. But note that this particular semantic change is very subtle and unlikely to be caught in code review (especially if, as you suggest, people start just approving pull requests that only add `with` statements). And while I personally don't often have problems with the short assignment operator (not) shadowing things, note that it is a very common pitfall mentioned by newcomers to the language. The reason I'm mentioning it, is that this property *also* means that the transformation between `with` and destructuring into `func`s is very straight-forward. So, if you are fine with this problem, I really don't understand why you are afraid that splitting one function into three would somehow break - it does exactly the same thing, after all. > 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 > <https://groups.google.com/d/msgid/golang-nuts/9aff05ef-1c37-4626-a18d-0df418d2d258%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAEkBMfHsmCDkgifyLoa8rHwsUSPcifcVD1%3Dd6MvO%3DAGKcyACew%40mail.gmail.com.
