Standardize boolean parameters
Opened this issue · 4 comments
[bool]
has some annoying behaviors, e.g. you can't pass bare strings true
or false
Using this pattern makes consumption easier
[Parameter()]
[ValidateSet($null, 'true', 'false')]
[object]
I think that should be a nullable bool tbh.
[nullable[bool]]
You shouldn't pass strings to that...
The [ValidateSet]
+ string
approach is certainly not ideal.
But if you use [nullable[bool]]
, you can't provide a string literal, e.g.
<CmdLet> -BooleanProperty false
results in ⬇️
Cannot convert value "System.String" to type "System.Nullable`1[System.Boolean]".
Boolean parameters accept only Boolean values and numbers, such as $True, $False, 1 or 0.
Seems like an oversight in Powershell; if you're going to say integers are valid, why not (unambiguous) strings?
But that's expected, because we want a [bool] (we just have to add a $
).
Why using 'false'? Is it purely for "shell" usage?
indeed -- I like supporting string literals as often the cmdlets are invoked from CI jobs. in some cases, the fact that the underlying code is powershell is completely hidden