This recent thread about unsafe, and some of my own coding has recently pointed out a feature D lacks:

In by reference

Let me start by first posing a question:

What is the implementation difference between inout and out?  Both are by reference, and it is true that the out keyword on in the parameter does not preclude you from accessing the variables contents.   So what does it mean?  It tells the person calling your function that you have no plans to use the value given in an "out" parameter.  So what?  Well what about the 'in' keyword?  It is implemented differently from out or inout, that is, it is passed by value.  So where is the option to specify that I want an "in" parameter by reference without using pointers?   It would be nice to not have to lie:

struct Foo {
	char[100000] bigArray;
}

int ProcessFoos( inout Foo bar )
{
	int hash = hash.max;
	foreach( char c; bar.bigArray ) {
		hash =  (hash << 1) ^ c;
	}
	return hash;
}

Cleary, inout is a lie here as I do not modify Foo at all.  It would be nice to be able to say "I want a reference, but i'm not going to modify the value it points to!"  The alternative right now is to just say "in" and copy 100000 bytes of memory for no good reason.

-S.

On Tue, 14 Feb 2006 08:11:42 -0500, S. Chancellor <dnewsgr@mephit.kicks-ass.org> wrote:

> This recent thread about unsafe, and some of my own coding has recently pointed out a feature D lacks:
>
> In by reference
>
> Let me start by first posing a question:
>
> What is the implementation difference between inout and out?  Both are by reference, and it is true that the out keyword on in the parameter does not preclude you from accessing the variables contents.   So what does it mean?  It tells the person calling your function that you have no plans to use the value given in an "out" parameter.  So what?  Well what about the 'in' keyword?  It is implemented differently from out or inout, that is, it is passed by value.  So where is the option to specify that I want an "in" parameter by reference without using pointers?   It would be nice to not have to lie:
>
> struct Foo {
> 	char[100000] bigArray;
> }
>
> int ProcessFoos( inout Foo bar )
> {
> 	int hash = hash.max;
> 	foreach( char c; bar.bigArray ) {
> 		hash =  (hash << 1) ^ c;
> 	}
> 	return hash;
> }
>
> Cleary, inout is a lie here as I do not modify Foo at all.  It would be nice to be able to say "I want a reference, but i'm not going to modify the value it points to!"  The alternative right now is to just say "in" and copy 100000 bytes of memory for no good reason.
>
> -S.
>

Agreed; I've had to do this on several occasions.

S. Chancellor wrote:
> This recent thread about unsafe, and some of my own coding has recently pointed out a feature D lacks:
> 
> In by reference
> 
> Let me start by first posing a question:
> 
> What is the implementation difference between inout and out?  Both are by reference, and it is true that the out keyword on in the parameter does not preclude you from accessing the variables contents.   So what does it mean?  It tells the person calling your function that you have no plans to use the value given in an "out" parameter.  So what?  Well what about the 'in' keyword?  It is implemented differently from out or inout, that is, it is passed by value.  So where is the option to specify that I want an "in" parameter by reference without using pointers?   It would be nice to not have to lie:
> 
> struct Foo {
>     char[100000] bigArray;
> }
> 
> int ProcessFoos( inout Foo bar )
> {
>     int hash = hash.max;
>     foreach( char c; bar.bigArray ) {
>         hash =  (hash << 1) ^ c;
>     }
>     return hash;
> }
> 
> Cleary, inout is a lie here as I do not modify Foo at all.  It would be nice to be able to say "I want a reference, but i'm not going to modify the value it points to!"  The alternative right now is to just say "in" and copy 100000 bytes of memory for no good reason.
> 
> -S.
> 

Support. This is very annoying.

S. Chancellor wrote:
> This recent thread about unsafe, and some of my own coding has recently pointed out a feature D lacks:
> 
> In by reference

Agree completely, but i would also like to add return by reference.

> 
> Cleary, inout is a lie here as I do not modify Foo at all.  It would be nice to be able to say "I want a reference, but i'm not going to modify the value it points to!"  The alternative right now is to just say "in" and copy 100000 bytes of memory for no good reason.

But I am afraid that I remember that Walters answer to this was something like: "a good optimizer will optimize this code so the struct wouln't actually be copyied". I have a feeling i read on this NG that DMD allready does this decision based on struct size but I might be wrong?

On 2006-02-14 11:11:53 -0800, Ivan Senji <ivan.senji_REMOVE_@_THIS__gmail.com> said:

> S. Chancellor wrote:
>> This recent thread about unsafe, and some of my own coding has recently pointed out a feature D lacks:
>> 
>> In by reference
> 
> Agree completely, but i would also like to add return by reference.
> 
>> 
>> Cleary, inout is a lie here as I do not modify Foo at all.  It would be nice to be able to say "I want a reference, but i'm not going to modify the value it points to!"  The alternative right now is to just say "in" and copy 100000 bytes of memory for no good reason.
> 
> But I am afraid that I remember that Walters answer to this was something like: "a good optimizer will optimize this code so the struct wouln't actually be copyied". I have a feeling i read on this NG that DMD allready does this decision based on struct size but I might be wrong?

Since this is undefined behavior, it could cause binary compatibility problems between compilers.  I think this needs more discussion to prevent binary compatibility problems.  Or have we given up on that?

-S.

S. Chancellor wrote:
> On 2006-02-14 11:11:53 -0800, Ivan Senji <ivan.senji_REMOVE_@_THIS__gmail.com> said:
> 
>> S. Chancellor wrote:
>>> This recent thread about unsafe, and some of my own coding has recently pointed out a feature D lacks:
>>>
>>> In by reference
>>
>> Agree completely, but i would also like to add return by reference.
>>
>>>
>>> Cleary, inout is a lie here as I do not modify Foo at all.  It would be nice to be able to say "I want a reference, but i'm not going to modify the value it points to!"  The alternative right now is to just say "in" and copy 100000 bytes of memory for no good reason.
>>
>> But I am afraid that I remember that Walters answer to this was something like: "a good optimizer will optimize this code so the struct wouln't actually be copyied". I have a feeling i read on this NG that DMD allready does this decision based on struct size but I might be wrong?
> 
> Since this is undefined behavior, it could cause binary compatibility problems between compilers.  I think this needs more discussion to prevent binary compatibility problems.  Or have we given up on that?

Since this is done during an optimization pass, I assume it only applies to code that can be inlined.


Sean

On 2006-02-14 13:05:31 -0800, Sean Kelly <sean@f4.ca> said:

> Since this is done during an optimization pass, I assume it only applies to code that can be inlined.
> 
> 
> Sean

Wouldn't that make it almost useless?

On Tue, 14 Feb 2006 12:52:47 -0800, S. Chancellor wrote:

> On 2006-02-14 11:11:53 -0800, Ivan Senji <ivan.senji_REMOVE_@_THIS__gmail.com> said:
> 
>> S. Chancellor wrote:
>>> This recent thread about unsafe, and some of my own coding has recently pointed out a feature D lacks:
>>> 
>>> In by reference
>> 
>> Agree completely, but i would also like to add return by reference.
>> 
>>> 
>>> Cleary, inout is a lie here as I do not modify Foo at all.  It would be nice to be able to say "I want a reference, but i'm not going to modify the value it points to!"  The alternative right now is to just say "in" and copy 100000 bytes of memory for no good reason.
>> 
>> But I am afraid that I remember that Walters answer to this was something like: "a good optimizer will optimize this code so the struct wouln't actually be copyied". I have a feeling i read on this NG that DMD allready does this decision based on struct size but I might be wrong?
> 
> Since this is undefined behavior, it could cause binary compatibility problems between compilers.  I think this needs more discussion to prevent binary compatibility problems.  Or have we given up on that?
> 
> -S.

I agree with your concerns S., both the need for this functionality and the 'optimisation' problem.

If I distribute a compiled library that does not optimise the passing large structures, and somebody tries to use that library with a compiler that does optimise this then we are going to have problems.

To be able to explicitly tell the compiler to do this would seem to be a very useful idea. Of course, the current alternative is to use pointers and hope the called function behaves itself, but hopefully we are trying to move away from explicit pointers nowadays.

I suppose another work around is to enclose the structure in a class, but that's starting to sound like a hack and overkill.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocracy!"
15/02/2006 12:22:39 PM

On Tue, 14 Feb 2006 05:11:42 -0800, S. Chancellor <dnewsgr@mephit.kicks-ass.org> wrote:
> This recent thread about unsafe, and some of my own coding has recently pointed out a feature D lacks:
>
> In by reference
>
> Let me start by first posing a question:
>
> What is the implementation difference between inout and out?  Both are by reference, and it is true that the out keyword on in the parameter does not preclude you from accessing the variables contents.   So what does it mean?  It tells the person calling your function that you have no plans to use the value given in an "out" parameter.  So what?  Well what about the 'in' keyword?  It is implemented differently from out or inout, that is, it is passed by value.  So where is the option to specify that I want an "in" parameter by reference without using pointers?   It would be nice to not have to lie:
>
> struct Foo {
> 	char[100000] bigArray;
> }
>
> int ProcessFoos( inout Foo bar )
> {
> 	int hash = hash.max;
> 	foreach( char c; bar.bigArray ) {
> 		hash =  (hash << 1) ^ c;
> 	}
> 	return hash;
> }
>
> Cleary, inout is a lie here as I do not modify Foo at all.  It would be nice to be able to say "I want a reference, but i'm not going to modify the value it points to!"  The alternative right now is to just say "in" and copy 100000 bytes of memory for no good reason.

So, what is wrong with using a pointer in this case? i.e.
  int ProcessFoos( Foo* bar )

?

Regan

On Wed, 15 Feb 2006 15:33:45 +1300, Regan Heath <regan@netwin.co.nz> wrote:
> On Tue, 14 Feb 2006 05:11:42 -0800, S. Chancellor <dnewsgr@mephit.kicks-ass.org> wrote:
>> This recent thread about unsafe, and some of my own coding has recently pointed out a feature D lacks:
>>
>> In by reference
>>
>> Let me start by first posing a question:
>>
>> What is the implementation difference between inout and out?  Both are by reference, and it is true that the out keyword on in the parameter does not preclude you from accessing the variables contents.   So what does it mean?  It tells the person calling your function that you have no plans to use the value given in an "out" parameter.  So what?  Well what about the 'in' keyword?  It is implemented differently from out or inout, that is, it is passed by value.  So where is the option to specify that I want an "in" parameter by reference without using pointers?   It would be nice to not have to lie:
>>
>> struct Foo {
>> 	char[100000] bigArray;
>> }
>>
>> int ProcessFoos( inout Foo bar )
>> {
>> 	int hash = hash.max;
>> 	foreach( char c; bar.bigArray ) {
>> 		hash =  (hash << 1) ^ c;
>> 	}
>> 	return hash;
>> }
>>
>> Cleary, inout is a lie here as I do not modify Foo at all.  It would be nice to be able to say "I want a reference, but i'm not going to modify the value it points to!"  The alternative right now is to just say "in" and copy 100000 bytes of memory for no good reason.
>
> So, what is wrong with using a pointer in this case? i.e.
>    int ProcessFoos( Foo* bar )

To be clear, I realise you said "without pointers" above, I want to know why you do not want to use a pointer.

Regan