[OT] Move semantics in a nutshell

[Timon Gehr]

On 11/9/25 17:35, monkyyy wrote:
> On Sunday, 9 November 2025 at 10:19:33 UTC, Timon Gehr wrote:
>> On 11/9/25 01:31, monkyyy wrote:
>>>
>>> When defining an opIndex you got yourself an int, and plenty of 
>>> context maybe just try solving the problem then and there. I suggest 
>>> making a singular ugly trade off, instead of the piles and piles of 
>>> complexity c+ + and rust just inject into the core language and 
>>> excited to talk about their massive amounts of complexity, slow 
>>> compiles, and 10000 man hours solutions.
>>
>> There is no panacea and if you think you found one you are probably 
>> wrong.
> 
> I know yall opinions

We are a group with a diverse set of opinions. I also don't think you 
actually know my opinions. It appears to me that we barely speak the 
same language sometimes.

> on actually failsafe code,

Oh neat, another invariant.

Completely fail safe code (i.e., with a correctness guarantee that it 
will not cause UB or crashes assuming the hardware is able to maintain 
its invariants) does not exist if you are running an OS, due to the 
potential of out of memory errors. Furthermore, (conditional) fail 
safety does not establish any sort of liveness properties, so your 
programs can also just stop responding to inputs or producing outputs 
while it cycles through now meaningless bit patterns in RAM, which is 
arguably an even more severe problem than a crash. Of course, it could 
also just start overwriting your hard disk with random garbage, which is 
even worse. It can also be vulnerable to an arbitrary code execution 
exploit, etc.

Anyway, aiming for fail safety first is nice for some things (e.g., in 
some games, getting a "correct" result is usually less important than 
not crashing), but it is not always the right tradeoff. It's really 
annoying to debug and it is not always possible, e.g. if you interact 
with the OS or libraries.

Invariants are also not saying "the program crashes sometimes", they are 
saying "the program only uses these specific combinations of bit patterns".

> but you jumped from "make one ugly tradeoff" to "panacea"
> ...

No, there was more context. You were literally saying you solve 
everything C++ and Rust are trying to address with this one ugly tradeoff.

> ```d
> import std;
> template innate(T){
>      T innate;
> }
> struct myarray(T){
>      T[] data;
>      ref T opIndex(int i){
>          if(i < 0){
>              return innate!T;
>          }
>          if(i >= data.length){
>              return innate!T;
>          }
>          return data[i];
>      }
>      //todo more op overloads
>      alias data this;
> }
> unittest{
>      myarray!int foo;
>      foo[-1000]=3;
>      foo[1]=6;
>      foo.map!(a=>assert(0));
>      foo~=1;
>      foo~=[2,3];
>      foreach(e;foo){
>          e.writeln;
>      }
> }
> ```
> 
> People make stupid problems, an opIndex is a function, I give an int(and 
> I do mean int, size_t is bad design) and I expect a T back, I use my 
> huge, massive brain to consider all possible ints given the context of 
> my data structure.
> 
> I dont know how for mere mortals to handle the *manual data flow 
> analysis* involved with this 2^32 by 2^64 possibility space; but perhaps 
> you could be convinced it will in fact not crash.
> ...

I am not sure why I should particularly care about this program, it does 
not seem like something I would get utility out of running. As I said, 
the problems that C++ or Rust try to address with their type systems pop 
up at a larger scale.

In any case, I can perhaps prove that this will not crash assuming some 
sort of ideal semantics in particular relying on invariants established 
by the compiler tying the source code to the execution behavior and some 
assumptions on the execution environment. In practice though it might 
fail with e.g. OOM, or because stdout cannot be written to, or maybe we 
can do some shenanigans with `--DRT=` arguments, etc. There are plenty 
of ways your code can still crash.

In the end, a crash is nothing other than a particular kind of bit 
pattern in your computer's memory, and "not crashing" is an invariant 
you are seeking to establish.

I however usually care about more than it just not crashing (and at some 
point, an uncontrolled blizzard of random garbage behaviors or freezing 
up or externally controllable code execution becomes way worse than even 
a crash). Furthermore, dependencies I have to interact with will still 
crash when fed random garbage. Being able to handle exceptions and for 
some applications even errors is usually a better tradeoff for me.

>> Look who is relying on language invariants and OS invariants now.
> 
> The size of ints is hardware level and n^2. Its not the yours or walters 
> or even c's. Maybe it was boole's maths.
> ...

You are relying on so much more than the size of ints. Anyway, it stands 
that it makes little sense to say one should not consider invariants 
important because C++ or Rust have some questionable designs.

> That would be correct in any statically typed language..

Even in some dynamic ones. Exactly my point.