_content/blog/inliner.md: credit Lasse

Change-Id: I38f8d1f9cbf795780f013e909e3a2bdd0db4ec65
Reviewed-on: https://go-review.googlesource.com/c/website/+/754360
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Auto-Submit: Alan Donovan <adonovan@google.com>

1 files changed, 1 insertions, 1 deletions

diff --git a/_content/blog/inliner.md b/_content/blog/inliner.md
index 072050e3..7aa54ec8 100644
--- a/_content/blog/inliner.md
+++ b/_content/blog/inliner.md
@@ -437,7 +437,7 @@ If you invoke the inliner in gopls, you’ll see that it makes the change shown
 ### An optimizing compiler for “tidiness”
 
 We’ve now seen half a dozen examples of how the inliner handles tricky semantic edge cases correctly.
-(Many thanks to Rob Findley, Jonathan Amsterdam, and Olena Synenka for insights, discussions, reviews, features, and fixes.)
+(Many thanks to Rob Findley, Jonathan Amsterdam, Olena Synenka, and Lasse Folger for insights, discussions, reviews, features, and fixes.)
 By putting all of the smarts into the inliner, users can simply apply an “Inline call” refactoring in their IDE or add a `//go:fix inline` directive to their own functions and be confident that the resulting code transformations can be applied with only the most cursory review.
 
 Although we have made good progress toward that goal, we have not yet fully attained it, and it is likely that we never will. Consider a compiler. A sound compiler produces correct output for any input and never miscompiles your code; this is the fundamental expectation that every user should have of their compiler. An *optimizing* compiler produces code carefully chosen for speed without compromising on safety. Similarly, an inliner is a bit like an optimizing compiler whose goal is not speed but *tidiness*: inlining a call must never change the behavior of your program, and ideally it produces code that is maximally neat and tidy. Unfortunately, an optimizing compiler is [provably](https://en.wikipedia.org/wiki/Rice%27s_theorem) never done: showing that two different programs are equivalent is an undecidable problem, and there will always be improvements that an expert knows are safe but the compiler cannot prove. So too with the inliner: there will always be cases where the inliner’s output is too fussy or otherwise stylistically inferior to that of a human expert, and there will always be more “tidiness optimizations” to add.