Patrick Meinecke

Some better tooling around parameter discovery in general would be nice. I have something in my profile that gives me this output:  Though for something like `Invoke-Command`, that does...

The Engine WG discussed this and agree with the change and it is ready to be reviewed

> Root cause of stack appears to be: > Message : Class not registered (0x80040154 (REGDB_E_CLASSNOTREG)) > Source : System.Private.CoreLib The exception is thrown from a class in corelib, which...

To be clear the issue is *not* about loading `System.Private.CoreLib`. The error posted is saying that the exception is thrown from an API in *the already loaded* assembly. Most exceptions...

> Why can't simple version checks be done and then use that version? Why are you locked into one? Why can't it just automatically use the correct version or at...

One of the conversion paths PowerShell utilizes is trying to pass the conversion subject as the first argument to a constructor of the target type. So while it's definitely surprising,...

> Interesting, so`[char]` is allowed to bind to _any_ numeric parameter, not just `[byte]`. It's more just that `char` > `int` is a valid conversion path. Just like how `string`...

> However, I think the point about the inappropriate array-constructor call in the case at hand is still worth addressing. There's no benefit to the current behavior, and it is...

Ahh okay so there's an existing exclusion in that rule for numeric types that gets circumvented when a non-numeric type could be cast as one. That's sort of the issue...

The Engine WG discussed this and agree that the behavior is confusing, but decided that adding additional hard coded exclusions here is not worth the extra potential confusion and/or breaking...