Earlier quoted context omitted.
From 1983: Although "optimum" is an absolute term, like "unique", it became common verbal practice to make it relative: "not quite optimum" or "less optimum" or "not very optimum". Mel called the maximum time-delay locations the "most pessimum". https://users.cs.utah.edu/~elb/folklore/mel-annotated/node1....
Even worse! ‘Optimum’ in English is a noun, not an adjective.
Choosing a more optimal `String` type
21–24 of 24 posts
Re: Choosing a more optimal `String` type
#22Aaah, `Cow`, the unloved child ...
Re: Choosing a more optimal `String` type
#23There should be a from_raw_parts-like interface for Arc that can construct one out of a pointer to a T + control block. That way you can shift the string data over and stick the control block inline (which is how I assume it's laid out in memory) and convert String to Arc for free (well not free, shifting takes O(n), but so does the copying in Arc::new, so in the end you do end up avoiding an allocation for free)
Unfortunately, this can't really be done efficiently with how allocation works in Rust. A String is always allocated with alignment 1, but an Arc's control block requires usize alignment. An allocated pointer can't be deallocated with a different alignment than it was allocated with, nor can its alignment be changed when it is reallocated. Thus, the from_raw_parts() idea would be unusable for any types with less than…