Repository navigation
Range operator (aka DotDot operator) with char operands in pipeline throws error #5519
Description
Steps to reproduce
A'..'B'
'A'..'B' | ForEach-Object { $_ }
Expected behavior
A
B
Actual behavior
Cannot convert value "A" to type "System.Int32". Error: "Input string was not in a correct format."
At line:1 char:1
- 'A'..'B' | ForEach-Object { $_ }
-
- CategoryInfo : InvalidArgument: (:) [], RuntimeException
- FullyQualifiedErrorId : InvalidCastFromStringToInteger```
Environment data
---- -----
PSVersion 6.0.0-rc
PSEdition Core
GitCommitId v6.0.0-rc
OS Microsoft Windows 10.0.15063
Platform Win32NT
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0```
Activity
markekraus commentedon Nov 21, 2017
repros for me.
mklement0 commentedon Nov 21, 2017
Interesting; I didn't even know support for character ranges was implemented. Can I suggest changing "dotdot operator" to "range operator" in the title?
TimCurwick commentedon Nov 21, 2017
I went with "dotdot operator" because that is what was used in the PR that added the character range implementation. #5026
mklement0 commentedon Nov 21, 2017
I see - that very nonstandard name is the reason that I wasn't able to find this new feature, despite then already knowing that it exists (based on this issue - that someone else would call it "DotDot operator" too hadn't occurred me), so thank you for adding the link.
I guess my mentioning the construct's official name here - range operator - now makes this issue more discoverable and, by extension, now also the linked PR, but my preference is always to have the important keywords in the title, as an
in:titlesearch then allows for a more focused search.mklement0 commentedon Nov 21, 2017
Another datapoint (and workaround): Forcing generation of the entire array up front avoids the problem:
IISResetMe commentedon Nov 21, 2017
The output from
Trace-Commandstrongly suggests that this code path is reached before the operator is explicitly invoked when the..appears as the very first operation in a pipeline:Why, I'm not entirely certain yet, will keep digging. While this is certainly not the intended behavior of the new
[char]overload for.., it doesn't seem to break any previously defined behavior (this is basically the expected behavior for$string..$otherstringprior to #5026)Re: the "nonstandard" name, I took it from the token that represents the underlying range operator :-)
[-]DotDot operator with char operands in pipeline throws error[/-][+]Range operator (aka DotDot operator) with char operands in pipeline throws error[/+]mklement0 commentedon Nov 22, 2017
Steve Lee (@SteveL-MSFT): Your title edit just made my day, thanks (I wish I were kidding).
Mathias R. Jessen (@IISResetMe): Fair enough, and perhaps "DotDot operator" is reasonably well-known; my term for it came from
Get-Help about_Operators, and I would argue that it's the more sensible name:Operators should be named for their purpose (only), not their syntactic form (too).
I won't repeat my rant about about the "dot sourcing operator" here.
Although, who's to say? Perhaps it's time for the "asterisk multiplication operator", or the "hyphen-minus subtraction operator", and, last but not least, the "dot-dot range operator".
lzybkr commentedon Nov 22, 2017
Mathias R. Jessen (@IISResetMe) - the idea was to name tokens after the syntactic form because it might not make sense if a token was allowed in some new context, e.g. if
..was allowed where it is no longer the range operator.