In article <1pbs7p4w3px1t$.18g0zn4yzirgl.dlg@40tude.net>, Derek Parnell says...
>
>On Wed, 15 Feb 2006 03:38:21 +0000 (UTC), Tom wrote:
>
>> In article <1d166miote41e$.1qa28uiydunuu$.dlg@40tude.net>, Derek Parnell says...
>>>> If this was the case, the compiler wouldn't allow modification of any member of the struct, so no copy would be necessary. If i'm wrong (or totally confused) please correct me, it's late and it has been a long day.
>>>
>>>No, I wasn't implying C++'s const functionality. I was implying that the compiler would *not* complain if the function had code to modified the passed array, instead it would silently take a copy of it and modify the copy. But this is probably too much against Walter's philosophy so I'm just wasting bandwidth again ;-)
>> 
>> I'm the king of wasted bandwidth so don't feel bad about it ;-)
>> 
>> So, if you didn't imply const functionality what is wrong about inref beeing that (const Type &var === inref Type var)? I really don't understand what´s the benefit of making a copy silently instead of complaining about the function trying to modify the INREF parameter. Please if you don't mind to explain me further, or I'm _really_ confused here and should shut my mouth (or my hands) :-)
>
>Ok, you asked for it ;-)
>
>Its pure laziness, that's all. It's just a way of automating CoW semantics. If all the compiler did was complain then I'd have to modify my code to do something different. This is a RARE circumstance I'm addressing here and one that also smacks of lazy coding.
>
>  void func( inref char[] a)
>  {
>      . . .
>      a[0] = 'C'; // compiler complains!
>      . . .
>  }
>
>so I change it to
>
>
>  void func( inref char[] a)
>  {
>      . . .
>      char[] b = a.dup;
>      b[0] = 'C'; // compiler is now happy
>      . . .
>  }
>
>but if the compiler was happy for me to be lazy it might help me out by silent doing ...
>
>  void func( inref char[] a)
>  {
>      a = a.dup; // take a copy and replace the pointer.
>      . . .
>      a[0] = 'C'; // compiler is now happy
>      . . .
>  }
>
>So, there is not really a good argument for supporting the silent CoW idea because I may as well be explicit about it anyway, thus using current D syntax ...
>
>  void func(char[] a)
>  {
>      a = a.dup; // take a copy and replace the pointer.
>      . . .
>      a[0] = 'C';
>      . . .
>  }

Thanks for the detailed thing! :-D but it made me realize that I understood it from the beginning. I think this kind of laziness isn't a good tradeoff with efficiency. I mean, I personally prefer the compiler to complain than compiler making silent copies of potentially big structures. I think compiler SHOULD complain if there was an INREF functionality.

C++'s "const Type &var" is an priceless thing and D should implement it someway
(IMHO).

Regards,

Tom;

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:

inout is a C++ reference.
out ensures the value will be initialized if it is untouched, it would also probably allow some compiler optimizations in certain cases.

> 
> 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.
>
Its not a lie, its an ability which you simply did not use.

This type of ability might be somewhat useful for library authors, but outside that it sounds as if you wish to handle a specific class of errors by changing the whole language.

If you are simply writing programs and not a library, asking the compiler to guess your intent is not really feasible.  The in/out/inout bestows *capabilities* not *constraints*.

Even so, why not just use a class and perhaps an Immutable wrapper?
Structs are useful for specific things, but shared data is not one of them, thats what classes are for.

class CFoo
{
   Foo foo;
   int opApply( int delegate( inout char c ) dg ) {
	<process foo.bigArray>
   }	
}

-DavidM

On Tue, 14 Feb 2006 05:11:42 -0800, 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

I've just noticed this in the D documentation, in the ABI reference...

---------------
Reference Types
When passing a static array to a function, the result, although declared as
a static array, will actually be a reference to a static array. For
example:

int abc[3];
Passing abc to functions results in these implicit conversions:

void func(int array[3]); // actually <reference to><array[3] of><int>
void func(int *p);       // abc[3] is converted to a pointer
 // to the first element
void func(int array[]); // abc[3] is converted to a dynamic array
----------------


-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocracy!"
16/02/2006 10:54:01 AM

In article <dsva39$139m$1@digitaldaemon.com>, David Medlock says...
>
>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:
>
>inout is a C++ reference.
>out ensures the value will be initialized if it is untouched, it would
>also probably allow some compiler optimizations in certain cases.
>
>> 
>> 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.
>>
>Its not a lie, its an ability which you simply did not use.
>
>This type of ability might be somewhat useful for library authors, but outside that it sounds as if you wish to handle a specific class of errors by changing the whole language.

Who said ANYTHING changing the entire language?  The functionality I require is already IN the language as pointers or as inout.  The point is that there is inconsitency in this case.

>If you are simply writing programs and not a library, asking the compiler to guess your intent is not really feasible.  The in/out/inout bestows *capabilities* not *constraints*.

The point of the in/inout/out keywords has NOTHING to do with anything other than information.  You are incorrect that they bestow features OR constraints. They are neither! They are a means for function writers to give INFORMATION about what their function does to the compiler, and to consumers of their function.  It just so happens that OUT by value or INOUT by value make NO SENSE, so those keywords bestow reference passing on the parameter!  Currently there is no way to get reference passing parameters aside from pointers, or one of those informational keywords.  Having to use pointers, or incorrently stating what your function does with the parameter, are unacceptable ways to obtain a reference.

>Even so, why not just use a class and perhaps an Immutable wrapper?
>Structs are useful for specific things, but shared data is not one of
>them, thats what classes are for.
>class CFoo
>{
>    Foo foo;
>    int opApply( int delegate( inout char c ) dg ) {
>	<process foo.bigArray>
>    }
>}

Structs (AKA structures) and Classes are two fundementally different things which are supposed to be for completely different purposes.  That is storing structured data vs grouping functions, which work on the same data, together. You seem to be saying that the only difference between structures is solely the fact that one has reference semantics while the other does not.  I would fully disagree with that assertion.

-S.

Derek Parnell wrote:
> On Tue, 14 Feb 2006 05:11:42 -0800, 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
> 
> I've just noticed this in the D documentation, in the ABI reference...
> 
> ---------------
> Reference Types
> When passing a static array to a function, the result, although declared as
> a static array, will actually be a reference to a static array.

This seems identical to array passing in C, where the same thing occurs.


Sean

On Wed, 15 Feb 2006 16:12:22 -0800, Sean Kelly wrote:

> Derek Parnell wrote:
>> On Tue, 14 Feb 2006 05:11:42 -0800, 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
>> 
>> I've just noticed this in the D documentation, in the ABI reference...
>> 
>> ---------------
>> Reference Types
>> When passing a static array to a function, the result, although declared as
>> a static array, will actually be a reference to a static array.
> 
> This seems identical to array passing in C, where the same thing occurs.
> 

Okay. It's just that it seems to me then that S.'s concerns about passing a huge array using the 'in' format are not warranted. However, this doesn't help out with passing huge structures

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocracy!"
16/02/2006 11:25:06 AM

Derek Parnell wrote:
> On Wed, 15 Feb 2006 16:12:22 -0800, Sean Kelly wrote:
> 
>> Derek Parnell wrote:
>>> On Tue, 14 Feb 2006 05:11:42 -0800, 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
>>> I've just noticed this in the D documentation, in the ABI reference...
>>>
>>> ---------------
>>> Reference Types
>>> When passing a static array to a function, the result, although declared as
>>> a static array, will actually be a reference to a static array.
>> This seems identical to array passing in C, where the same thing occurs.
>>
> 
> Okay. It's just that it seems to me then that S.'s concerns about passing a
> huge array using the 'in' format are not warranted. However, this doesn't
> help out with passing huge structures

Agreed.  Though I agree that if something happens then it must be in the ABI.  The last thing I want in D is binary incompatibility between compilers.


Sean

On Thu, 16 Feb 2006 11:27:45 +1100, Derek Parnell wrote:

> On Wed, 15 Feb 2006 16:12:22 -0800, Sean Kelly wrote:
> 
>> Derek Parnell wrote:
>>> On Tue, 14 Feb 2006 05:11:42 -0800, 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
>>> 
>>> I've just noticed this in the D documentation, in the ABI reference...
>>> 
>>> ---------------
>>> Reference Types
>>> When passing a static array to a function, the result, although declared as
>>> a static array, will actually be a reference to a static array.
>> 
>> This seems identical to array passing in C, where the same thing occurs.
>> 
> 
> Okay. It's just that it seems to me then that S.'s concerns about passing a huge array using the 'in' format are not warranted. However, this doesn't help out with passing huge structures

Oops, spoke too soon. I just tried this little test ...

-----------------
import std.stdio;
char[100000] a = void;

void func(in char[100000] x)
{
    x[0] = 'x';
}

void main()
{
    a[0] = 'a';
    func(a);
    writefln("%s", a[0]);
}
-----------------

So although the huge array might actually be passed via a reference, it seems that the 'in' modifier is not respected. The output was 'x'.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocracy!"
16/02/2006 11:32:51 AM

On Thu, 16 Feb 2006 11:34:39 +1100, Derek Parnell <derek@psych.ward> wrote:
> On Thu, 16 Feb 2006 11:27:45 +1100, Derek Parnell wrote:
>
>> On Wed, 15 Feb 2006 16:12:22 -0800, Sean Kelly wrote:
>>
>>> Derek Parnell wrote:
>>>> On Tue, 14 Feb 2006 05:11:42 -0800, 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
>>>>
>>>> I've just noticed this in the D documentation, in the ABI reference...
>>>>
>>>> ---------------
>>>> Reference Types
>>>> When passing a static array to a function, the result, although declared as
>>>> a static array, will actually be a reference to a static array.
>>>
>>> This seems identical to array passing in C, where the same thing occurs.
>>>
>>
>> Okay. It's just that it seems to me then that S.'s concerns about passing a
>> huge array using the 'in' format are not warranted. However, this doesn't
>> help out with passing huge structures
>
> Oops, spoke too soon. I just tried this little test ...
>
> -----------------
> import std.stdio;
> char[100000] a = void;
>
> void func(in char[100000] x)
> {
>     x[0] = 'x';
> }
>
> void main()
> {
>     a[0] = 'a';
>     func(a);
>     writefln("%s", a[0]);
> }
> -----------------
>
> So although the huge array might actually be passed via a reference, it
> seems that the 'in' modifier is not respected. The output was 'x'.

The 'in' modifier applies to the array reference, not the data.

Regan

On Thu, 16 Feb 2006 13:39:56 +1300, Regan Heath wrote:

> On Thu, 16 Feb 2006 11:34:39 +1100, Derek Parnell <derek@psych.ward> wrote:
>> On Thu, 16 Feb 2006 11:27:45 +1100, Derek Parnell wrote:
>>
>>> On Wed, 15 Feb 2006 16:12:22 -0800, Sean Kelly wrote:
>>>
>>>> Derek Parnell wrote:
>>>>> On Tue, 14 Feb 2006 05:11:42 -0800, 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
>>>>>
>>>>> I've just noticed this in the D documentation, in the ABI reference...
>>>>>
>>>>> ---------------
>>>>> Reference Types
>>>>> When passing a static array to a function, the result, although
>>>>> declared as
>>>>> a static array, will actually be a reference to a static array.
>>>>
>>>> This seems identical to array passing in C, where the same thing occurs.
>>>>
>>>
>>> Okay. It's just that it seems to me then that S.'s concerns about
>>> passing a
>>> huge array using the 'in' format are not warranted. However, this
>>> doesn't
>>> help out with passing huge structures
>>
>> Oops, spoke too soon. I just tried this little test ...
>>
>> -----------------
>> import std.stdio;
>> char[100000] a = void;
>>
>> void func(in char[100000] x)
>> {
>>     x[0] = 'x';
>> }
>>
>> void main()
>> {
>>     a[0] = 'a';
>>     func(a);
>>     writefln("%s", a[0]);
>> }
>> -----------------
>>
>> So although the huge array might actually be passed via a reference, it seems that the 'in' modifier is not respected. The output was 'x'.
> 
> 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.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocracy!"
16/02/2006 12:04:28 PM