Suggestion: object const'ness

[Derek Parnell]

.
>
> If you see a signature like this:
>
> void doSomething(in SomeObj obj1, inout SomeObj obj2);
>
> You'll instantly expect that function "doSomething" doesn't modify obj1

But it doesn't modify 'obj1'. Remembering that 'obj1' is the reference to  
the object and not the object itself.

>    and do posibly modify obj2 (the object and not it's reference). Why  
> would you want (in the most of the cases) to make "in" the reference  
> itself?

Don't know. Simplier I guess.

> Currently D 'in Obj p' "behaves as" the rarely-used 'Obj *const p' and  
> not as the widely and common 'const Obj *p' of C++ ("behave as" because  
> I use pointers instead of references to illustrate the underlying  
> behavior and C++ references are always const).
>
> Const is another level of protection against unintended behavior (i.e.  
> bugs). In C++, const *can* be circumvented but one has to be horribly  
> explicit to do that. No way you would unintentionally do that.

So everyone repeat after me ... D is not C++, D is not C++, D is not C++,  
...  ;-)

-- 
Derek Parnell
Melbourne, Australia