I should also note that deadcode -test ./... is not what I want: sometimes, due to the nature of refactors, an exported function in an internal package suddenly becomes unreachable - but it is still tested in its own package. I still want to be told about those cases even if I run the tool in "library mode".

We could define an -exported flag that added all public symbols from non-internal packages of the initial module to the analysis' set of reachable functions. But what can we conclude about func and interface values among the parameters to those functions? Consider func F(p I) where I is an interface type: a call to a method p.m() might not reach any callees because there are no live types that implement I, even though there would be in a real program. I worry that the results could be quite confusing.

I should also note that deadcode -test ./... is not what I want: sometimes, due to the nature of refactors, an exported function in an internal package suddenly becomes unreachable - but it is still tested in its own package. I still want to be told about those cases even if I run the tool in "library mode".

I'm confused: if it is still tested in its own package, wouldn't this be included in -test ./...?

But what can we conclude about func and interface values among the parameters to those functions?

I'm not sure. I'd be fine with this mode having documented caveats if there's no good way to deal with those situations. Would there be a way to skew towards being conservative in cases like this, leaning towards false negatives rather than false positives?

I'm confused: if it is still tested in its own package, wouldn't this be included in -test ./...?

My understanding and limited experience with the tool is that deadcode -test ./... will never warn about an exported function if it is called from any test function. In any case, all I meant to say is that I thought about using deadcode -test ./... for my libraries but it's not a good approximation of what I want to accomplish here.

But what can we conclude about func and interface values among the parameters to those functions?

I'm not sure. I'd be fine with this mode having documented caveats if there's no good way to deal with those situations. Would there be a way to skew towards being conservative in cases like this, leaning towards false negatives rather than false positives?

Let's define the terms to ensure we're on the same page: in this context "conservative" means silent and a "positive" is an "unreachable" diagnostic.

I think you're asking for the -exported flag to treat all implementations of I as reachable. It could do that, but I think it would seriously degrade precision.

My understanding and limited experience with the tool is that deadcode -test ./... will never warn about an exported function if it is called from any test function.

That's correct.

In any case, all I meant to say is that I thought about using deadcode -test ./... for my libraries but it's not a good approximation of what I want to accomplish here.

Obviously the tool can't safely report a function as dead if it's needed by a test. Are you saying that -test generates unwanted "coverage", and that you want to know which functions are unreachable from the exported API, ignoring tests?

I might still argue that the tool is pointing to a gap in your test suite (though pragmatically I get that a broad shallow API doesn't always need exhaustive test coverage).

Let's define the terms to ensure we're on the same page: in this context "conservative" means silent and a "positive" is an "unreachable" diagnostic.

Correct.

I think you're asking for the -exported flag to treat all implementations of I as reachable. It could do that, but I think it would seriously degrade precision.

Fair enough. I personally wouldn't mind false positives (unreachable diagnostics where I can't remove a declaration without breaking users) assuming they would be relatively rare. I think they should be relatively rare, because the types implementing a public interface are usually also public themselves.

Are you saying that -test generates unwanted "coverage", and that you want to know which functions are unreachable from the exported API, ignoring tests?

I worry that my bringing up of -test is derailing the thread a bit :) As a library author, I want to know what code I can delete without breaking my main packages or changing the API as shown by go doc or pkg.go.dev (excluding internal packages). Whether or not I have done a good job at covering my public APIs with tests should not matter in this analysis, which is why I was trying to say I've discarded using -test in any way for my purpose here.

One tangential thought is that runnable examples could matter in this -exported mode, because they are rendered as part of the documentation, so they are part of the contract between the library author and the library user in terms of what is supported and meant to continue working in the future. If runnable examples are reachable with -exported, but not tests, then perhaps the way to resolve false positives with interfaces would be to write one more example which reaches those implementation types.

We could define an -exported flag that added all public symbols from non-internal packages of the initial module to the analysis' set of reachable functions. But what can we conclude about func and interface values among the parameters to those functions? Consider func F(p I) where I is an interface type: a call to a method p.m() might not reach any callees because there are no live types that implement I, even though there would be in a real program. I worry that the results could be quite confusing.

@adonovan What if we additionally add all types reachable from exported types in the transitive reachable packages as live. Would we still have an example that could end up confusing? In particular for the tool to report some F as dead in one set of packages, but not in another? It may be a lack of imagination, but I am struggling to come up with such an example.

(TypeParams seem horrible without a whole program though.)