Suggestion: object const'ness

[Tom]

Hasan Aljudy escribió:
> 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.

Now, at last what I wanted to hear. That's my point with "true" 
in/out/inout attributes. I mean attributes that aren't useless.
I would propose two options: remove in/out/inout and introduce some 
'byref' or make in/out/inout act as they should with reference types 
(protecting the referenced objects).

This is also just my opinion and isn't a big deal either, just some 
thoughts.