Faulty suggestion to convert to LINQ in 7.1

Albeit using Resharper 7.1, I want to check this out.

Resharper suggests to change this:
public static string ReplaceAll(this string input, Dictionary<char, char> replacementMap)
{

    foreach (var replace in replacementMap)
    {
        input = input.Replace(replace.Key, replace.Value);
    }


Into this Linq expression:
replacementMap.Aggregate(input, (current, replace) => input.Replace(replace.Key, replace.Value));

The problem is that a string is immutable and that this breaks function. Should be the following to work:
replacementMap.Aggregate(input, (current, replace) => curent = input.Replace(replace.Key, replace.Value));

This would be considered a bug, right? Is it fixed in newer verions? Just curious.
This is the first time resharper breaks something for me and it led me away to fight imaginary battles with red character encoding herrings for a while.

2 comments
Comment actions Permalink

The LINQ statement generated is incorrect, it should be:

replacementMap.Aggregate(input, (current, replace) => current.Replace(replace.Key, replace.Value));

Note the use of current.Replace, not input.Replace (is this a copy paste error? It's not consistent with what you describe the error to be).

On each call to the lambda, the current parameter is the "running total" value. The return value of the lambda is used as the new value of the "running total" and passed in as current for the next item in the sequence. Assigning a value to current has no effect in the lambda, because it's not an out or ref parameter, so changing it does nothing.

0
Comment actions Permalink

Yeah, I have no idea how this happened. There must have been a mayor glitch in the matrix, or I somehow executed a major fuck-up. In all honesty, the later is probably the most likely since I can not reproduce anything. Thanks.

0

Please sign in to leave a comment.