cast(immutable) vs extra variable

[Jonathan M Davis]

On Thursday, September 19, 2013 18:47:12 Daniel Davidson wrote:
> Multi-part question:
> 
> 1) Why does the last line fail? If cast to immutable how is it
> different than z? I know it is related to the ref. I'm using ref
> because I think it is likely more efficient - so assume the
> char[16] were really char[1024].

As Namespace pointed out, ref (including const ref) does not accept rvalues - 
only lvalues.

> 2) If I got rid of the ref, how many copies of the data would be
> made? And without looking at assembly what is a good way to
> answer this question? I've tried to add this(this) to other Stuff
> type structures to print when they are being called, but that
> does not work because no logic can be in the default constructor.

That would depend on what functions are being called and could change if the 
code is refactored. The compiler will do moves instead of copies whenever it 
can, so the situation is far better than with C++ (particularly pre-C++11), 
but how many copies will actually be needed depends on what the functions are 
doing and how many functions get called. Writing a postblit constructor would 
be the only way that I know to track it, though I'm not sure why the lack of 
default construction would be a problem, unless you're trying to name all of 
your objects and print out exactly how many each individual one is copied. But 
if you want to do that, then create a constructor that you pass the name, and 
don't use a default-initialized value.

> 3) Also, is storing immutable(STUFF) in a struct in the general
> case (as opposed to just this one) useful or silly?

As soon as you have a const or immutable member in a struct, you can't ever 
assign anything to it, even if all of its other members are mutable (you could 
assign the individual, mutable members but not the whole struct). That means 
stuff like if the struct is ever default-initialized, you can't even give it 
another value, which tends to mean that you can't use such a struct in places 
like arrays.

All in all, I think that it's pretty much always a bad idea to have a struct 
with const or immutable members. It's just begging for problems. Tail-const or 
tail-immutable is fine, because the members themselves aren't const or 
immutable (just what they refer to), but having them be directly const or 
immutable is a bad idea IMHO.

- Jonathan M Davis