It is not unnecessary. It is by design - https://golang.org/doc/faq#unused_variables_and_imports.

The presence of an unused variable may indicate a bug, while unused imports just slow down compilation, an effect that can become substantial as a program accumulates code and programmers over time. For these reasons, Go refuses to compile programs with unused variables or imports, trading short-term convenience for long-term build speed and program clarity.

I think OP's point is that fmt is used in the program, even if it's in a malformed go/defer expression.

Smaller reproducer:

package main

import "fmt"

func main() {
        defer func() {
                _ = fmt.Print
        }
}

Perhaps this is by design. I don't know how far are invalid expressions typechecked. /cc @griesemer @mdempsky

I agree that the compiler could do better in this case; there's really just one error here (the deferred function must be invoked). go/types avoids the unused fmt error. This should probably be fixed.

The compiler is also not consistent. For instance, in this case

package main

func main() {
	var i int
        defer func() {}
}

we have the opposite situation; i is indeed not used, but there's no error. (Interestingly go/types also doesn't complain in this case; I will file a separate bug for that).

@griesemer I think the case in your comment is acceptable.
After all, "deferred function not called" is a more serious error than "a variable not used".

The root cause for the current behavior is that the check that the defer expression is a function call happens at parse time; and if there are parse errors the compiler stops (and doesn't bother type-checking the code).

In this case it may make sense to move that test to later (out of the parser) for a couple of reasons: 1) it is quite common to make the mistake of forgetting to call the deferred function; and 2) the syntax actually doesn't state that the expression must be a function call, that restriction in made in prose. As a general (but not hard and fast) rule for the parser, syntactic restrictions that are in prose are handled outside the parser.

Change https://golang.org/cl/94155 mentions this issue: cmd/compile/internal/syntax: more tolerant handling of missing function invocation in go/defer

Change https://golang.org/cl/94156 mentions this issue: cmd/compile/internal/syntax: more tolerant handling of missing function invocation in go/defer