Add a `Join-Object` cmdlet to the standard PowerShell equipment

As the verb-noun convention suggests, I think that there are a lot of developers looking for a common way to join objects (lists). See StackOverflow: In Powershell, what’s the best way to join two tables into one? Personally, I am convinced that a Join-Object cmdlet will generally result in a better syntax were an object (list) join is required (in comparison with alternative cmdlets along with Group-Object) and better performance (then using obvious iterators like ForEach-Object together with Where-Object or similar cmdlets and methods). For that reason I am maintaining a Join-Object script/module for more than 3 years now. I don’t think that my Join-Object version should be added to the standard PowerShell package (for one thing, it is written in PowerShell and not C# 🤔), but it might serve as an example for what I would expect from a syntax that comes together with a Join-Object cmdlet.

What do I expect from a “internal” Join-Object cmdlet?

• An intuitive idiomatic PowerShell syntax The syntax should be PowerShell like and include features similar to the SQL Join clause where it basically joins (a list of) objects or items based on related properties (-On parameter) or a simple side-by-side list join (by omitting the -On parameter) as a specific PowerShell cmdlet feature (see: #14732) .
• Ability to do similar Join types as SQL, along with InnerJoin, LeftJoin, RightJoin, FullJoin
• Ability to join based on multiple property relations, e.g.: -On Column1, Column2
• Smart property merging (e.g. if a properly is defined as related, it should only appear ones in the result)
• Respect the PowerShell pipeline (for the left object supplied through pipeline)
• A reasonable performance by using a binary search (HashTable) on the right object (knowing that it needs to be iterated multiple times). Also note the Linq Join-Object solution by @ili101
• Calculated properties
• …

[mklement0]

An aside re:

And it could even prevent to invest too much in traditional operators as shown here.

As I’ve argued in detail in https://github.com/PowerShell/PowerShell/issues/14724#issuecomment-777801399, there is no reason to pit cmdlet-based solutions against expression / statement-based solutions: both are necessary, and in certain cases use of one over the other is the only option. Instead, we should strive for feature parity, to the extent that is feasible.

[chenxizhang]

vote for this feature