Cosa significa "monotonicità" nel contesto della mutabilità

Sto leggendo The Rust Programming Language e ho trovato il seguente passaggio:

Ricorda che scrivere su una struttura non è un'operazione atomica e molte funzioni come vec.push()possono riallocare internamente e causare comportamenti non sicuri, quindi anche la monotonia potrebbe non essere sufficiente per giustificare UnsafeCell

È appena uscito dal nulla nel libro e ho avuto delle difficoltà online a cercare di trovare cosa significhi esattamente in questo contesto. Troppe informazioni riguardano il concetto di "monotonicità" delle funzioni matematiche, che già conoscevo ma apparentemente non è molto utile.

Mi è sembrato di trovare solo questo articolo che ne parla.

Ora, oltre a rispettare l'uguaglianza in modo ovvio, includo anche la stipula secondo cui un programma funzionale deve rispettare la monotonia delle osservazioni. Cosa intendo con questo? Deve essere che una volta che hai osservato qualcosa in un determinato momento, ciò non cesserà di essere evidente in futuro. Ciò è analogo alla proprietà di monotonicità nella semantica di Kripke o Beth.

Tuttavia, anche questo è abbastanza astratto e non sono sicuro che parli della stessa cosa.

L'autore sembra usare lo stesso concetto (generale) di "monotonicità" della matematica pura.

Usando l'esempio di a vector, se la dimensione di una particolare istanza di vectorè monotona, sembrerebbe ragionevole supporre che la posizione di memoria di qualsiasi pushelemento precedentemente modificato non verrà successivamente modificata, e quindi che sia sicuro cambiare direttamente il valore di quell'elemento senza dover sincronizzarsi con le vectorsuccessive pushoperazioni.

Questa ipotesi sembra ragionevole per lo stesso motivo per cui sembra ragionevole supporre che la posizione di memoria di un elemento precedentemente spinto su uno stack (non circolare, basato su array, illimitato) la cui dimensione è strettamente crescente non sarà influenzato da un futuro pushoperazione. Ciò è in contrasto con uno stack su cui vengono invocate entrambe pushe le popoperazioni, e quindi la posizione di memoria di un elemento precedentemente spinto può essere "rimossa" da popun'operazione, e quindi disponibile per essere assegnata di nuovo (cioè modificata) da un pushoperazione successiva .

Il punto dell'autore è che questa ipotesi non è corretta, poiché anche in una struttura di dati le cui dimensioni sono in costante aumento, inserimenti futuri possono influire su elementi precedentemente inseriti innescando una riallocazione interna di qualche tipo che è distinta dall'effetto "logico" dell'inserzione .