Using in as a parameter qualifier

[Shriramana Sharma]

On Fri, May 31, 2013 at 12:12 PM, Ali Çehreli <acehreli at yahoo.com> wrote:
>>    double x,y ;
>>    this () {}
>
> That is not allowed. In D, every type has the .init property, which is its
> default value.

Hm can you clarify that a bit? If I actually try it I get:

pair.d(14): Error: constructor pair.pair.this default constructor for
structs only allowed with @disable and no body

>> Consider a function that operates on a pair:
>> double abs2 ( pair a ) { return a.x * a.x + a.y * a.y ; }
>> In C++ the function signature would be: double abs2 ( const pair & a )
>> So I thought const ref pair a would be appropriate in D -- is that right?
>
> Yes:
> double abs2(ref const(Pair) a) { /* ... */ }

But is this the idiomatic D way of doing things? I mean, would one
normally prefer in or ref const(T) which somehow seems more awkward
than even const T &?

> 'in' is nothing but 'scope const' (scope is not implemented yet):

Does that mean "this is const within the current scope"?

And does "in" *not* guarantee that the object is *not* copied? I mean,
if a parameter input to a function is read-only, it makes optimization
sense to not copy it but just automatically provide a reference to it
right? So I would expect in to mean const ref -- doesn't it work that
way, and if not, why not?

> double abs2(Pair a) { /* ... */ }
> This one has the added benefit of compiler's automatic moving of the value
> to the function. You know that 'a' is a copy of the argument so you can
> safely move it for use later.

I don't understand; can you please clarify that. I understand that a
is a copy of whatever pair is passed to it, so where do I move it and
why would I want to use it later?

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