Tuples and how the relate to strong typisation

[ChristopherG84]

This is not an issue with the actuall ,build, but more a question I have about the idea of Tupels (the C# 7 construct) and strong typisation. And I could not find the proper Forum for open discussions.

I worked with a lot of languages over the last 1.5 decades.
I originall learned on native C++. I had some stints with PHP, Java, Mixal and Phyton. Most solidly I am now in C# and .NET.

And if you stint with PHP taught me one thing, it is to love strong typisation. This comic by a fellow programmer showcaes nicely the issues that result from weak typisation and/or overly agressive implicit conversions:
http://www.sandraandwoo.com/2015/12/24/0747-melodys-guide-to-programming-languages/

We also had situations where the order of inputs matered in .NET before.
When using DbParameters with the old OleDBCommand class the names of the parameters did not mater - it was going purely by order:
https://msdn.microsoft.com/en-us/library/system.data.oledb.oledbparameter(v=vs.110).aspx

I feel like tupels might re-introduce that issue as they can be deconstructed by order. Indeed it appears doing that is the default way.
It never matered if a struct/class was written like this:
stuct something{ int Int1; bool bool1; }
or this:
stuct something{ bool bool1; int Int1; }
Except maybe in odd cases like Reflection (I am not even sure it matered there).

But with these new Tupels, it does mater.
Moreover with the support to use var to take over the tupel contents, changing the order of contents of a function return tupel from "bool bool1, int Int1" to "int Int1, bool bool1" between two builds could break using code in unpredictable ways:
Suddenly what used to be a bool (on previous compilations) is a int and vice versa. Wich version of this library you use matters all of a sudden or code will not compile.

I feel like we might just be making a old mistake yet another time. But maybe that is already acounted for somehow and I am just missing that part?

[DavidArno]

One important thing to remember here is that types cannot be implicitly deconstructed to tuples, unless you provide Deconstruct methods for those types. So the following will not work by default:

struct something{ int Int1; bool bool1; }
...
var (a, b) = new something();

This will only work if a Deconstruct method is added to something:

struct something
{ 
    int Int1; 
    bool bool1; 
    public void Deconstruct(out int i, out bool b) { i = Int1; b = bool1; } 
}
...
var (a, b) = new something();

So the order of the fields/properties in the type do not matter, still.

[CyrusNajmabadi]

But with these new Tupels, it does mater.

Yes. Tuples are an ordered sequence of data. If you change the order you change the contract. That's a very intentional and important part of their design. If your domain wants unordered data, you def should not use tuples. Struct-Records will be more likely what you want (when they come in a future release).