Null conditional operators for coalescing, assignment and member access

[adityapatwardhan]

The concept has been discussed in issue PowerShell/PowerShell#3240

[vexx32]

Reading between the lines for the alternate proposal comments, it seems like the final decision is to always consider ? as part of the variable name?

I think that's probably going to make for less usage of these operators in general, given that any use of them is going to complicate syntax an additional level here... What is the reason for rejecting the proposal to preferentially tokenize ? as an operator token? It would simplify syntax in the vast majority of cases, and only require awkward syntax when an already awkward name is in use.

[KirkMunro]

Me reading between the lines: I think there is concern that if ? is in use in variable names, and if the suspicion that users who use such names are not advanced users is accurate, preferential tokenizing of an operator like ?. could be very, very confusing to those users. Data needs to be gathered though to really assess that impact.

[vexx32]

Hmm, yeah I guess I can see that, potentially. That's one of the reasons I'm in favour of ? simply being removed as a standard variable name character, but that has its own problems.

Really, it seems like every solution here is kind of problematic in its own way, but I feel that the solution currently preferred by this RFC is the most problematic, because it creates a pattern for requiring more complex syntax that may be permanent. A one-time break is one thing, but requiring more complicated syntax in (probably) every future version of PowerShell seems like a worse change to me. 😕

[SeeminglyScience]

but I feel that the solution currently preferred by this RFC is the most problematic, because it creates a pattern for requiring more complex syntax that may be permanent.

Agreed. I think that loses all familiarity that the syntax of ?. would buy. No one is going to think to try that, most don't even know about the ${} syntax in the first place. I'd personally rather see that aspect of this RFC tabled until a suitable syntax is found.

[majst32]

Very confused by this statement: If the left hand side is null then return the right hand side, else return the right hand side. (Wouldn't that mean "always return the right-hand side"?)

[essentialexch]

Lots of operators: -match, -replace, -contains, -split, -join, -as, -is, -isnot, -f, +=, -=, *+, /=, ++, --, etc. etc. The arithmetic operators very C-family based; the others - not so much. Some supporting very odd syntax already (I'm looking at replace and join as I write that).

If someone is willing to looking at something more verbose, then something like:

$varThatMayBeNull -isNull $FallBackValue

seems fairly obvious. Similarly,

$varThatMayHaveNullProperty -isPropertyNull $PropertyName, $FallBackValue

also seems fairly obvious (with something shorter -ispropnull also reasonably verbose).

I currently handle the first with an infix if statement, e.g.:

if( $varThatMayBeNull ) { $varThatMayBeNull } else { $FallBackValue }

The second is more complex, which I would love to replace:

function SafeGetProp
{
    Param
    (
        [Object] $obj,
        [String] $propName
    )

    ## $prop = if( Get-Member -Name $propName -InputObject $obj -MemberType Property ) { $obj.$propName } else { $null }
    ## faster:
    $prop = &{ Set-StrictMode -Off; $obj.$propName }
    $prop
}

$prop = SafeGetProp $varThatMayHaveNullProperty $propertyName
if( $null -eq $prop ) { $prop = $FallBackValue }

[vexx32]

-isNull sounds like it's expected to return a boolean value; I'd probably avoid that.

[essentialexch]

-isValueNull. It's flexible. :-) I'm throwing something out there that feels more like PowerShell to me. And is actually readable by average humans.

[vexx32]

-is<anything> sounds like it's expected to give a boolean result. For example: -isNull $null I would expect to get $true, and I don't think that'd be a particularly uncommon pitfall of logic. 🙂

But I think that is more in the right direction, yeah. I rather like $value -else $fallback just because it kind of has the right feel to it (still far from perfect, but I don't think that we'll find a 'perfect' solution, really), and also because it can tie in with $bool -then $trueValue -else $falseValue -- though it's perfectly possible that may not be desirable.

[KirkMunro]

@SteveL-MSFT To respond to your question asking if anyone has other syntax suggestions that wouldn't result in breaking changes, I was tinkering a little today, and wondered what if we look at ! as a postfix operator that is similar to the dot-reference operator, but only evaluating the right-hand side if the left-hand side is not null?

As far as I can tell, these are non-breaking changes:

# This references the Length member, but only if $x -ne $null
# (no . required, since there's already one at the bottom of the !, but
# we could use !. here if we really felt it was necessary)
$x!Length

# This references the item at index 2, but only if $x -ne $null
$x![2]

That would be non-breaking. I also like the visual relationship between the dot-reference operator (.) and the non-null dot-reference operator (!). The actual operators here would be ! and ![].

When comparing this with the other C# operators (ternary, null-coalescing, etc.), there's no conflict in thought and they are all explainable:

• ?: is used for shorthand conditionals (logical expressions)
• ?? and ??= both show that ?? is used to invoke an expression if a value is null
• ! is used to invoke a member or to retrieve a collection item if a value is not null.

There is one overlap with C#, which has what is referred to in online discussions as the damnit operator (a postfix !), but that's used by the compiler to ignore when a nullable reference type may be null. Since we're interpreted and not compiled, I don't see an issue there.

Also just to make it clear, I prefer sticking with the ?. and ?[] syntax that is already used in C#. But with the committee resisting that breaking change, and since you requested other syntax suggestions, I wanted to share one.

[adityapatwardhan]

?= has been changed to ??= to align with newly introduced C# operator ??= defined here: docs

[JamesWTruher]

looking for a number of more examples

[JamesWTruher]

what is $? under these cases? Is it always true?
What happens with type declarations? ex: [int]$x ??= 'string'

[JamesWTruher]

should probably add an explanatory note about the variable name being x? as is possible today, we're not adding nullable variables with this syntax.

[JamesWTruher]

another example?
$x = $x ??= 5
if $x is null before execution, the value of $x will be 5
if $x is not null before execution, the value of $x will be unchanged

[vexx32]

🤔 wouldn't that leave $x as $null, since $x ??= 5 has no output to pass back to $x in the final assignment? Or is the precedence the same as = and all assignments are "simultaneous" just like $a = $b = 2 ?

[rjmholt]

I'd expect right-to-left execution, so $x = ($x ??= 5). That's what the compiler does currently for all assignment.

So you can do this:

$x = @(1)
$w = $z, y = $x += 2,3

[JamesWTruher]

I'd like to see a lot more examples (likely a bunch of your tests) which really poke the precedence and results.

if ( $x ??= 5 )
if ( $x = $x ??= 5 )
if ( $x ??= $null )
for($x ??= 4; $x -lt 6; $x++)

etc.

[Halkcyon]

@chuanjiao10 It's a programming/scripting language. The language already isn't catered to beginners and aims for the median. If you do not like it, you can write style guides for your peers that bans its use.

[kborowinski]

Should state "can be used" instead of "can used"

[daxian-dbw]

This should not be put in the alternate proposal section. The null-conditional operator should be put in a separate RFC given that it's a experimental feature.

[adityapatwardhan]

Moved it to the "specification" section.

[ExE-Boss]

The ?. and ?? operators have been added to ECMAScript as well.

[Halkcyon]

@ExE-Boss which likely took inspiration from C# considering that syntax and feature existed 5-10 years prior.