Using in as a parameter qualifier

[Shriramana Sharma]

Thanks to all who explained the various issues. Some more questions:

On Fri, May 31, 2013 at 9:28 PM, Ali Çehreli <acehreli at yahoo.com> wrote:
> What the error message is saying is that you can declare it just to disable
> its use:
>
> struct Pair {
>     double x = 10.75;
>     double y = 20.25;
>
>     // Default constructor disabled
>     @disable this();
>
>     // Users must use another constructor:
>     this(double x, double y) { this.x = x; this.y = y; }
> }
>
> As you see, you must also provide a proper constructor that is appropriate
> for that type.

Sorry but I still don't get it -- if a default constructor is
disallowed for struct-s by the language itself, why should I have to
*tell* the compiler to disable it?

> However, :) if you are going to make a copy of the argument anyway, always
> take a struct by-value. That works with both lvalue and rvalue arguments and
> in the case of rvalues, you will get the automatic move semantics.
>
> My choice is by-value for structs unless there is any reason not to.

So where is the cut-off point? I mean, by-value means a copy is done
every time the function is called right? So how heavy (in terms of
sizeof) would a struct have to be to make passing by ref more
efficient than passing by value?

> be slower than taking by-value. This is the idiomatic way of writing
> operator= in C++:
>
>     Foo & operator= (Foo that)
>     {
>         this->swap(that);
>         return *this;
>     }

This assumes that Foo defines a swap method. Maybe good for lists and
such. ... One sec... if you take an argument by value, it means the
copy constructor would be called. So how is this really more efficient
than taking const Foo & as an argument? Is it the code savings that
would be done by avoiding duplicating the copy-constructor code in
operator= too?

>> it makes optimization sense to not copy it but just automatically provide
>> a
>> reference to it right?
>
> Unless the language makes a guarantee about that we cannot take the address
> of the parameter and save it. We wouldn't know whether it is a copy or a
> reference.

Can you explain? It's not very clear to me.

> Another reason is less surprise because structs have copy semantics by
> default.

Makes me start thinking I should use class rather than struct for my
pair even though there is no polymorphism etc required. Then I can
just say abs2(const pair). It would automatically be a reference.
Would that be inadvisable for any reason? My program would use pairs
heavily. Would the heap allocation/deallocation/GC be a burden if I
made the pair a class?

-- 
Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा