On Mon, 22 May 2006 07:44:55 +1000, Tom <ihate@spam.com> wrote:


> 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?

No. I don't come from either C++ or Java background. The 'in' no longer scares me now that I can think in D too. In those situations that are critical that an object/array passed as a parameter is not modified, I pass a copy of that object/array. In other words, as I know that the compiler is not helpful in this situation, I take responsiblity for the application.

Likewise, if my class returns a reference to something that only the class is allowed to modify, I return a copy of that data instead. I know that DMD will not help me so I take control.

Yes I know that this is more work on my part and more runtime overheads, but it works. So in that sense, DMD is not as sophisticated and helpful as C++, but it offers other benefits that outweight this blemish.

-- 
Derek Parnell
Melbourne, Australia

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.

On Sun, 21 May 2006 17:58:57 -0600, Hasan Aljudy <hasan.aljudy@gmail.com> wrote:
> 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".

I disagree. "byref" is _less_ meaningful (read on for my reasoning).

> "in" is the default and shouldn't need a keyword anyway.

Agreed. It's probably only there for the Derek's of this world :)
Each to their own I say.

> "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.

I use "out" in cases like:

void loadX(out int a, out int b, out int c);

where X can be anything you like i.e. UserDefaults or ServerSettings or whatever. Where the types need not be 'int', where they would have more meaningful names than a, b, and c. Basically in any situation where you want to return more than 1 "result" from the function.

(yes, there are other ways to do this sort of thing i.e. returning a composite data type struct/class etc)

The fact that "out" initialises the variables to their init values is important, just like D's other instances of default initialisation for variables. The other reason you would use "out" and not "inout" is that "inout" implies "input" as well as "output" and that's clearly not the case here. So saying "inout", or not saying anything (byref) is wrong, confusing or _less_ meaningful.

In short, "byref" says "this is being passed by reference" whereas "out" says "this variable will recieve output from this function", likewise "inout" says "this variable contains input and will/may receive output from this function". In short, "out" and "inout" hold more meaning than "byref" would.

In actual fact, "out" and "inout" don't actually state the variable will be passed by reference, that's just how it happens to be implemented. There may in fact be no other way to do it, but that's not the point. The point is that "out" and "inout" do not mean "this is being passed by reference", they never have (IMO, of course).

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

To my mind "out" and "inout" are solely function contracts. They just happen to cause pass by reference (because that's how they achieve their goal).

I don't want to re-start the old "byref" discussion, but, I still cannot see a need for it(byref). If you want to pass a struct, or other value type, as input, by reference, you just use a pointer, eg.

struct A { int abc; }
void foo(in A* p) {
  //note D automatically de-references the pointer for you (in most cases)
  p.abc = 5;
}

Until we get some sort of const system, the 'in' parameter, the pointer 'p', is all that is 'protected' from modification, it's contents are open to modification.

Now, you _could_ pass it by value, that would protect it's contents, but what about the contents of it's contents, for example:

struct A { char *str; }
void foo(A a) { a.str[0] = 'a'; }

any reference contained in a struct is itself protected, but not so the data to which it refers. Any const system would ideally therefore need to handle several layers of protection, perhaps my preventing the use of reference types as an lvalue?


All in all, I guess all I'm trying to say is that I like "out" and "inout" I think they perform a valid and valuable task, in fact they're a big step up from the days of using a pointer or passing by reference because they add _more_ meaning, they actually tell you what the function programmer intended to do with the parameter.

I would like to see some sort of const guarantee and I think "in" should play a part, I think by default parameters should be passed as "in" (as they are) and should be protected/const/read-only by default.

Regan

On Mon, 22 May 2006 12:50:47 +1200, Regan Heath wrote:

...

> All in all, I guess all I'm trying to say is that I like "out" and "inout" I think they perform a valid and valuable task, in fact they're a big step up from the days of using a pointer or passing by reference because they add _more_ meaning, they actually tell you what the function programmer intended to do with the parameter.
> 
> I would like to see some sort of const guarantee and I think "in" should play a part, I think by default parameters should be passed as "in" (as they are) and should be protected/const/read-only by default.

Yeah ... like Regan said.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocracy!"
22/05/2006 11:25:43 AM

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.

ChristopheBourez schreef:
> It should be interesting to have a const'ness ala C++, I mean, the ability to
> declare methods that do not modify the state of objects.
> 
> class X { public:
> void ModifyState?();
> void DontModifyState?() const;
> };
> 
> Any comments?
> 
> Christophe
> 
> 

Endless discussion which has followed on this, discussing pros and cons about D vs. C++ and so forth.

What about the following:

using another parameter such as:

locked

void foo(in locked Bar bar) {
	bar.setValue(10); // Compiler error
	int i = bar.getValue(); // OK
}

The keyword would modify the behaviour from in, which only is about the actual stack value passed to the function, to be completely locking all calls (changing the reference, changing the object contents, changing the contents within the object contents etc).

It would be possible using the same keyword prepended in front of functions themselves:

class Bar {
	int _i;
	void setValue(int i) {_i = i;}

	// Can't modify _i contents nor (if a reference) the
	// contents within.
	locked int getValue() {return _i;}

}

How about this?