object destructuring

Using the techniques from #4127 and #4406. It’s now possible to implement destructuring for user-written classes as a syntax sugar over existing constructs in the language. (That is to say, with zero impact upon the backend.)

For example, we could make:

case (Person(name, age)) expr

desugar to:

case (is Person) let ([name, age] = p.destructured) expr

Given a new language module interface Struct shown here.

Or, alternatively, we could make:

case (Person { name, age }) expr

desugar to:

case (is Person) let (name = p.name, age = p.age) expr

Which is a solution that requires no Struct interface or any other kind of “extractor” function, but does not allow easy renaming. (You would have to write Person { fullName=name, age } or whatever if you were fussy about local aliases.)

I have two questions about this:

1. Which of the above approaches do we prefer? With or without the Struct interface? I lean towards the solution without it.

2. What does destructuring look like in syntactic locations other than switch? Is it, for example:

   for (Person {name, age} in people) { ... }
   

   Or would it just be:

   for ({name, age} in people) { ... }
   

Thoughts?

[gavinking]

For example, I guess you would wind up with something like this:

Person { name, address = { street, city, state, zip } }

Ah no, sorry, my bad. That was silly. You would write it like this:

Person { name, { street, city, state, zip } = address }

or like this:

Person { name, Address { street, city, state, zip } = address }

which is perfectly natural, and totally consistent with the syntax for aliases.

So that’s fine. There’s no problem there for nested patterns.

For literals in patterns I guess you would come up with something like:

Person { name, age == 18 }

which is also OK, I suppose.

[lucono]

But we also wind up with the most natural way to combine a condition with nested destructuring being:

Person { name, 
         exists address { street, city, state }, 
         is Employment activity { employer, since } }

which looks perfectly reasonable but isn’t the same as the existing syntax for conditions:

Person { name, 
         exists { street, city, state } = address, 
         is Employment { employer, since } = activity }

@gavinking - Agree the first one feels very natural.

I think the following syntax for combining all of destructuring, conditions and aliasing would feel as natural, without being inconsistent with existing syntaxes:

Person { name, 
         exists addressAlias = address { street, city, state }, 
         is Employment activityAlias = activity { employer, since } }

My head naturally parses the { ... } part of address { street, city, state } as simply a destructing operator/operation on address, more than as a local declaration of street, city and state. It just happens that the destructuring has the effect of creating the locals anyway.

So that it really doesn’t feel in conflict with the syntax for conditions:

• fits the syntax for conditions: (exists localName = expression)
• also fits the syntax for imports: import some.package { TypeAlias = Type }
• without the aliases, drops back to exactly what you had in the first one.

Without aliases:

Person { name, 
         exists address { street, city, state }, 
         is Employment activity { employer, since } }

Without conditions (similar to imports):

Person { name, 
         addressAlias = address { street, city, state }, 
         activityAlias = activity { employer, since } }

Without aliases or conditions:

Person { name, 
         address { street, city, state }, 
         activity { employer, since } }