Skip to content

Null conditional operators for coalescing, assignment and member access #223

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 7 commits into from
Feb 19, 2020
Merged

Null conditional operators for coalescing, assignment and member access #223

Changes from 1 commit
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
c4cb77d
Null conditional operators for coalescing, assignment and member access
adityapatwardhan Aug 26, 2019
8449c4b
Update 1-Draft/RFCNNN-Null-conditional-operators.md
adityapatwardhan Aug 27, 2019
6dfa2c3
Address feedback and move member access operators to additional consi…
adityapatwardhan Sep 27, 2019
e41f35b
Add operator precedence change
adityapatwardhan Oct 11, 2019
7a8f5f7
Fix typo in operator precedence example
adityapatwardhan Oct 15, 2019
c5eb257
Move null member access for specification section
adityapatwardhan Feb 7, 2020
177eaa2
Prepare RFC0051 (null conditional operators) for merging as Final
joeyaiello Feb 19, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
74 changes: 37 additions & 37 deletions 1-Draft/RFCNNN-Null-conditional-operators.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -81,43 +81,6 @@ The `??` operator checks the left hand side to be null or undefined and returns

If the module `Pester` is not installed, then install the module.

### Updates to operator precedence

The operator precedence token flags will be updated to add gaps and place the null coalesce opeator at position 7, above comparison and below add/subtract.
Currently, the binary operator mask is set at `0x07`, which will be updated to `0x0f`.
This will ensure that `??` is evaluated before operators like `-eq`, `-and`, `-bor` etc, but after `+` and `-`.

This enables scenarios like:
```PowerShell
'x' -eq $null ?? 'x' evaluates to 'x' -eq ($null ?? 'x')

2 + $null ?? 3 evaluates to (2 + $null) ?? 3
```

### Additional considerations

The `??=` and `??` operators are binary operators and check for the value of the left hand side to be null or an undefined variable.
They can be used with a space between the variable name and the to operator.
If the left hand side is null, then `??=` assigns the right hand side to the variable while, the `??` operator returns the right hand side.
When they are used without a space between variable name and the operator, a `{}` must be used around the variable name.

## Alternate Proposals and Considerations

### Disallow `?` in variable names

It was considered to disallow `?` in variable names, to avoid confusion whether the operator is a null conditional operator or the variable name has `?` in it.
This proposal was rejected to maintain backward compatibility.

### Prefer new operators when tokenizing variable names

It was considered to look ahead when tokenizing the variable names and check for `??=`, `??`, `?.` or `?[]`.
If the token is found the assume that it is a null conditional check and not a member access of a variable name ending in `?`.
To maintain backward compatibility and this proposal was rejected.

### Use a different sigil for null-conditional operators

It was determined that the familiarity of `?.` and `??` operators to `C#` programmers will make usage of the new operators easier to understand than introducing new sigils.

### Null conditional member access operators - `?.` and `?[]`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Moved it to the "specification" section.


Null member access operators can used on scalar types and array types.
Expand Down Expand Up @@ -153,3 +116,40 @@ The `?.` and `?[]` operators are member access operators and do not allow a spac
PowerShell allows `?` as part of the variable name.
Hence disambiguation is required when the operators are used without a space between the variable name and the operator.
To disambiguate, the variables must use `{}` around the variable name like: `${x?}?.propertyName` or `${y}?[0]`.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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. 😕

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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"?)

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 }

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

@vexx32 vexx32 Sep 30, 2019 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

-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.

Copy link
Contributor

@KirkMunro KirkMunro Sep 30, 2019 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.


### Updates to operator precedence

The operator precedence token flags will be updated to add gaps and place the null coalesce opeator at position 7, above comparison and below add/subtract.
Currently, the binary operator mask is set at `0x07`, which will be updated to `0x0f`.
This will ensure that `??` is evaluated before operators like `-eq`, `-and`, `-bor` etc, but after `+` and `-`.

This enables scenarios like:
```PowerShell
'x' -eq $null ?? 'x' evaluates to 'x' -eq ($null ?? 'x')

2 + $null ?? 3 evaluates to (2 + $null) ?? 3
```

### Additional considerations

The `??=` and `??` operators are binary operators and check for the value of the left hand side to be null or an undefined variable.
They can be used with a space between the variable name and the to operator.
If the left hand side is null, then `??=` assigns the right hand side to the variable while, the `??` operator returns the right hand side.
When they are used without a space between variable name and the operator, a `{}` must be used around the variable name.

## Alternate Proposals and Considerations

### Disallow `?` in variable names

It was considered to disallow `?` in variable names, to avoid confusion whether the operator is a null conditional operator or the variable name has `?` in it.
This proposal was rejected to maintain backward compatibility.

### Prefer new operators when tokenizing variable names

It was considered to look ahead when tokenizing the variable names and check for `??=`, `??`, `?.` or `?[]`.
If the token is found the assume that it is a null conditional check and not a member access of a variable name ending in `?`.
To maintain backward compatibility and this proposal was rejected.

### Use a different sigil for null-conditional operators

It was determined that the familiarity of `?.` and `??` operators to `C#` programmers will make usage of the new operators easier to understand than introducing new sigils
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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