C#

atrus2711 wrote:

IEnumerable<string,int>

atrus2711 wrote:

What could a "unified" method signature look like?

private void Doit<T>(IEnumerable<T> values) { ... }

var result = SomeList.Select(c => c.IntegerField).Distinct();

var result = SomeList.Select(c => new { c.IntegerField1, c.IntegerField2}).Distinct();

var result = SomeList.Select(c => new { c.StringField, c.IntegerField}).Distinct();

private void DoIt<TSource, TResult>(IEnumerable<TSource> source, Func<TSource, TResult> selector, IEqualityComparer<TResult> comparer = null)
{
    ...
    var result = source.Select(selector).Distinct(comparer);
    ...
}

DoIt(SomeList, c => c.IntegerField);
DoIt(SomeList, c => new { c.IntegerField1, c.IntegerField2 });
DoIt(SomeList, c => new { c.StringField, c.IntegerField });

Nathan Minier wrote:

I generally avoid standard Tuples anyway in favor of interfaces.

Nathan Minier wrote:

There are definitely new gotchas when implementing property update events.

BillWoodruff wrote:

Thanks; I would be interested in seeing a code sample using an Interface that is an alternative to use of a Tuple.

interface IExample{
   int Number {get;set}
   string Text {get;set;}
}

Tuple<int,string> ExampleTuple;
IExample ExampleImplementation;

Eddy Vluggen wrote:

you omit XML documentation on a member.

Eddy Vluggen wrote:

How is it more readable than returning a known structure?

Eddy Vluggen wrote:

does it justify the money saved on 'typing'?

BillWoodruff wrote:

fyi: I'm not evangelizing for use of ValueTuples, I'm inquiring about them.

BillWoodruff wrote:

The post is a short, simplified, example intended to elicit discussion.

BillWoodruff wrote:

I do not make the claim it is more readable in every circumstance.

Bastard Programmer from Hell
If you can't read my code, try converting it here[^]

Quote:

An interesting note about ValueTuple is that it is mutable. Mads Torgersen explains why,

The reasons why mutable structs are often bad, don't apply to tuples.

If you write a mutable struct in the usual encapsulated way, with private state and public, mutator properties and methods, then you are in for some bad surprises. The reason is that whenever those structs are held in a readonly variable, the mutators will silently work on a copy of the struct!

Tuples, however, simply have public, mutable fields. By design there are no mutators, and hence no risk of the above phenomenon.

Also, again because they are structs, they are copied whenever they are passed around. They aren't directly shared between threads, and don't suffer the risks of "shared mutable state" either. This is in contrast to the System.Tuple family of types, which are classes and therefore need to be immutable to be thread safe."

Bernhard Hiller wrote:

Your example above is a typical textbook example, where I do not see the full power of Value Tuples.

Bernhard Hiller wrote:

... their major advantages are with more functional styles of programming, e.g. with Linq.

public Name(string first = null, string middle = null, string last = null) { ... }
...
public (string first, string middle, string last) FullName
{
    get 
    {
        return (first: FirstName, middle: MiddleName, last: LastName); 
    }
    set 
    { 
        FirstName = value.first;
        MiddleName = value.middle;
        LastName = value.last;
        
        // Or:
        // (FirstName, MiddleName, LastName) = value; 
    }
}

public void Deconstruct(out string first, out string middle, out string last)
{
    first = FirstName;
    middle = MiddleName;
    last = LastName;
}

var (_, _, lastname) = nametest2;
// lastname == "doe"

Richard Deeming wrote:

I can possibly see them being useful internally within a single project. But for shared code, a traditional class or struct would still be the better option.