c# multi assignment

后端 未结 7 1783
温柔的废话
温柔的废话 2020-12-16 13:54
int a, b, n;
...
(a, b) = (2, 3);
// \'a\' is now 2 and \'b\' is now 3

This sort of thing would be really helpfull in C#. In this example \'a\' and

相关标签:
7条回答
  • 2020-12-16 14:04

    Creating a set of Unpack<T1, T2>(this Tuple<T1, T2>, out T1, out T2) methods would be a more idiomatic c# way of doing this.

    Your example would then become

    int a, b, n;
    ...
    Tuple.Create(2, 3).Unpack(out a, out b);
    // 'a' is now 2 and 'b' is now 3
    

    which is no more complex than your proposal, and a lot clearer.

    0 讨论(0)
  • 2020-12-16 14:07

    As others already wrote, C# 4 Tuples are a nice addition, but nothing really compelling to use as long as there aren't any unpacking mechanisms. What I really demand of any type I use is clarity of what it describes, on both sides of the function protocol (e.g. caller, calle sides)... like

    Complex SolvePQ(double p, double q)
    {
        ...
        return new Complex(real, imag);
    }
    ...
    var solution = SolvePQ(...);
    Console.WriteLine("{0} + {1}i", solution.Real, solution.Imaginary);
    

    This is obvious and clear at both caller and callee side. However this

    Tuple<double, double> SolvePQ(double p, double q)
    {
        ...
        return Tuple.Create(real, imag);
    }
    ...
    var solution = SolvePQ(...);
    Console.WriteLine("{0} + {1}i", solution.Item1, solution.Item2);
    

    Doesn't leave the slightest clue about what that solution actually is (ok, the string and the method name make it pretty obvious) at the call site. Item1 and Item2 are of the same type, which renders tooltips useless. The only way to know for certain is to "reverse engineer" your way back through SolvePQ.

    Obivously, this is far fetched and everyone doing serious numerical stuff should have a Complex type (like that in the BCL). But everytime you get split results and you want give those results distinct names for the sake of readability, you need tuple unpacking. The rewritten last two lines would be:

    var (real, imaginary) = SolvePQ(...); // or var real, imaginary = SolvePQ(...);
    Console.WriteLine("{0} + {1}i", real, imaginary);
    

    This leaves no room for confusion, except for getting used to the syntax.

    0 讨论(0)
  • 2020-12-16 14:09

    The closest structure I can think of is the Tuple class in version 4.0 of the framework.

    0 讨论(0)
  • 2020-12-16 14:10

    The behavior that you're looking for can be found in languages that have support or syntactic sugar for tuples. C# is not among these langauges; while you can use the Tuple<...> classes to achieve similar behavior, it will come out very verbose (not clean like you're looking for.)

    0 讨论(0)
  • 2020-12-16 14:13

    We have considered supporting a syntactic sugar for tuples but it did not make the bar for C# 4.0. It is unlikely to make the bar for C# 5.0; the C# 5.0 team is pretty busy with getting async/await working right. We will consider it for hypothetical future versions of the language.

    If you have a really solid usage case that is compelling, that would help us prioritize the feature.

    0 讨论(0)
  • 2020-12-16 14:20

    Deconstruction was introduced in C# 7.0: https://blogs.msdn.microsoft.com/dotnet/2016/08/24/whats-new-in-csharp-7-0/#user-content-deconstruction

    0 讨论(0)
提交回复
热议问题