The Match function takes two instances of the ResourceId type and allows comparing the parsed segments for these.
Whilst this is also possible by comparing the value of .ID() in both instances - that's not case-aware and so will be problematic in the future - hence the need for this function which can account for case-aware comparisons.
This also exposed a feature-flag for treating User Specified Segments as case-insensitive for comparison purposes - however this isn't usable at this time and so must not be exposed as a toggle at this point-in-time, since it'll cause more problems than it solves. However having this internal-only feature flag allows us to built out the surrounding components ahead-of-time and add tests covering both scenarios - therefore this is beneficial to have as an internal toggle today - even if it's not usable for end-users for some time.
There are currently 6 instances of this across the Provider:
The
Match
function takes two instances of the ResourceId type and allows comparing the parsed segments for these.Whilst this is also possible by comparing the value of
.ID()
in both instances - that's not case-aware and so will be problematic in the future - hence the need for this function which can account for case-aware comparisons.This also exposed a feature-flag for treating User Specified Segments as case-insensitive for comparison purposes - however this isn't usable at this time and so must not be exposed as a toggle at this point-in-time, since it'll cause more problems than it solves. However having this internal-only feature flag allows us to built out the surrounding components ahead-of-time and add tests covering both scenarios - therefore this is beneficial to have as an internal toggle today - even if it's not usable for end-users for some time.
There are currently 6 instances of this across the Provider:
in addition to (at least) https://github.com/hashicorp/terraform-provider-azurerm/pull/25809 - therefore we should get ahead of this and switch to using
resourceids.Match
to enable us to handle this consistently in the future.