From 5ecca2ca95abf73554912076d0e402e255685611 Mon Sep 17 00:00:00 2001 From: Aleksandr H Date: Mon, 1 Jul 2019 08:52:18 -0400 Subject: [PATCH] Accept suggestion: replace "that point" with "pointing" Co-Authored-By: Lasse Martin Jakobsen --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 2e3c6f4..35a905d 100644 --- a/README.md +++ b/README.md @@ -940,7 +940,7 @@ Again, this is a very standard implementation of a getter function for our store > NOTE: Consider the case where our application uses multiple threads. In this scenario, passing pointers to the same memory location can also potentially result in a race condition. In other words, we aren't only potentially corrupting our data—we could also cause a panic from a data race. -Please keep in mind that there is intrinsically nothing wrong with returning pointers. However, the expanded scope of variables (and the number of owners that point to those variables) is the most important consideration when working with pointers. This is what categorises our previous example as a smelly operation. This is also why common Go constructors are absolutely fine: +Please keep in mind that there is intrinsically nothing wrong with returning pointers. However, the expanded scope of variables (and the number of owners pointing to those variables) is the most important consideration when working with pointers. This is what categorises our previous example as a smelly operation. This is also why common Go constructors are absolutely fine: ```go func AddName(user *User, name string) {