Generic across forms

[josh11b]

We propose:

• Special type Core.Form whose values describe the form (category, phase, and so on) of parameters or returns in the signature of functions.
• A form(...) literal syntax for writing values of these form types.
• Form facet types for expressing constraints on form types, which may be composed using &.
• :? binding and ->? return syntax parameterized by a form value.
• Form versions of interfaces, facets, and facet types.
• Use these new form facet types to create new "primitive" versions of the operator interfaces, like Core.CallPrimitive, that allow control over the form of the parameters and return.
• A call(...) syntax for concisely and naturally writing facet types of the Core.CallPrimitive interface.
• Impl lookup will allow some conversions between Core.Form values in interface arguments and associated constants, when specified by the interface, replacing the existing mechanism where impls use like to allow implicit conversions in arguments.
• A number of increased capabilities for named constraints.

Together these changes will allow:

• the operator interfaces to support Carbon's full range of function semantics, particularly in the Core.CallPrimitive form interface;
• replacing our existing operator interfaces like Core.Call and Core.AddWidth with named constraints that use types instead of forms;
• a new, more capable definition of alias, along with a shorthand using;
• full-fidelity forwarding of function parameters; and
• a syntax for a compile-time parameter that is equal to a specified value.

[geoffromer]

Looks like something's missing here.

[geoffromer]

This seems like it follows from what's already been said about Core.Form and .type, rather than being a separate feature introduced by this proposal. Am I missing something?

[geoffromer]

I'm having a hard time parsing this sentence -- I feel like maybe there's a missing verb after "would", and "a facets" is clearly a typo but I'm not sure what the correct version is.

[geoffromer]

Why can't we instead say that form() can contain anything that can appear in a ->? return form, e.g. form((var i32, ref f64, formof(7)))? That requires no more dedicated syntax than the current proposal, and it would make the language more consistent, as well as making compound form literals less verbose.

[geoffromer]

Suggested change

	We instead decided that `ref` on an argument only affects deduction. In this
	We instead decided that `ref` on an argument only affects deduction, because this
	minimizes the divergence between function calls and other forms of pattern maching. In this

Feel free to take or leave that particular suggestion, but it would be good to give some indication of why we chose this.

[geoffromer]

If I understand correctly, the binding itself isn't quite referentially transparent, because if y is an initializing expression, x will be a reference expression. Instead, ~x is referentially transparent (given the assumptions you make elsewhere about the semantics of ~). It's probably worth saying so explicitly.