[OT] Move semantics in a nutshell

[Timon Gehr]

On 11/9/25 01:31, monkyyy wrote:
> 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,

`int` gives a meaning to all bit patterns. Not all numbers are the right 
answer, or even a sensible answer. It's inevitable that a useful program 
will have some invariants involving `int` data, even if your programming 
language never crashes and has no UB. Invariants in general touch more 
than one variable at a time, data type invariants are are just a method 
to package them in a way that is often a bit more manageable.

> your code you want to 
> hint at at some function failure but you didn't do that
> ...

My code was a fine illustration of the point that just because every bit 
pattern is a valid `int` you are not banishing invariants involving that 
`int`. Not every bit pattern in RAM is made equal. Some of them are 
actually preferable.

> ```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.
> ...

Clearly `int` is not the ideal type for this function argument.

> ```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.
> ...

Look who is relying on language invariants and OS invariants now.

> If d does "move", it will get c++ "move" complexity to some degree. C++ 
> makes some stupid problems to even have.

The C++ design is uniquely... C++.

> I suggest you avoid having stupid problems.

Not having moves leads to stupid problems. Breaking strong invariants 
leads to stupid problems too, but there is plenty of prior art with 
`T.init`.

Anyway, I have my preferences, but I don't get to have the final say of 
what features make it into D in what form, nor do I have the spare time 
required to make a convincing case for my preferences. Personally I am 
not a fan of either `T.init` nor husks, but I think moves are useful.

In the real world, you will always have some stupid problems, you can 
just try to choose which ones.

> I will not be writing code the correctly handles 
> zvalues 7 op overloads with fvalues.
> ...

This is simply not what is being proposed. What is being proposed though 
is something that requires weaker invariants from all movable types, 
which demonstrably leads to stupid problems. Ironically you attack 
invariants as being somehow a C++ or Rust thing that magically 
contributes to their problems. No, invariants are a thing, programming 
languages have to contend with them, and there are better and worse ways 
to do it.

The video goes like "if not A then B". You go like "B is stupid, hence A 
is stupid".

> ---
> 
> Allocation (or "that data better exist when I ask for it") isn't that 
> hard,

Famous last words. Anyway, even if it is not that hard, getting it wrong 
even once can have (and often does have) devastating consequences. 
People are imperfect and having a lot of bugs that are avoidable using a 
better programming methodology is also a stupid problem.

> 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.
> ...

Yes, types with internal invariants such as arrays, sumtype and nullable 
are indeed useful for dealing with memory allocation. Bonus points if 
they are movable.

But these don't solve all stupid problems. Now you e.g. often enough 
have to deal with `int`s that are actually references.

What works in 100-line programs often enough no longer works at scale. 
What works for you may not work for other applications.

> 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.