On Thu, 16 Feb 2006 22:53:25 +0000 (UTC), S. <S._member@pathlink.com> wrote:
> In article <dt2hth$132q$1@digitaldaemon.com>, Dave says...
>>
>> In article <dt2faq$105d$1@digitaldaemon.com>, S. Chancellor says...
>>>
>>> In article <dt1uqc$dut$1@digitaldaemon.com>, David Medlock says...
>>>>
>>>> import std.stdio;
>>>>
>>>> class A { int x = 1; }
>>>> struct B { int x = 1; }
>>>>
>>>> void one( in A a )
>>>> {
>>>>  a.x = 5;
>>>> }
>>>>
>>>> void two( in B b )
>>>> {
>>>>   b.x = 5;
>>>> }
>>>>
>>>> void main( char[][] args )
>>>> {
>>>>   A foo = new A();
>>>>   writefln( "%s", foo.x );
>>>>   one( foo );
>>>>   writefln( "%s", foo.x );
>>>>
>>>>   B bar;
>>>>   writefln( "%s", bar.x );
>>>>   two( bar );
>>>>   writefln( "%s", bar.x );
>>>> }
>>>>
>>>>
>>>> prints:
>>>> 1
>>>> 5
>>>> 1
>>>> 1
>>>>
>>>> This is reference versus value semantics.
>>>> The class object is passed by reference, the struct is passed by value.
>>>
>>>
>>> Oops.  In my test I got confused about what & was giving me.  You are right.
>>>
>>> However, You've just proven there's absolutely nothing wrong with just giving me
>>> an inref keyword that is essentially an alias to the inout keyword.  Which is
>>> what I requested.
>>>
>>> Have a nice day.
>>>
>>> -S.
>>>
>>
>> How about one keyword: 'byref' as in 'in', 'out' and 'byref'. It's grep-able and
>> should be pretty much universally understood by anyone except total programming
>> newbies (who probably would have as much trouble grasping 'inout' anyway).
>>
>> Heck, modern BASICS's and even things like Windows script have 'ByVal' and
>> 'ByRef' and I've never heard any complaints there - they are well understood
>> even by developers who are not real familiar with pointer syntax or semantics.
>>
>> int foo(byref int x) { ... }
>> foreach(byref double d; darr) { ... }
>>
>> As for keyword consistency using the words in and out -- 'in' will rarely be
>> used anyway and for my money could be removed as a keyword, unless it inherits
>> some special meaning w.r.t. 'constness' or something along those lines.
>
> One of the reasons there's out/inout/in keywords exist is to provide
> implementation details in the parameter list.

Does it say that somewhere in the D docs? Has Walter said that was his intention? I'm not saying it wasn't I'm just saying I haven't see/read that anywhere, all I can really assume is that out/inout/in are there to provide the effect they provide, and nothing more.

> But also, while we're at it,
> since any out keywords are obviously by reference, lets make that automatic?
> Whoops, we forgot we sometimes want in keywords which are references.

In this case, I use a pointer.

> And to answer your question, maybe eventually the different keywords will impart
> protections.  For example, the out keyword overwrites the variable with it's
> initializer before allowing you to use it.

Sure, we could invent a new keyword "byref" and in the future apply the protection to it, but, who's to say the protection _ever_ gets implemented? The keyword would initially be no different to a pointer, so, it will start off as another way to do the same thing and it might just stay that way forever. It hardly seems worth it, to me.

Regan

On 2006-02-16 15:25:07 -0800, "Regan Heath" <regan@netwin.co.nz> said:

> Does it say that somewhere in the D docs? Has Walter said that was his  intention? I'm not saying it wasn't I'm just saying I haven't see/read  that anywhere, all I can really assume is that out/inout/in are there to  provide the effect they provide, and nothing more.
> 
>> But also, while we're at it,
>> since any out keywords are obviously by reference, lets make that  automatic?
>> Whoops, we forgot we sometimes want in keywords which are references.
> 
> In this case, I use a pointer.
> 
>> And to answer your question, maybe eventually the different keywords  will impart
>> protections.  For example, the out keyword overwrites the variable with  it's
>> initializer before allowing you to use it.
> 
> Sure, we could invent a new keyword "byref" and in the future apply the  protection to it, but, who's to say the protection _ever_ gets  implemented? The keyword would initially be no different to a pointer, so,  it will start off as another way to do the same thing and it might just  stay that way forever. It hardly seems worth it, to me.

If you don't think that was his intention, why didn't he make it a byref keyword to begin with?  Why have in, inout, and out?  Why even have out? It's hardly worth it to have out since it doesn't do hardly anything anyways.  In fact it adds overhead by setting the parameter to it's initializer.  Does having in/out/inout make coding more clear than just ByRef?  If so, does using inout where you are not using the parameter as both an in and an out parameter obfuscate things?

D has an ever expanding plethora of features which are useless to quite a few people.  More being added by the minute, why not a simple aliased keyword?  Nobody said you had to use it.

-S.

On 2006-02-16 09:23:17 -0800, S. Chancellor <S._member@pathlink.com> said:

> In article <op.s42nznti6b8z09@ginger.vic.bigpond.net.au>, Derek Parnell says...
>> 
>> On Fri, 17 Feb 2006 00:51:05 +1100, Bruno Medeiros  <daiphoenixNO@SPAMlycos.com> wrote:
>> 
>> 
>> [snip]
>> 
>>>>> The 'in' modifier applies to the array reference, not the data.
>>>> Yes I know that! But I didn't pass a reference, I passed an array. The
>>>> compiler passed the reference. But yeah, I know...this is the whole  point
>>>> that people have been on about for ages. I just thought I'd highlight
>>>> another trap for coders. You may think your passing the array but you
>>>> aren't really. Nasty things could happen here.
>>>> 
>>> 
>>> How is that surprising, or another trap for coders ? It's the way it is  done since old C to any modern day C-family language. Static arrays are  (like) reference types.
>> 
>> It is surprising if one does not have a C background and one uses normal  reasoning.
>> 
>> My code said "pass this array to the function". The compiler didn't do  that. We are told that fixed length arrays and structs are created on the  stack not the heap but that classes and variable length arrays are heap  things. We are told that heap entities are passed by reference. We are  told that structs are passed by value, so one could innocently assume that  fixed length arrays, being stack entities like structs, are also passed by  value.
>> 
>> This topic doesn't warrant further consideration.
> 
> 
> It's interesting to note that classes passed via 'in' parameters are still
> passed by VALUE.  Not reference.
> 
> Just some food for thought.
> 
> -S.

Ignore my dipshit comment.  I ran my test incorrectly.

-S.

On Thu, 16 Feb 2006 20:24:44 -0800, S. Chancellor <dnewsgr@mephit.kicks-ass.org> wrote:
> On 2006-02-16 15:25:07 -0800, "Regan Heath" <regan@netwin.co.nz> said:
>
>> Does it say that somewhere in the D docs? Has Walter said that was his  intention? I'm not saying it wasn't I'm just saying I haven't see/read  that anywhere, all I can really assume is that out/inout/in are there to  provide the effect they provide, and nothing more.
>>
>>> But also, while we're at it,
>>> since any out keywords are obviously by reference, lets make that  automatic?
>>> Whoops, we forgot we sometimes want in keywords which are references.
>>  In this case, I use a pointer.
>>
>>> And to answer your question, maybe eventually the different keywords  will impart
>>> protections.  For example, the out keyword overwrites the variable with  it's
>>> initializer before allowing you to use it.
>>  Sure, we could invent a new keyword "byref" and in the future apply the  protection to it, but, who's to say the protection _ever_ gets  implemented? The keyword would initially be no different to a pointer, so,  it will start off as another way to do the same thing and it might just  stay that way forever. It hardly seems worth it, to me.
>
> If you don't think that was his intention, why didn't he make it a byref keyword to begin with?

Because we have pointers. :)

> Why have in, inout, and out?  Why even have out? It's hardly worth it to have out since it doesn't do hardly anything anyways.  In fact it adds overhead by setting the parameter to it's initializer.

The behaviour of 'out' achieves much the same thing as the auto initialising of other D variables. It makes it easier to debug when a function has forgotten to set it. I agree, it also tells the caller what to expect. I agree with your original statement WRT 'out', making the code clearer is "one of the reasons" for it.

I do not believe the same argument applies to "byref". It adds nothing that a pointer does not already give us. If in the future we have some sort of data protection scheme and if that scheme requires a keyword in function declarations then "byref" just might be it.

> Does having in/out/inout make coding more clear than just ByRef?

I agree, in/out/inout make coding clearer.

> If so, does using inout where you are not using the parameter as both an in and an out parameter obfuscate things?

Yes, which is why I use a pointer. A pointer passes data 'in' by reference. Yes, you can change the data it points to, but it is no different to a class or array reference passed 'in'.

> D has an ever expanding plethora of features which are useless to quite a few people.  More being added by the minute, why not a simple aliased keyword?

So.. your argument for a 'useless' feature is that there are plenty of other 'useless' features, why not add another one?

> Nobody said you had to use it.

This is true.

Regan

Derek Parnell wrote:
> On Fri, 17 Feb 2006 00:51:05 +1100, Bruno Medeiros <daiphoenixNO@SPAMlycos.com> wrote:
> 
> 
> [snip]
> 
>>>> The 'in' modifier applies to the array reference, not the data.
>>>  Yes I know that! But I didn't pass a reference, I passed an array. The
>>> compiler passed the reference. But yeah, I know...this is the whole point
>>> that people have been on about for ages. I just thought I'd highlight
>>> another trap for coders. You may think your passing the array but you
>>> aren't really. Nasty things could happen here.
>>>
>>
>> How is that surprising, or another trap for coders ? It's the way it is done since old C to any modern day C-family language. Static arrays are (like) reference types.
> 
> It is surprising if one does not have a C background and one uses normal reasoning.
> 
That I can agree with. Although most programmers should have a C-family languages background, we could clarify (by "we" I mean foremost the docs) this issue by clearly stating that static arrays are reference types, just like it's kin dynamic arrays.

> My code said "pass this array to the function". The compiler didn't do that. We are told that fixed length arrays and structs are created on the stack not the heap but that classes and variable length arrays are heap things. We are told that heap entities are passed by reference. We are told that structs are passed by value, so one could innocently assume that fixed length arrays, being stack entities like structs, are also passed by value.
> 
Thus, we shouldn't think of the way how data in a var is allocated as a means to discern parameter behavior. What we should think of, is if the data type is a value type, or a reference type.
And also: *all* variables in D are by default passed by value, including classes and arrays. What happens is that they are reference values. This  conceptualization may look similar, but it's not, and it's a very important notion to have.

> This topic doesn't warrant further consideration.
> 
Huh, why? I barely said anything, and I find the above mentioned comment relevant.


-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to be... unnatural."

S. Chancellor wrote:
> On 2006-02-16 09:23:17 -0800, S. Chancellor <S._member@pathlink.com> said:
> 
>> In article <op.s42nznti6b8z09@ginger.vic.bigpond.net.au>, Derek Parnell says...
>>>
>>> On Fri, 17 Feb 2006 00:51:05 +1100, Bruno Medeiros  <daiphoenixNO@SPAMlycos.com> wrote:
>>>
>>>
>>> [snip]
>>>
>>>>>> The 'in' modifier applies to the array reference, not the data.
>>>>> Yes I know that! But I didn't pass a reference, I passed an array. The
>>>>> compiler passed the reference. But yeah, I know...this is the whole  point
>>>>> that people have been on about for ages. I just thought I'd highlight
>>>>> another trap for coders. You may think your passing the array but you
>>>>> aren't really. Nasty things could happen here.
>>>>>
>>>>
>>>> How is that surprising, or another trap for coders ? It's the way it is  done since old C to any modern day C-family language. Static arrays are  (like) reference types.
>>>
>>> It is surprising if one does not have a C background and one uses normal  reasoning.
>>>
>>> My code said "pass this array to the function". The compiler didn't do  that. We are told that fixed length arrays and structs are created on the  stack not the heap but that classes and variable length arrays are heap  things. We are told that heap entities are passed by reference. We are  told that structs are passed by value, so one could innocently assume that  fixed length arrays, being stack entities like structs, are also passed by  value.
>>>
>>> This topic doesn't warrant further consideration.
>>
>>
>> It's interesting to note that classes passed via 'in' parameters are still
>> passed by VALUE.  Not reference.
>>
>> Just some food for thought.
>>
>> -S.
> 
> Ignore my dipshit comment.  I ran my test incorrectly.
> 
> -S.
> 
No, what you said the first time is correct. What may be incorrect is your notion of value/reference types and their argument passing.

-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to be... unnatural."

On 2006-02-16 23:46:37 -0800, "Regan Heath" <regan@netwin.co.nz> said:

>> If you don't think that was his intention, why didn't he make it a byref  keyword to begin with?
> 
> Because we have pointers. :)

We have in, out and inout too!  Why use pointers if we don't have to?

> 
>> Why have in, inout, and out?  Why even have out? It's hardly worth it to  have out since it doesn't do hardly anything anyways.  In fact it adds  overhead by setting the parameter to it's initializer.
> 
> The behaviour of 'out' achieves much the same thing as the auto  initialising of other D variables. It makes it easier to debug when a  function has forgotten to set it. I agree, it also tells the caller what  to expect. I agree with your original statement WRT 'out', making the code  clearer is "one of the reasons" for it.
> 
> I do not believe the same argument applies to "byref". It adds nothing  that a pointer does not already give us. If in the future we have some  sort of data protection scheme and if that scheme requires a keyword in  function declarations then "byref" just might be it.

I didn't ask for a ByRef keyword, I asked for a method for an in keyword to be by reference.

>> Does having in/out/inout make coding more clear than just ByRef?
> 
> I agree, in/out/inout make coding clearer.

Wouldn't it be consistent then to have a sort of "inbyref" parameter? Wouldn't that be consistent with the rest of D style, rather then a pointer, which is just vague and C-esque?

> 
>> If so, does using inout where you are not using the parameter as both an  in and an out parameter obfuscate things?
> 
> Yes, which is why I use a pointer. A pointer passes data 'in' by  reference. Yes, you can change the data it points to, but it is no  different to a class or array reference passed 'in'.

Pointers are a break from normal D style.  One of the goals of D is to provide programmers access to things like pointers, while making it so they don't have to use them 90% of the time.

> 
>> D has an ever expanding plethora of features which are useless to quite  a few people.  More being added by the minute, why not a simple aliased  keyword?
> 
> So.. your argument for a 'useless' feature is that there are plenty of  other 'useless' features, why not add another one?

If that's what you want to read...  I said there are plenty of features that are useful to quite a few people.  This one is apparently useless to you.

On 2006-02-17 06:29:43 -0800, Bruno Medeiros <daiphoenixNO@SPAMlycos.com> said:

> S. Chancellor wrote:
>> On 2006-02-16 09:23:17 -0800, S. Chancellor <S._member@pathlink.com> said:
>> 
>>> In article <op.s42nznti6b8z09@ginger.vic.bigpond.net.au>, Derek Parnell says...
>>>> 
>>>> On Fri, 17 Feb 2006 00:51:05 +1100, Bruno Medeiros  <daiphoenixNO@SPAMlycos.com> wrote:
>>>> 
>>>> 
>>>> [snip]
>>>> 
>>>>>>> The 'in' modifier applies to the array reference, not the data.
>>>>>> Yes I know that! But I didn't pass a reference, I passed an array. The
>>>>>> compiler passed the reference. But yeah, I know...this is the whole  point
>>>>>> that people have been on about for ages. I just thought I'd highlight
>>>>>> another trap for coders. You may think your passing the array but you
>>>>>> aren't really. Nasty things could happen here.
>>>>>> 
>>>>> 
>>>>> How is that surprising, or another trap for coders ? It's the way it is  done since old C to any modern day C-family language. Static arrays are  (like) reference types.
>>>> 
>>>> It is surprising if one does not have a C background and one uses normal  reasoning.
>>>> 
>>>> My code said "pass this array to the function". The compiler didn't do  that. We are told that fixed length arrays and structs are created on the  stack not the heap but that classes and variable length arrays are heap  things. We are told that heap entities are passed by reference. We are  told that structs are passed by value, so one could innocently assume that  fixed length arrays, being stack entities like structs, are also passed by  value.
>>>> 
>>>> This topic doesn't warrant further consideration.
>>> 
>>> 
>>> It's interesting to note that classes passed via 'in' parameters are still
>>> passed by VALUE.  Not reference.
>>> 
>>> Just some food for thought.
>>> 
>>> -S.
>> 
>> Ignore my dipshit comment.  I ran my test incorrectly.
>> 
>> -S.
>> 
> No, what you said the first time is correct. What may be incorrect is your notion of value/reference types and their argument passing.

The point is the class is not passed by value.  The pointer to the class is passed by value.  What good is that?

-S.

P.S.  I have enough humility to admit my error, and you come back with a snide remark like that?  I don't even know you.

On Sat, 18 Feb 2006 01:28:01 +1100, Bruno Medeiros <daiphoenixNO@SPAMlycos.com> wrote:

> Derek Parnell wrote:
>> On Fri, 17 Feb 2006 00:51:05 +1100, Bruno Medeiros <daiphoenixNO@SPAMlycos.com> wrote:
>>   [snip]
>>
>>>>> The 'in' modifier applies to the array reference, not the data.
>>>>  Yes I know that! But I didn't pass a reference, I passed an array. The
>>>> compiler passed the reference. But yeah, I know...this is the whole point
>>>> that people have been on about for ages. I just thought I'd highlight
>>>> another trap for coders. You may think your passing the array but you
>>>> aren't really. Nasty things could happen here.
>>>>
>>>
>>> How is that surprising, or another trap for coders ? It's the way it is done since old C to any modern day C-family language. Static arrays are (like) reference types.
>>  It is surprising if one does not have a C background and one uses normal reasoning.
>>
> That I can agree with. Although most programmers should have a C-family languages background, we could clarify (by "we" I mean foremost the docs) this issue by clearly stating that static arrays are reference types, just like it's kin dynamic arrays.
>
>> My code said "pass this array to the function". The compiler didn't do that. We are told that fixed length arrays and structs are created on the stack not the heap but that classes and variable length arrays are heap things. We are told that heap entities are passed by reference. We are told that structs are passed by value, so one could innocently assume that fixed length arrays, being stack entities like structs, are also passed by value.
>>
> Thus, we shouldn't think of the way how data in a var is allocated as a means to discern parameter behavior. What we should think of, is if the data type is a value type, or a reference type.
> And also: *all* variables in D are by default passed by value, including classes and arrays. What happens is that they are reference values. This   conceptualization may look similar, but it's not, and it's a very important notion to have.

That is very wrong.

When passing a class instance, the data which is owned by that object is not passed (its value) but as you say, an address of a RAM structure that represents the object is passed (its reference). The 'reference' is not the 'value'.

When passing an array, the bits that go in into making the value of the data that is owned by the array is not passed (its value) but an address of an 8-byte structure (in the case of variable length arrays) or the address of the data (in the case of fixed length arrays) is passed (its reference). The 'reference' is not the 'value'.

So, some things are passed by reference (which is not its value) and some things are passed by value (which is not its reference).

>> This topic doesn't warrant further consideration.
>>
> Huh, why? I barely said anything, and I find the above mentioned comment relevant.

Because we, and others, have been saying the same things over and over again without resolution or advancement. None of these discussions is going to change D.

The 'in' qualifier ensures that whatever changes are made to whatever that is literally passed as a function parameter will not be returned to the caller in that same parameter.

Both the 'out' and 'inout' qualifier ensures that whatever changes are made to whatever that is literally passed as a function parameter will be returned to the caller in that same parameter.

Thus, in the case of 'in' and an array, what is literally passed is the reference and that reference is what is protected.

The original poster, I think, was just saying it would be useful to have another option available for those things that are currently passed by value, and that option being that we can specify that instead of being passed by value that we want it to be passed by reference *and* that we don't want to use pointer notation to do that.

-- 
Derek Parnell
Melbourne, Australia

In article <op.s44i7ehj6b8z09@ginger.vic.bigpond.net.au>, Derek Parnell says...
>
>The original poster, I think, was just saying it would be useful to have another option available for those things that are currently passed by value, and that option being that we can specify that instead of being passed by value that we want it to be passed by reference *and* that we don't want to use pointer notation to do that.

Being the original poster, I can say this is almost exactly what I meant! At least someone understands what I was talking about!

Also, I was stating not only that we don't want to use pointers, but we also don't want to use inout, because inout means we're going to change the value.

-S.