In Praise of Exhaustive Destructuring

https://antoine.vandecreme.net/blog/exhaustive-destructuring-praise/

by avandecreme • 11 days ago

50 7 11 days ago

antoine.vandecreme.net

The dangerous weather example seems like a poor example. Most fields I would add would be orthogonal to existing functionality, and if they weren't, I would account for things I need to change (e.g. the is dangerous function) during the specification phase.

As an example of what I mean: The spec for "is dangerous" would have specified what "dangerous" means, and if that included high speeds, then that would have been known in advance when I made a plan to implement the speed feature.

The reason I mention this is that agentic coding seems to be requiring us to move to "spec-driven development" and it behooves us all to learn how best to adapt to this new landscape.

A simple example of an inline spec (i.e., a spec living as a comment in the code file, a bit like literate programming) for "is dangerous" would be something like:

    /*
     * dangerous = anything that would cause a risk of getting hurt for a healthy adult, e.g. heat stroke, lightning strike, hypothermia, gale force wind, flood, hurricane, tsunami, earthquake
     * Not all of this is implemented now, but that is what this function should try to do.
     */

jasim2• 6 days ago

But couple that with a deterministic system - the type checker with exhaustive destructing (and pattern matching, while we are it it) - that would become a fool-proof combination.

healthworker3• 6 days ago

Agreed. As long as we understand that the map (the code) is not the territory (the spirit of what the code should do), e.g., I can't have type-checking for earthquake if I don't have any earthquake-related concepts in the code yet, but earthquake could and should still be part of the aspirational aspect of the inline spec.

sarreph• 6 days ago

I used to be a die-hard destructurer! I liked the readability aspect, but ultimately two core problems emerged that pushed me towards dot-accessors:

1. It's highly verbose, especially in a language like TypeScript where you're often defining properties in types and then destructuring the same properties, making the whole thing look quite duplicative.

2. If you're passing an object through different functions doing similar things, I would quite often have to rename a destructured property in TypeScript because I would want to reuse the same name in a function-scoped variable.

I think for exhaustive switches, destructuring can be fine, but in general as long as you've got a well-defined set of types backing everything up, dot-access is neater.

Also on the point about optional parameters:

let's suppose some stations now have an anemometer and are able to record wind speed

I find that discriminated unions are so much better at dealing with these kinds of problems. Also tends to work better with dot-access because you're not then destructuring undefined properties.

dlahoda• 6 days ago

Rust has it own limitations making destructure to be not the only option.

So Rust has work in progress to improve.

In Praise of Exhaustive Destructuring

Related Stories