Combining records and enumerations

[Brian Goetz]

On 10/14/2021 7:43 AM, Aaron Scott-Boddendijk wrote:
> In two of my projects (unfortunately closed-source), both with over 100
> enums, nearly half look like they would convert to this pattern (our enums
> often have additional attributes, a strength of Java enums).
>
> There's a significant percentage of the enum-type body dedicated to
> ceremony that this would eliminate.

As I said, it's not a *bad* feature, it just has a worse return on 
investment than other features we could be working on.  We could 
prioritize this, but we'd have to deprioritize something else. Should we 
delay deconstruction patterns for six more months to make room for 
this?  Deconstruction patterns seem way more powerful.

> FYI, I really dislike the deconstruction term, as in general conversation
> 'construction' tends to imply allocation as well as constructor invocation.
> Destructuring seems a more precise term and one that several languages
> already use - and it then also covers destructuring patterns for types for
> which there was no equivalent 'constructor' (eg array/slice destructuring
> patterns).

Naming things is hard.

We considered using "destructuring" for all the reasons you suggest, but 
it is not without its problems either.  First, destructuring is a more 
general term than the concept being described here; what we are callling 
a "deconstruction pattern" is merely one form of destructuring, and 
there will be others.  And the name "destructurer" is impossible to 
spell or pronounce correctly.  More importantly, in the object model, 
this is the dual of construction, and to the degree users can see it 
that way, they will understand the concept more immediately.  Later 
features will be built on matching pairs of constructor and 
deconstructor (or deconstruction pattern).  The similarity in naming is 
important.

The main problem with "deconstructor" is the potential confusion with 
"destructor" in C++.

Naming things is hard.