Suggestion: object const'ness

Hasan Aljudy hasan.aljudy at gmail.com
Sun May 21 16:58:57 PDT 2006


Tom wrote:
> Hasan Aljudy escribió:
> 
>> Tom wrote:
>>
>>> Derek Parnell escribió:
>>>
>>>> .
>>>>
>>>>>
>>>>> 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.
>>>
>>>
>>>
>>> If you read just below you'll notice I was referring to obj1 as the 
>>> object and not as it's reference.
>>> |
>>> V
>>>
>>>>>    and do possibly 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.
>>>
>>>
>>>
>>> Exactly, no one knows why, it's simply useless. At present, in D is 
>>> perfectly pointless (merely informative) to use 'in' with reference 
>>> parameters, at least for the 99% of the cases.
>>>
>>>>> 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++, ...  ;-)
>>>
>>>
>>>
>>> I know that Derek. Just that *many* of the users that come to D, 
>>> don't know if you realize it, comes from the C++ world. It's 
>>> understandable, we like the features of C++ but hate the syntax (and 
>>> other stuff) and we see D as a better C++. It's perfectly natural to 
>>> try to achieve the same things in D that we've achieved in C++. Don't 
>>> be afraid, I'd hate to see D become another C++ (and that's not gonna 
>>> happen for sure).
>>>
>>> For C++ users, 'in' parameters (for references) are 'const Obj &o', 
>>> inout/out parameters are 'Obj &o'. When you see that on a signature 
>>> you can be "sure" (there's always some reasonable trust in the 
>>> middle) the function will not modify the object (you don't care about 
>>> the object reference). In D in/out/inout are just a disappointment 
>>> (for C++ users). I've dreamed to see that keywords used with the same 
>>> meaning as what I've mentioned above.
>>>
>>>> --Derek Parnell
>>>> Melbourne, Australia
>>
>>
>> "D is not C++" implies the following:
>> Don't try to achieve things the same way as in C++!!
>>
>> It's not just the syntax that's different, it's a lot of features too.
>> For example: objects are always by reference, never by value.
>> This make for a huge difference; it results in a completely different 
>> behaviour in many situations. (for the better).
>>
>> I would advice you to try Java for a while, maybe it can help you get 
>> rid of useless C++ idioms. :)
> 
> 
> I work with JAVA as well. I like it as a language but I hate its VM, its 
> gigantic JDK and its slowness. Native compiled Java would be great if 
> you ask. Anyway I think I get your point.
> Just a few questions, is in/out/inout useful for you in any way? 
> Wouldn't it be more honest to remove in/out/inout and replace it for 
> some kind of 'byref' attribute?
> 
> Regards,
> -- 
> Tom;

This is just my opinion .. I don't think it's a big deal though, but 
since you asked, here's what I think:
I think a "ref" or "byref" keyword would be more meaningful than "inout".
"in" is the default and shouldn't need a keyword anyway.
"out" is somewhat similar to inout (see my post/question in the learning 
NG); it offers no special functionality, and I think it's rarely ever 
used. so it's really not needed.

PS: "in" and "out" would still be keywords; they're used in function 
contracts.



More information about the Digitalmars-d mailing list