MatDialog open method R generic is too loose

[jelbourn]

Because the R generic on MatDialog.open isn't constrained by arguments to the function, it's effectively always any. We should remove the method generic and change the return generic to {}, which will force people to explicitly state which type it is when consuming it.

[crisbeto]

The reason R defaults to any was to avoid breaking changes at the time we introduced the argument.

[rkirov]

The issue is not with 'any', but with allowing R to be unsafely inferred to be anything. For example, the following always compiles.

let ref: MatDialogRef<T, SomeMadeUpType> = open(...);

It looks like any other code where the function call returned some type, but the developer choose to write it out for clarity.

By forcing the developer to write let ref = open(...) as MatDialogRef<T, SomeMadeUpType>; it becomes clear that this is an unsafe cast.

[JWess]

It would be nice if the type of R could be inferred from the type of Component being passed into open().

[aceArt-GmbH]

The only type safe thing would be if the dialog and it's return value would be passed around.
Currently the dialog caller has to declare some return value and some input variables and the dialog does the same thing in reverse (declaring input types and having output variables)

[Samuel-Therrien-Beslogic]

Whilst I'm not entirely certain if the best default should be unknown, {} or void. I did notice that as well and since then I am using patch-package to replace in node_modules/@angular/material/dialog/index.d.ts

-export declare class MatDialogRef<T, R = any> {
+export declare class MatDialogRef<T, R = void> {

[aceArt-GmbH]

Also check out a proposed workaround for a similar type issue #24538 (comment).
Maybe it can be made official and fix both issues at once?