meetings/2018/LDM-2018-02-07.md
Warning: These are raw notes, and still need to be cleaned up. Read at your own peril!
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.
(tempA == tempC) && (tempB == tempD), taking whatever & operator eventually gets used.(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 boolWe 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.
We're adding support for a type to have a special method that returns a pinned ref.
Should that special method be executed on a copy or on an original l-value? We don't see good reasons to.
fixed or otherwiseWe 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.
Allow? Yes, same as for ref extension methods in general: Has to be called on a mutable l-value. For in, anything is fine.
GetPinnableReference is weird enough; we don't have to put "Dangerous" or something in the name.