Repository navigation
Range operator (aka DotDot operator) with char operands in pipeline throws error #5519
Description
Activity
repros for me.
Interesting; I didn't even know support for character ranges was implemented. Can I suggest changing "dotdot operator" to "range operator" in the title?
I went with "dotdot operator" because that is what was used in the PR that added the character range implementation. #5026
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.Another datapoint (and workaround): Forcing generation of the entire array up front avoids the problem:
('A'..'B') | ForEach-Object { $_ } # OK, due to (...)
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:PS C:\> Trace-Command -Expression {'A'..'B' |ForEach-Object { $_ }} -Name * -Option All -FilePath ($t = [System.IO.Path]::GetTempFileName()) 2>$null; Get-Content $t -TotalCount 2 TypeConversion Information: 0 : Converting to integer. TypeConversion Information: 0 : Exception converting to integer: "Input string was not in a correct format.".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 :-)
- changed the title
[-]DotDot operator with char operands in pipeline throws error[/-][+]Range operator (aka DotDot operator) with char operands in pipeline throws error[/+]on Nov 21, 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".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.Reacted by Michael Klement, Jos Koelewijn and Brian Scholer
Steps to reproduce
Expected behavior
Actual behavior
Cannot convert value "A" to type "System.Int32". Error: "Input string was not in a correct format."
At line:1 char:1
Environment data