Patrick Meinecke

The engine WG discussed this and agree there should be a better solution than the work arounds currently in place in PSES (and other projects). We would like to avoid...

> The example given is not a good one because `path` is a string not an expanded string. `Temp` works better. That's actually part of the problem. `PATH` *can* be...

The Engine WG discussed this yesterday. We agree it would be nice to have as a dynamic parameter for the registry provider. Marking as up for grabs.

I'd like to see this. The biggest potential disconnect is that `~` is configurable, so it's not particularly well suited for a parse time concept: ```powershell PS C:\> (Get-PSProvider FileSystem).Home...

> .Net syntax is not friendly with `~` as part of the path @237dmitry Our `using` statement is not a dotnet concept. We have full control over how it acts....

> Considering that relative paths work like: `using module ..\..\TestModule` I don't see why ~ shouldn't also work. Interestingly, relative paths work differently in `using` statements. They work relative to...

Another option would be something like this: ```powershell switch ($obj) { -is [string] { } -is [int] { } 'but this also works' { } default { } } ```...

Nothing is carved in stone, anything can be changed but is judged on a scale of impact vs effort. Note though, I'm not weighing in on how I think the...

> Although this doesn't parse currently an error, it (afaik) never triggers the type operand and therefore is currently useless (and unlikely breaks anything either). It's not an error, but...

The engine WG discussed this and agrees that it would be useful. An RFC would be required as we could not unanimously agree to the proposal above.