Allow New-Guid to accept optional byte array

[chelnak]

Summary of the new feature/enhancement

As a user I would like New-Guid to accept an optional custom byte array at creation time, allowing me to control the bytes that are used to create the Guid object.

Proposed technical implementation details (optional)

For example something like...

$Bytes = [System.Byte[]]::new(16)
$RNG = [System.Security.Cryptography.RNGCryptoServiceProvider]::new()
$RNG.GetBytes($Bytes)

$VersionByteIndex = [System.BitConverter]::IsLittleEndian ? 7 : 6
$Bytes[$VersionByteIndex] = $Bytes[$VersionByteIndex] -band [char]0x0F -bxor [char]0x40
$Bytes[9] = $Bytes[9] -band 0x3F -bxor 0x80

New-Guid -Bytes $Bytes

The underlying c# implementation would have a code path that calls new Guid(Byte[]).

https://docs.microsoft.com/en-us/dotnet/api/system.guid.-ctor?view=net-5.0#System_Guid__ctor_System_Byte___

Also if you want to ensure that the result is v4 RFC 4122 compliant then some sort of validation would be needed.

[mklement0]

Note that New-Guid is just a wrapper around Guid.NewGuid(), i.e. it generates a new GUID for you.

By contrast, the constructors of the Guid type essentially convert preexisting data to a Guid instance.

In other words: surfacing the constructor functionality wouldn't be an extension to the cmdlet's current mandate, but would mean adding entirely new functionality to it, and to me the question is:

Is this a common enough use case to warrant extending New-Guid, given that calling the constructors directly is already an option?

# Using an empty byte array for simplicity. Note that System.Guid also doesn't provide validation.
$bytes = [byte[]]::new(16)
[Guid]::new($bytes)

Alternatively, using the New-Object cmdlet to call constructors (passing an array as the only constructor argument makes this awkward):

$bytes = New-Object byte[] 16
New-Object Guid (, $bytes)

[chelnak]

Nice, thank you for the clear comment.

Agree about calling the constructor directly and is what I do in these edge cases.