What ever happened to move semantics?

[Walter Bright]

On 2/28/2024 1:03 PM, Timon Gehr wrote:
> No, the idea is that the compiler enforces that it is indeed the last use and 
> produces a compile-time error message if it cannot prove that it is the case.

DFA works with mathematical reliability (absent compiler bugs). The optimizer 
relies heavily on DFA; if DFA was unreliable the whole edifice will fall apart. 
Leave move vs copy to the compiler. The move vs copy/destroy choice is an 
optimization, and should be semantically thought of it that way.

> Yes. It still holds that one may want to make sure that a value is really moved 
> at a given point. Sometimes this matters. Anyway, this is by far not the most 
> important point.

If more language features are needed to work around bugs in the DFA, you've 
failed as a language designer/implementer. :-/

Last use DFA can be implemented in a mathematically correct manner. The downside 
to DFA is it slows down the compiler, which concerns me in adding it to the 
front end semantics. I'm guessing is that's a reason why Rust has a reputation 
for slow compiles. (C++ doesn't have an excuse!)


>> A nice feature of this is that the type of a variable can be changed on 
>> redeclaration. Note that Rust allows this.
> 
> This is a relatively common idiom in languages that support moves. It is 
> annoying if you have to invent a new name for each intermediate result.
> 
> One use case would be type state:
> 
> File!(FileState.flushed) file = open("file.txt");
> File!(FileState.buffered) file = file.write("hello ");
> File!(FileState.buffered) file = file.writeln("world!");
> // file.close(); // compile time error
> File!(FileState.flushed) file = file.flush();
> file.close(); // moves "file"
> 
> // file.write("hello"); // compile time error
> 
> Assume you have some declarations like these and you want to comment out part of 
> the statements. It would now be annoying to have to rename variables.
> 
> I.e., you want to use the same name for different versions of the same thing, 
> similarly to how you do not have to change the name of a variable when assigning 
> to it.

Interesting that you bring that up. I've been slowly leaning towards the "single 
assignment" style, where a variable is only assigned to once, when it is 
initialized. Sort of a "head const" thing. Some languages enforce this (can't 
remember which ones).

I find it makes code more readable.

I get the feeling that allowing not only the contents, but the type of the 
variable change after re-assignment makes for less coherent code.

I'm not sure why, but I find Rust code hard to read. Maybe that's part of it. I 
like the O/B system so much I implemented it in D (@live), not only that, but 
have begun adopting it as my own coding style. And it looks sooo much nicer in D 
syntax!


>> We already disallow shadowing declarations, and that has prevented a number of 
>> bugs at least in my own code (they're very difficult to spot with a visual 
>> check).
> 
> The reason why shadowing is error prone is that multiple variables with 
> overlapping lifetimes are in scope and the compiler arbitrarily picks one of 
> them. This case is different, as only one variable of the same name exists at 
> any given time. This is not error prone.

I've made that error myself now and then, usually as a result of moving code 
lines about.

> Requiring unique names is more error 
> prone in this case, as you can accidentally copy an older version of a variable.

I can't remember making that error :-/


> Anyway, this is not the most important thing, please do check out the points I 
> initially included in my review. This point is just something I had forgotten to 
> include.

Of course. This was just an easy to respond to issue.

But a caveat. I'm kinda swamped at the moment. I'm working on some cool stuff 
for the upcoming DConf. I also wrote the Move/Copy/Forward DIP before I worked 
on the O/B system for D. The whole Move/Copy/Forward needs to be studied in the 
context of how it fits in with O/B. This is going to need some careful study.