Allow custom type names (e.g. `[PSTypeName('Custom.Type.Name')]`) to be used on the right-hand side of the `-is` and `-isnot` operators

[KirkMunro]

Summary of the new feature/enhancement

As a PowerShell scripter who uses named custom types often I want to be able to use the -is and -isnot operators to determine if something is of a custom type so that I can always check for types the same way in PowerShell.

Proposed technical implementation details (optional)

The issue here is simple: if you create a custom, named type, and you want to check if an object is that custom, named type, you need to perform that check differently than how you check for any other type.

For example, consider this:

$o = [pscustomobject]@{
    PSTypeName = 'Dr.Seuss'
    OneFish = 'Two fishes'
    RedFish = 'Blue fishes'
}
function Test-DrSeuss {
    [CmdletBinding()]
    param(
        [Parameter(Mandatory, ValueFromPipeline)]
        [PSTypeName('Dr.Seuss')]
        $InputObject
    )
    process {
        'Horton heard you!'
    }
}
$o | Test-DrSeuss
$o -is [PSTypeName('Dr.Seuss')]

When you hit enter on the last line, the PowerShell parser will be waiting for more input because it recognizes [PSTypeName('Dr.Seuss')] as an attribute, and it's looking for either a string or a type name.

I would like to change this so that I can use -is (and Should -BeOfType in Pester, which uses -is internally) to check if an object is a custom object with a specific type name.

The workaround is to check the object's PSTypeNames property to see if it contains the type name, but since we can identify types on property input in cmdlets using the PSTypeName attribute, it would be more consistent if we could do the same with the -is and -isnot operators.

[KirkMunro]

Related: https://github.com/pester/Pester/issues/1315.

[vexx32]

Hmm. Honestly, I think we should be able to just do this with -is 'Dr.Seuss'; complicating the parsing by introducing the attribute doesn't feel like something we should need to do?

That would mean Pester may need to adjust how it does -BeOfType to accommodate it in the same way, but I don't think we should have an overly complex syntax for it either way.

[fflaten]

3 years later, status?

String vs attribute? Both? String is cleaner, but no way to identify type name from real class (use cases?)? Also inconsistency with parameter-attribute.

Accepted extension for -is by WG and/or team and just waiting for PR?

[JamesWTruher]

The WG doesn't believe that this has too much value if only applied to the is and isnot operators. Also, we would be concerned with actual dotnet namespace collisions which would be breaking. We do see that a more fleshed out enhancement to ETS would be generally useful, but this is too specific.

[ghost]

This issue has been marked as declined and has not had any activity for 1 day. It has been closed for housekeeping purposes.