Repository navigation
Decide on which experimental features will remain in experimental in 7.1 #13406
Description
As we did with 7.0 in #11302, we have to make a decision going into RC on whether experimental features are "graduated" to stable vs. staying as experimental.
Per some conversations with the @PowerShell/powershell-committee, this is our current position on each (edited 8/25/20: the below are now the current plan-of-record for 7.1):
Supported / Non-Experimental
PSNullConditionalOperators: We agree that braces for variable names are an existing PowerShell construct, and they work fine here. This hasn't caused issues, so we just leave it on and merge the RFC with which it's associated.PSUnixFileStat: We haven't seen any reports of negative behavior, and it seems to be working well for those of us who use it.
Experimental (for now)
PSCommandNotFoundSuggestion: Suggestions are still broken in non-pwshhostsPSCultureInvariantReplaceOperator: Weirdly, our telemetry shows that this went down in 7.1, but we're not sure why, and there haven't been any issues filed on it since it was merged. Ilya (@iSazonov) it looks like you were the one to implement this, has this been useful for you and/or have you experienced or heard of any unintended behaviors?PSImplicitRemotingBatching: I recalled that this was somewhat incomplete, but we couldn't remember why. Paul Higinbotham (@PaulHigin) can you weigh in here?PSDesiredStateConfiguration.InvokeDscResource: This is still not well fleshed-out, and additional DSC behavior like DSC resource platform changes to use JSON instead of MOF #13359 will be behind experimental in 7.1 as well, so there's little benefit to moving this out of experimental.PSNotApplyErrorActionToStderr: A fix for Inconsistent handling of native command stderr #3996 and Redirection of stderr output from external programs sets $? invariably to $false, no longer reflecting whether $LASTEXITCODE equals 0 #10512, namely that we're consistent in not treating output instderras errors that trigger ErrorAction, and including a fix to set$?correctly in cases where ErrorAction is no longer triggered.PSNativePSPathResolution: Some edge cases don't work as expected, so we decided to leave this as experimental until they're fixed.Microsoft.PowerShell.Utility.PSManageBreakpointsInRunspace: Some problems have been raised since we originally decided to move this to supported, so it will remain experimental in 7.1.
On their way (and will remain experimental)
PSSubsystemPluginModel: This is the plugin model for minimal PS and PSReadline suggestion fixes. This feature will guard Get-Subsystem, and will also serve as a notation that the APIs are experimental and subject to change. (Still need to investigate how to notate that these are experimental)
Reacted by Ilya
Activity
PaulHigin commentedon Aug 11, 2020
It has been a while since I thought about
PSImplicitRemotingBatching. I remember that it is incomplete and not ready for prime time. There were some difficult scenarios that some users requested, but I haven't done any work on it.It is an interesting idea, but I remember my feeling was that it is too limited in its current form, but probably not worth the effort of continuing since few people would use it.
vexx32 commentedon Aug 12, 2020
IMO to make the PSNullConditionalOperators feature more usable, we should disable
?as a valid variable name token by default, so that we can write things like$myObject?.Method()without the awkward${myobject}?.Method()syntax.True, it would probably be better off as a separate experimental feature (even if after the null conditional one is accepted as stable in itself), but IMO that form of the null conditional syntax is not especially usable because of that and I tend not to use it as a result of that.
ALIENQuake commentedon Aug 13, 2020
Regarding
PSNullConditionalOperatorscouldn't agree more with vexx32. This is the neat feature but the implementation makes it impossible to use. The 'question mark' char has no meaningful value by being a part of the variable itself.ThomasNieto commentedon Aug 13, 2020
I also agree with Rain Sallow (/u/ta11ow) (@vexx32). I've talked with multiple PowerShell scriptwriters at my company. They won't be using this feature due to the extra syntax required.
Not to rehash the entire conversation with disallowing the question mark in a variable names but if we had a small breaking change to force users that want question marks in their variable names to use the
${name?}?.Propertysyntax while allowing the vast majority to make use of null conditional operators using the familiar syntax$name?.Property.joeyaiello commentedon Aug 25, 2020
Updating the above list to:
PSNotApplyErrorActionToStderrnameDHowett commentedon Sep 15, 2020
For PSNativePSPathResolution, #13638
sdwheeler commentedon Oct 28, 2020
Joey Aiello (@joeyaiello) Need a final list of what made it in and what didn't so we can update the docs. See https://docs.microsoft.com/powershell/scripting/learn/experimental-features for current doc.
joeyaiello commentedon Nov 11, 2020
Made some edits above to reflect that a couple more features were brought back to experimental
PSNativePSPathResolutionMicrosoft.PowerShell.Utility.PSManageBreakpointsInRunspacejoeyaiello commentedon Dec 14, 2020
Looks like this got caught up in bulk editing to get brought forward. This was done after 7.1 GA