Thanks for taking this on, Ilya (@iSazonov).

Generally, it sounds we should follow the example of -match and -split (assuming they work consistently among them), which is PSObject.ToStringParser(context, lval), which, from what I gather, is like using "$var" for a non-string value $var.

But I don't understand how PSObject.ToStringParser(context, PSObject.AsPSObject(lval)) differs in practice from PSObject.ToStringParser(context, lval).
Can you explain in more detail and give an example?

But I don't understand how PSObject.ToStringParser(context, PSObject.AsPSObject(lval)) differs in practice from PSObject.ToStringParser(context, lval).
Can you explain in more detail and give an example?

In second case we could fall in fast way - TryFastTrackPrimitiveTypes() or IFormattable. In first case a code path is another - follow ETS at first.
You can see the logic in internal static string ToString(ExecutionContext context, object obj, string separator, string format, IFormatProvider formatProvider, bool recurse, bool unravelEnumeratorOnRecurse)

I see - but, speaking from observation (haven't looked a the code):

Apart from [pscustomobject] instances, ETS properties seem to only affect output formatting, not stringification (in expandable strings). Or are there cases where including ETS properties makes a difference for stringification? If so, what are they, and can you give a specific example?

Michael Klement (@mklement0) The example is in #10389 (comment)

ETS properties seem to only affect output formatting

You confuse ETS (Extended Type System) with extensions for Formatting System (Update-TypeData vs Update-FormatData).

I see - you mean an ETS-overridden .ToString() method (I was thinking properties in general, which would only matter in formatting) - that's a helpful example.

So it sounds like -join is currently the only string-coercing operator that goes the ETS route.

-match, -split, -like do not.

In the case of #10389 the ruling was to prevent a behavioral -join change, even if that means forgoing a possible performance optimization.

Here, it comes down to this:

• PSObject.ToStringParser(context, lval) means aligning -replace with -match, -split, -like and results in no behavior modification (except for the culture-sensitivity being fixed)

  • However, that means that an ETS .ToString() method is ignored.

• PSObject.AsPSObject(lval)) is the conceptually correct thing to do, as it corresponds to what "$var" does (and you would expect the ETS to be honored consistently):

  • It would result in a behavioral change - arguably for the better - in that an ETS .ToString() method then would be respected, unlike before.

  • It would impact performance, as you state - I don't know to what extent.

I don't know what the performance implications are, but my personal recommendation would be to pick one of the following two options:

• Make all string operators use PSObject.AsPSObject(lval)) to ensure that ETS .ToString() methods are consistently honored.

  • Technically, a breaking change, but in spirit it is more of a bug fix.

• Fix -replace only and align with the majority behavior there, not least because -match, -split, -like are not only string operators but involve string matching (unlike -join), i.e., use PSObject.ToStringParser(context, lval) (and continue to have ETS .ToString() methods ignored).

Michael Klement (@mklement0) Great investigations! Thanks!

Steve Lee (@SteveL-MSFT) Perhaps PowerShell-Committee should weight these Michael Klement (@mklement0) 's proposed options.

@PowerShell/powershell-committee reviewed this. It's definitely a breaking change (Bruce Payette (@BrucePay) is calling it Bucket 2: Reasonable Gray Area), but we think it's the right thing to do.

Given where we're at in the release cycle, and our new snap to .NET's 1-year release cycle, we want to take this as an experimental feature into 7.1-preview.1 so we can understand the breakage and whether we need to revert to old behavior.

If you prefer to put the experimental feature name in a variable, then you can declare an internal const string field in the Const Member section to hold your experimental feature name.

It makes no sense because we can not use strong typed names out of SMA.
I reverted the change.

It makes no sense because we can not use strong typed names out of SMA.

If the experimental feature is not in SMA.dll, then it's not an engine feature and should not be declared in ExperimentalFeature.cs. Instead, it should be declared in the module where that dll is in.

Dongbo Wang (@daxian-dbw) Could you please continue?

Should we add CL-Experimental label?

I think we can only use 1 CL-xx label, otherwise the script to generate the change log will be confused.

I think we can only use 1 CL-xx label, otherwise the script to generate the change log will be confused.

It seems Travis said me that CL-Breaking can be used with another CL- label.

From releaseTools.psm1

    # Array of PRs with multiple labels. The label "CL-BreakingChange" is allowed with some other "CL-*" label.

I don't know about that, but what would you expect the script to do then? placing the same PR under both Breaking Changes and Experimental Features sections?
I think CL-BreakingChange wins in this case. But thanks for the quote, I added the experimental label.

Hmm, by looking at the following code, it seems the script doesn't handle multiple labels even if CL-breakingchange is one of them, as the switch will fall into the default case when $clLabel contains more than 1 item.

switch ($clLabel.Name) {

Here we will have an array and the switch will run for every value from the array.

Ah, you are right, I totally missed that.

🎉v7.1.0-preview.1 has been released which incorporates this pull request.:tada:

Handy links:

• Release Notes