[OT] Move semantics in a nutshell

[monkyyy]

On Saturday, 8 November 2025 at 22:45:29 UTC, Timon Gehr wrote:
> On 11/8/25 17:38, monkyyy wrote:
>> 
>> Whats the (very important) invariants on int?
> code

> The way you are conceptualizing this makes no sense to me.

Hot take: `int` has no (existence) limitations, your code you 
want to hint at at some function failure but you didn't do that

```d
void foo(int i){assert(i!=3);}
```

In this code, int still is a perfect data type, its foo that 
breaks if you do the unthinkable and call it with 3.

```d
int[256] myarray;
ubyte myindex;
ref int get()=>myarray[myindex];
```

This code does not have an existence invariant unless you want to 
claim the compiler or os will break in some profoundly stupid 
way. In which case I'm not trying to fix it.

If d does "move", it will get c++ "move" complexity to some 
degree. C++ makes some stupid problems to even have. I suggest 
you avoid having stupid problems. I will not be writing code the 
correctly handles zvalues 7 op overloads with fvalues.

---

Allocation (or "that data better exist when I ask for it") isn't 
that hard, you dont need smart pointers with dozens of overloads 
and 100 pages of "undefined behavior" that I aint reading or a 
mathematical proof engine and lots of shame about safety; big 
arrays, one op overload `opIndex`, the range api with 3 
functions. Maybe a sumtype and nullable here or there.

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.