(uhm, nevermind that I didn't actually internalize the supposed syntax enough. Should be "step with: a", I guess?)
On Sun, Mar 1, 2020 at 11:13 PM Axel Wagner <axel.wagner...@googlemail.com> wrote: > 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/CAEkBMfFxaH4rgjbDT5MXfOVoKKazyXOpjmS6gj_PuQ35mQ7xXg%40mail.gmail.com.
