Thank you!

[Ali Çehreli]

On 9/7/21 9:36 PM, Tejas wrote:

 >>> S _s;
 >>>
 >>> S s() {return _s;}

[...]

 > Do you really think people who are writing code like that expect a
 > temporary to be generated?

I think so. Even if they don't, I can't imagine this being a big 
surprise in the future; a little test would reveal that _s was not changing.

 > What else could be the purpose of returning
 > an existing struct and using it as an `lvalue` if not to modify it?

The returned copy is not an lvalue; it is an rvalue.

 > I feel we would be better off if the same
 > ```d
 > <your_var_name> is not an lvalue and cannot be modified
 > ```

rvalues cannot be assigned to but they can be modified. The reason I 
don't find this surprising must be my past experience with C++, where it 
is exactly the same.

 > error that is raised for other similar cases came up in the original
 > version of this code. It will catch a (almost 100% guranteed) runtime
 > error during compile time _and_ be consistent with the rest of the
 > language.

How? Being value types, structs are consistently passed and returned by 
value. Otherwise, we wouldn't be able to write a factory function:

S makeS() {
   return S();  // Should this be returning a reference to a temporary?
}

Ali