***Warning: These are raw notes, and still need to be cleaned up. Read at your own peril!***
# Tuple equality
We want to make it so that the `==` operator is delegated to the elements, but the choice of `&` operator shouldn't be up to the elements.
We can't think of this in terms of a user-defined `==` on the `ValueTuple<...>` overloads, since those don't have access to the specific `==` implementations of the type arguments.
1. Same as `(tempA == tempC) && (tempB == tempD)`, taking whatever `&` operator eventually gets used.
2. Same as `(bool)(tempA == tempC) && (bool)(tempB == tempD)` but only when there is an implicit conversion to `bool`
2a. Same as 2 or `!(tempA == tempC).false && !(tempB == tempD).false`, so there are two ways to make the individual comparisons `bool`
We want to do 2a, so that we make every effort to turn the result of each comparison into bool. For `==` we would use the `false` operator, for `!=` we will use the true operator. But the `&` and `|` are applied to booleans.
For dynamic, let's look at what `if` does and probably do the same.
# The fixed statement
We're adding support for a type to have a special method that returns a pinned ref.
## Copy?
Should that special method be executed on a copy or on an original l-value? We don't see good reasons to.
- The method might want to change the state for the benefit of a future `fixed` or otherwise
- Wasteful to copy big struct
## Generics
We need to know if it's a struct or a class, to decide whether to copy (for the null check) or not (to preserve mutations in a struct).
We already solved this for `?.`. We can emit a check for whether the type is a reference type (check whether its default is null), and the JIT specializes.
No lifting. You can do your own if you really want, but there is no way (for the compiler or user) to expose the value itself without copying. If you want to pin an specific nullable type you can, as long as an extension method is provided for it.
## Ref extension methods
Allow? Yes, same as for ref extension methods in general: Has to be called on a mutable l-value. For `in`, anything is fine.
## Name of method
`GetPinnableReference` is weird enough; we don't have to put "Dangerous" or something in the name.
