Rule Idea: Pipeline Type Checking against Output

[JustinGrote]

This is just a spitball idea to contribute feedback if it is maybe feasible, I might consider attempting a PR

Problem

Often when writing a pipeline you may pipe an incompatible type, and you won't find out until runtime.

Proposed solution

If the output type of a function can be explicitly determined by:

1. Use the .OUTPUT comment based help section to define the output type of a function
2. Take all explicit return keywords that explicitly cast to a type e.g. return [MyType]@{} or can be simply derived from a typed variable e.g. $f = [MyType]::new();return $f

And the function being called either to or from meets the following criteria:

1. Has strictly typed non-primitive parameter or ValueFromPipeline

Then we should be able to safely issue a warning or error stating something like "MyFunction expected [MyType] but is receiving [WrongType] via the pipeline" as a static analysis.

#Issues

1. Easily castable types like string we have to exclude, they will basically always match
2. Probably should support/detect explicit casts or interfaces

Prior Art

How JSDoc can be used to test for type safety in normally-untyped javascript.

[bergmeister]

This will be very challenging to implement and not able to analyse most cases due to the need to determine the output type. PSSA just parses the AST so if the function's output that is being piped is not defined in the file being analyzed, then how would PSSA know? In some rules, PSSA makes Get-Command calls to get information about cmdlets available on the system, this is a very expensive operation though and would require the cmdlet to be either already properly installed or loaded into memory already. Therefore only with the last suggestion, would PSSA be able to determine the output type in some cases.
Powershell is dynamic by design and therefore analysis is limited as it is not strongly typed and compiled like C#. I feel like the effort might be not in relation to the value here, given that the rule won't be able to analyse many cases due to lack of information.

[JustinGrote]

Appreciate the feedback, and I'm aware of this aspect, hence why I was trying to limit the scope. Analysis across multiple files is an issue as mentioned, and the goal wouldn't be for it to be foolproof, it would only be in the specific circumstances where it could make the reasonable assertion, basically to catch obvious mistakes during write-time rather than run-time.

[kilasuit]

@JustinGrote - Output Type can also be defined as an attribute of the function/cmdlet as per this doc and I had suggested (& wanted to work on adding functionality into the core engine) via this Issue