a GPIO should always be enabled AFTER configuring direction etc

[CodingVoid]

The first code example in this section:
https://docs.rust-embedded.org/book/static-guarantees/design-contracts.html
shows that direction and input/output mode can only be configured AFTER enabling a GPIO. But it should be the other way around.
You always want to configure the direction first. Imagine enabling a GPIO and for a split seconds it is configured as an output GPIO even though it is supposed to be an input GPIO. You could short your circuit and therefore damage your hardware. Enabling the GPIO should almost always be your last operation on a GPIO to avoid damage or glitches.
In case of output you usually want to:

1. configure output value (high/low)
2. configure direction
3. enable the pin

Arguably 1 and 2 can be switched out since the enable bit will prevent any glitches that come from setting the direction before the output value.
Of course you don't have any of these problems if you simply add function configures the register in one go. For example create functions like configure_output(high_low: bool, enable: bool) and configure_input(mode: "u2", enable: bool).
In any case, I think the example gives a dangerous recommendation.

[BartMassey]

This is fair. Real HALs require you to configure GPIO mode and direction simultaneously with initializing the pin: see for example nrf52833_hal. The checks for enabled in the mode and direction methods should not be there given the description of the imaginary GPIO register, although the checks for mode matching direction are required. This is true both for the design of the run-time and typestate interfaces, I think.

A pull request would be welcome!