New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

`switch` statement: deprecate the -exact option #8599

Open
mklement0 opened this Issue Jan 7, 2019 · 5 comments

Comments

Projects
None yet
3 participants
@mklement0
Copy link
Contributor

mklement0 commented Jan 7, 2019

Note: By deprecation I mean "soft" deprecation, i.e., deprecation without (eventual) removal, in the interest of backward compatibility.

Summary of the new feature/enhancement

The -exact option is never needed and was presumably only ever implemented for symmetry with -wildcard and -regex, as a way to explicitly opt into the default behavior, which is essentially: implied -eq comparison, which with strings means case-insensitive comparison in full (though you can opt into case-sensitivity by adding -casesensitive).

Given that I think most users expect this behavior by default anyway, -exact only raises unnecessary questions, not least due to its name, given that it can be combined with -casesensitive (as an aside: to contrast it with -wildcard and -regex, -literal would have made more sense as a name).

Proposed technical implementation details (optional)

  • Remove -exact from tab completion, if possible.

  • Mention -exact in the docs as never being necessary and existing primarily for backward compatibility.

@BrucePay

This comment has been minimized.

Copy link
Member

BrucePay commented Jan 7, 2019

@mklement0

The -exact option is never needed and was presumably only ever implemented for symmetry with -wildcard and -regex, as a way to explicitly opt into the default behavior,

Explicitly indicating intent is a useful thing.

@mklement0

This comment has been minimized.

Copy link
Contributor

mklement0 commented Jan 8, 2019

@BrucePay:

Explicitly indicating intent is a useful thing.

Sometimes, yes, but not categorically:

Given that:

  • the option's name is confusing, as explained.
  • that the default behavior is sensible and is what users are likely to expect, along with the need to opt into variant behaviors (-wildcard, -regex, -casesensitive).

I'd say we're better off without -exact overall.

Note that there's no -caseINsensitive either, for instance, and I don't think anyone wishes there were.

@vexx32

This comment has been minimized.

Copy link
Contributor

vexx32 commented Jan 8, 2019

Aye, the default behaviour is essentially what users coming from other languages will more or less expect.

Having a switch named -Exact makes it sound like it's more specific than the default, which it isn't.

@BrucePay

This comment has been minimized.

Copy link
Member

BrucePay commented Jan 8, 2019

@mklement0

the option's name is confusing, as explained.

I supposed we could have named them -ExactMatch, -WildCardMatch, -RegularExpressionMatch. That's pretty clear. On the other hand, since matching is the whole point of the switch statement, it seems a bit redundant.

into variant behaviors (-wildcard, -regex, -casesensitive).

-CaseSensitive is not, in itself, a variant behaviour. It's a modifier for wildcard/regex/exact e.g.

    switch -CaseSensitive -Exact(Match) {

In general, allowing script authors to strongly express intent is a pervasive theme in the design of PowerShell: long options, noun-verb command names, even language operators like -ieq, -ceq, -eq, etc. support this. And while the need for elastic syntax means that this can not be required , it is absolutely encouraged for production scripting.

@mklement0

This comment has been minimized.

Copy link
Contributor

mklement0 commented Jan 9, 2019

I supposed we could have named them -ExactMatch

The problem is the word exact (a case-insensitive match is not an exact one); literal would have been better, but I still think there's no need for this option altogether (see below).

-CaseSensitive is not, in itself, a variant behaviour

Switching from case-insensitive to case-sensitive matching is a variant behavior too, just along a different dimension.

even language operators like -ieq, -ceq, -eq, etc. support this.

A switch statement without options can - and is likely to - be conceived of as a generalized -eq statement, with -eq being used to match the branch conditions.

As such, -exact would be akin to complementing the -eq operator with an -exacteq operator, which is both unnecessary and confusing.

To mirror -ceq / -ieq, you could make the case that switch should support -caseinsensitive too, after all; while I personally think that's not necessary, I wouldn't consider it problematic.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment