3 ms·
Still no first-class tuple support? Argh! All want is: var first, last = parseName(fullName); Instead of: String last; var first = parseName(fullName,
by DenisM 12y ago
Still no first-class tuple support? Argh! All want is:
var first, last = parseName(fullName);
Instead of:
String last;
var first = parseName(fullName, out last);
- BigChiefSmokem 12y agoi think it's because they rather have you pass in fullName string and get back a typed Name object instead. that second example is always a bad choice and i would never but i do agree a little tuple support would be nice as a trap door kinda feature to avoid code like this
- DenisM 12y agoHaving to create a class for everything is a chore, it doubles the amount of named things in the codebase. It also creates an undue discontinuity when moving from one returned value to two returned values during the process of codebase evolution. Either first-class tuples or anonymous classes as return types would reduce this cognitive overhead.
- sootzoo 12y agoAgree with the complaint but not the workaround; there is Tuple<string, string>, after all, so maybe something like this? Tuple<string, string> fullName = ParseName(fullName); var firstName = fullName.Item1; var lastName = fullName.Item2;
- louthy 12y agoTotally agree on the need for tuple syntax (and pattern matching to make it really useful): return Tuple.Create(foo,bar); Should be: return (foo,bar); The worst part is using the Item1..ItemN properties. One way I've gotten around it is to create a Tuple extension method called Apply [1]. I allows you to do this: ParseName(fullName).Apply((first, last) => ... ) That allows for giving names to the tuple ItemX fields and uses them 'in scope'. At least with C#6 we can now open static classes like namespaces and do something this: using Language.Helpers [2] ... return tuple(x,y); Which already makes it start to feel like it's part of the language. [1] https://gist.github.com/louthy/f4cee2524d0d049b4378 https://gist.github.com/louthy/f4cee2524d0d049b4378 [2] https://gist.github.com/louthy/dc06868c446ed76f0d7a https://gist.github.com/louthy/dc06868c446ed76f0d7a
- DenisM 12y agoApply creates new scope, which is often undesirable. Consider the "Declaration expressions" feature in C# 6: ParseName(fullName).Unpack(out string first, out string last); However, this makes for essentially left-to-right assignment, which is contrary to the usual order. So this creates discontinuity when moving from one return value to two return values.
- louthy 12y agoMy personal opinion is 'out' is a total abomination. I will do everything I can to avoid using it. I prefer expression based programming where there's a balance between the two sides of an operator. Declaring named values on the RHS is just horrible (again, IMHO). The only reason for it to exist is because C# hasn't got proper tuple support. By the way, creating a new variable half-way down a method is also creating a new scope (the variable isn't in scope above the declaration, and it is in scope below it, until the end of the method). For example: public int GetSurnameLength() { string fullName = ReadFullNameFromDb(); Tuple<string,string> result = ParseName(fullName); return result.Item2.Length; } Has the same effect as: public int GetSurnameLength() { string fullName = ReadFullNameFromDb(); return ParseName(fullName).Apply( (first,last) => last.Length ); } The only real downside to the Apply method is the syntax clutter from the closure. But there's no real issue with scope as far as I can tell (because the rest of the method can be within the closure if necessary). This is very similar to how 'let' works in F#.