The same.

We don't but it saved me from specifying null for the argument where it is called. I can certainly make it without a default if you prefer that.

I do think the default is a nice way to see that the argument is nullable without having to turn on the nullability checks and annotating it.

I see your point. This is not critical, it just makes me think that there are a number of call sites that use this default.

In this case there still are, this is why I added the default in the first place because there are some calls where there is no assembly object to provide.

Last attribute win? In code above first win. I'd expect the same here.

It's somewhat confusing but the "first" attribute is actually the closes one to the definition rather than it being top -> bottom.

So in the below example the first attribute is actuallyBottom, thenMiddle, then finallyTop.

[Parameter(HelpMessage='Top')][Parameter(HelpMessage='Middle')][Parameter(HelpMessage='Bottom')][string]$Param

This could change in the future but the code already goes bottom -> top and I don't think this PR should be the one to revisit that choice.

I mean line 791. There is abreak but not here. Why is it different?

The code from 783-794 only check for the help message and does not check forDontShow (what it is doing today) so once we get a message we can cancel the loop entirely.

The code from 904-921 currently checks ifDontShow is present hence why it breaks early there in that code branch. With this PR it also now checks for the help message if present but it doesn't break because it still needs to check forDontShow if present in subsequent attributes for the parameter.

I ask about follow difference:

• In code from 783-794 we get help message from "Bottom" (first attribute in the loop)
• In code from 904-921 we get help message from "Top" (last attribute in the loop)
  Yes?

No differences they are both the same, both will loop through the attributes in the "compiled" order from PowerShell (bottom up). It will stop at the first attribute where there is a valid help message found.

The only reason why there is a difference in code is because one handlesDontShow while the other does not. This is a behaviour not touched by this PR at all.

This could change in the future but the code already goes bottom -> top and I don't think this PR should be the one to revisit that choice.

Before this change, there was nothing in the result to distinguish one result from another for the same parameter. But now we have such property -Tooltip. That's why I can't agree with your statement. The results should be generated correct now.

In[string][int]$var first attribute win -[string]. The common expectation is that first parameter attribute win too and we see help message from the attribute.
Also if parameter has two parameter attributes for different parameter sets we should get help message from correct parameter set if possible or all cases.

I'm just going to have to leave this as is. This is beyond what I find needed for such a PR. Will just have to wait until someone from the pwsh team gets to this.

MSFT team has already clearly outlined the work that they will do in this milestone and they will not consider others as this exceeds their capabilities.

@daxian-dbw What do think about the inconsistency?

It is better to check all the cases explicitly to avoid regression in any form (in tests below too):

In this case we are only testing the ToolTip message for each returned option but even if you wanted to have multiple tests there are a few problems with this approach:

• This will return all parameters including the common ones so adding more common parameters would mean you also need to update this test
• I've already added a specific test for a parameter without the help message herehttps://github.com/PowerShell/PowerShell/pull/25108/files#diff-393e1fa171a673ad5e5c3c1f3700ad03d32d46031ffcf72e4eaac1a7c7c46579R1056-R1077

This may not apply to this change directly, but if it is possible to make an additional check, why not add it and exclude regression in case someone reworks this code?
My suggestion is to expand this test a bit and check that the text from the first parameter is not randomly displayed for the second one.

Because if attributes for another parameter are being applied to another we have a major problem that would/should be picked up by other tests. By testing it here as well we complicate an already somewhat complicated test that isn’t designed to check for this particular problem.

@iSazonov any further response to@jborean93's response? We have implemented the appropriate parts of PSES to support this change and I'd like to pick this up again and move it forward if possible.

@JustinGrote I'm sorry, but I can't help you. Firstly, the contributor rejected my requests and expressed a desire to continue only with the MSFT team, and they do not have this work in their plans. Secondly, time is lost, because it's time to stabilize before the next release. So there is very little chance that it will be accepted soon.