Chandler Carruth

I'm still thinking about this, but I'd also like to suggest re-framing the questions a little bit. Specifically, I'd like to first answer which *use cases* we want to address...

I have a few clarifications after chatting about this with @josh11b -- thanks for the chat, it helped! Will write them up as separate comments as I think through them....

Updated to strikethrough use case (1) as #509 was resolved "no" (for now).

Chatting a bit with @zygoloid - we're both pretty happy with at least saying "no" to use case (4) entirely based on the suggestion from @josh11b for how to handle...

> I have been trying to write out choices [in this Google doc](https://docs.google.com/document/d/1iuytei37LPg_tEd6xe-O6P_bpN7TIbEjNtFMLYW2Nno/edit#heading=h.5rokc9pmypp8). I'd like to propose we go with something simple: I think I agree with your suggestion, especially...

Just to leave a note here that the leads are explicitly deferring this question and #476. We're not opposed to named parameters and arguments, but the initial motivation for prioritizing...

My initial leaning went towards tackling the potential grammar risk head on, and allowing patterns to (potentially) bind _name_-qualified names.... So: ``` namespace NS; var (NS.a: i32, NS.b: i32) =...

> We can make this a bit nicer by saying that you _either_ get a single qualified name in a `let` or `var` (following the rule in my earlier comment),...

Structurally, I think we should keep these aligned with function parameter patterns. I think there are still questions about what kinds of patterns we want to support in these positions,...

Just to note, we decided in #2188 to not allow a nested name binding in the type position and make the type position of a binding just an expression (and...