"Andrew Fedoniouk" <news@terrainformatica.com> wrote in message news:dauu7h$2a8i$1@digitaldaemon.com...
>
> "Ben Hinkle" <bhinkle@mathworks.com> wrote in message news:daul84$229o$1@digitaldaemon.com...
>>
>> "Andrew Fedoniouk" <news@terrainformatica.com> wrote in message news:daui3u$1vos$1@digitaldaemon.com...
>>>
>>> "Ben Hinkle" <bhinkle@mathworks.com> wrote in message news:daubr5$1phd$1@digitaldaemon.com...
>>>>> Hmm, it seems that we are speaking about the same entity but using different terms.
>>>>>
>>>>> See, in C++ declaration of const variable like
>>>>>
>>>>> const typename v;
>>>>>
>>>>> means declaration of variable of "const typename" - implicitly
>>>>> generated type - const version
>>>>> of typename with all non const members disabled ( non availble ) for
>>>>> use through 'v' alias.
>>>>>
>>>>> Therefore, if I understand you and Walter correctly
>>>>>
>>>>> C++:
>>>>>      void foo(const char[] str)
>>>>>
>>>>> is exactly yours:
>>>>>      void foo(final char[] str)
>>>>>
>>>>> and Walter's:
>>>>>      void foo(in char[] str)
>>>>>
>>>>> Is this correct?
>>>>
>>>> Not as I read Walter's posts like http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/26096. In particular C++ const says nothing about changing the values through other references while this final/in proposal would assert that the value remains constant through all references. That's been the drum-beat of all these posts saying why D doesn't have const already. I don't understand the confusion here.
>>>
>>> Practical "ultimate resource immutability" ( a.k.a.
>>> "Andrei's deep immutability" ) implementation is not feasible on
>>> compiler level for
>>> langages of D class (e.g. having pointers).
>>> Only on VM level it is possible to do it and at some extent only. As
>>> "D virtual machine" is a processor itself then it means that without
>>> os/hardware support implementation of this dream is not possible.
>>> I though that it was clear from the very beginning....
>>>
>>> BTW: Do you know any solution for read-only protection
>>> of any arbitrary memory location?
>>> Highly probable that I missed something in this area recently.
>>
>> As Walter's original post said deep immutability is a contract made by the programmer to the compiler (and other programmers) which the compiler can verify in simple cases similar to the cases C++ const would catch. It is independent of any VM or the existence of pointers. Are you trying to say the contract must be verfied in *all* cases? I agree it is impractical to validate all cases. I suspect that's why Walter said the compiler would only catch simple cases like assigning through an immutable pointer and such.
>
> I suspect quite opposite:
>
> Walter:
> "On the other hand, look at C++ "const". Nothing about "const" says that
> some
> other thread or reference cannot change the value out from under you at
> any
> moment. Furthermore, it can be cast away and modified anyway. The semantic
> value of C++ "const" is essentially zip. This is why I am often flummoxed
> why it is given such weight in C++."
>
> Ben: "Are you trying to say the contract must be verfied in *all* cases?"
> Of course no. This is Walter who is trying to say this as far as I
> understand his concerns
> about 'const' in C++.

I can only assume you haven't read all of Walter's post or that there is some language barrier going on here. Let me try to expand on what Walter said. The use of 'in' or 'final' is a promise made by the *programmer* to the compiler to obey the contract. The compiler can validate the contract in a subset of circumstances. The compiler will not and most likely cannot validate the contract in all cases. The whole point is that in/final is a promise by the programmer that nothing will change the value and is independent of what the compiler will or will not be able to validate.

>>>> In addition the final/in proposal is different than C++ const for the
>>>> following example:
>>>>  struct A {
>>>>    A* ptr;
>>>>  }
>>>>  void foo(final A* ptr2) {
>>>>    ptr2.ptr.ptr = null; // illegal
>>>>  }
>>>>  void main() {
>>>>    A a;
>>>>    a.ptr = &a;
>>>>    foo(&a);
>>>>  }
>>>
>>>> vs in C++
>>>>  struct A {
>>>>    A* ptr;
>>>>  }
>>>>  void foo(const A* ptr2) {
>>>>    ptr2->ptr->ptr = 0; // legal
>>>>  }
>>>
>>> True. I think that C++ behavior in this case can be better as if you would change this to:
>>>
>>> struct A {
>>>  A *_ptr;
>>>  A* ptr() { return _ptr; }
>>> };
>>>
>>> void foo(const A* ptr2) {
>>>   ptr2->ptr()->ptr(); // error here
>>> }
>>>
>>> you will get an error:
>>> 'ptr' : cannot convert 'this' pointer from 'const struct A' to 'struct A
>>> &' or so.
>>>
>>>>  void main() {
>>>>    A a;
>>>>    a.ptr = &a;
>>>>    foo(&a);
>>>>  }
>>>> The example is simplistic but it illustrates the meaning of
>>>> recursive/deep immutability.
>>>
>>> Yes it is. As I have shown in example above C++ does
>>> such deep immutability.
>>
>> Sure - if you change the C++ example to not allow any writing then it becomes immutable. But that is different than what I originally posted and what Walter meant by deep immutable parameter.
>>
>>> I am using "deep immutability" term as it is described here: http://www-sop.inria.fr/everest/events/cassis05/Transp/poll.pdf page #18
>>
>> I understand. Do you understand Walter's description of deep immutability from his post? The key phrase in Walter's post is "every sub-object reachable from that parameter". Perhaps we should start using the phrases "deep immutable type" and "deep immutable variable" to distinguish between the notions.
>>
>
> Yes, I think I understand "every sub-object reachable from that
> parameter".
> This is exactly referentional deep immutability -
> "using this particular reference to the object it is impossible to change
> state of the object and every sub-object reachable from that object"

The key difference is that const and Javari encode the "immutability" in the type and the in/final semantics are not encoded in the type (hence my original statement that final/in aren't type modifiers). Please consider again the examples I posted comparing final and const "deep immutability".

> This is what C++ and Javari are doing:
>
> "The specific constraint expressed is that the abstract state of the
> object to which an immutable reference refers cannot be modified using
> that reference. The abstract state is (part of) the transitively reachable
> state: that is, the state of the object and all state reachable from it by
> following references. The type system permits explicitly excluding fields
> or objects from the abstract state of an object. For a statically
> type-safe language, the type system guarantees reference immutability."
> Javari also allows to:
> "If the language is extended with immutability downcasts, then run-time
> checks enforce the reference immutability constraints."
> by making specific changes in VM.
>
> C++ is using 'const' and Javari uses 'readonly' for marking parameters, fields and methods. http://pag.csail.mit.edu/~mernst/pubs/ref-immutability-oopsla2004-slides.pdf http://pag.csail.mit.edu/~mernst/pubs/ref-immutability-oopsla2004.pdf

Walter's post as I understand it avoids using the type system or run-time checks to attempt to enforce immutability. Note the key phrase in the first sentance you quote: "cannot be modified using that reference". Walter is trying to find a solution where that would be replaced with "cannot be modified".

> This is what C++ and Javari are doing:
>
> "The specific constraint expressed is that the abstract state of the object to which an immutable reference refers cannot be modified using that reference. The abstract state is (part of) the transitively reachable state: that is, the state of the object and all state reachable from it by following references. The type system permits explicitly excluding fields or objects from the abstract state of an object. For a statically type-safe language, the type system guarantees reference immutability."

sorry for the double post but I should add that C++'s const is not transitive, as illustrated by the code example I posted before.

"Ben Hinkle" <ben.hinkle@gmail.com> wrote in message news:dav7rm$2hp9$1@digitaldaemon.com...
>
> "Andrew Fedoniouk" <news@terrainformatica.com> wrote in message news:dauu7h$2a8i$1@digitaldaemon.com...
>>
>> "Ben Hinkle" <bhinkle@mathworks.com> wrote in message news:daul84$229o$1@digitaldaemon.com...
>>>
>>> "Andrew Fedoniouk" <news@terrainformatica.com> wrote in message news:daui3u$1vos$1@digitaldaemon.com...
>>>>
>>>> "Ben Hinkle" <bhinkle@mathworks.com> wrote in message news:daubr5$1phd$1@digitaldaemon.com...
>>>>>> Hmm, it seems that we are speaking about the same entity but using different terms.
>>>>>>
>>>>>> See, in C++ declaration of const variable like
>>>>>>
>>>>>> const typename v;
>>>>>>
>>>>>> means declaration of variable of "const typename" - implicitly
>>>>>> generated type - const version
>>>>>> of typename with all non const members disabled ( non availble ) for
>>>>>> use through 'v' alias.
>>>>>>
>>>>>> Therefore, if I understand you and Walter correctly
>>>>>>
>>>>>> C++:
>>>>>>      void foo(const char[] str)
>>>>>>
>>>>>> is exactly yours:
>>>>>>      void foo(final char[] str)
>>>>>>
>>>>>> and Walter's:
>>>>>>      void foo(in char[] str)
>>>>>>
>>>>>> Is this correct?
>>>>>
>>>>> Not as I read Walter's posts like http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/26096. In particular C++ const says nothing about changing the values through other references while this final/in proposal would assert that the value remains constant through all references. That's been the drum-beat of all these posts saying why D doesn't have const already. I don't understand the confusion here.
>>>>
>>>> Practical "ultimate resource immutability" ( a.k.a.
>>>> "Andrei's deep immutability" ) implementation is not feasible on
>>>> compiler level for
>>>> langages of D class (e.g. having pointers).
>>>> Only on VM level it is possible to do it and at some extent only. As
>>>> "D virtual machine" is a processor itself then it means that without
>>>> os/hardware support implementation of this dream is not possible.
>>>> I though that it was clear from the very beginning....
>>>>
>>>> BTW: Do you know any solution for read-only protection
>>>> of any arbitrary memory location?
>>>> Highly probable that I missed something in this area recently.
>>>
>>> As Walter's original post said deep immutability is a contract made by the programmer to the compiler (and other programmers) which the compiler can verify in simple cases similar to the cases C++ const would catch. It is independent of any VM or the existence of pointers. Are you trying to say the contract must be verfied in *all* cases? I agree it is impractical to validate all cases. I suspect that's why Walter said the compiler would only catch simple cases like assigning through an immutable pointer and such.
>>
>> I suspect quite opposite:
>>
>> Walter:
>> "On the other hand, look at C++ "const". Nothing about "const" says that
>> some
>> other thread or reference cannot change the value out from under you at
>> any
>> moment. Furthermore, it can be cast away and modified anyway. The
>> semantic
>> value of C++ "const" is essentially zip. This is why I am often flummoxed
>> why it is given such weight in C++."
>>
>> Ben: "Are you trying to say the contract must be verfied in *all* cases?"
>> Of course no. This is Walter who is trying to say this as far as I
>> understand his concerns
>> about 'const' in C++.
>
> I can only assume you haven't read all of Walter's post or that there is some language barrier going on here. Let me try to expand on what Walter said. The use of 'in' or 'final' is a promise made by the *programmer* to the compiler to obey the contract. The compiler can validate the contract in a subset of circumstances. The compiler will not and most likely cannot validate the contract in all cases. The whole point is that in/final is a promise by the programmer that nothing will change the value and is independent of what the compiler will or will not be able to validate.
>

Ben, honestly I don't think that any language barrier is involved here.
Probably
different thinking context or particular design environment or tasks. Anyway

Let me try to reproduce of what I understand so far, (I will cite this): http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/26096

"(#1) Deep immutable parameters would have unchanging values for the scope
of that
parameter, and also every sub-object reachable by that parameter would also
be unchangeable.
(#2)The values wouldn't change even by another reference or
another thread. (This is quite unlike C++ "const".)
(#3) "in" would be a promise by the programmer, and could not be guaranteed
by the compiler
(#4) - but - the optimizer can take advantage of this promise to generate
perhaps
significantly better code.
(#5) (With C++ "const", values can change at any moment by another reference
or another thread,
making optimizations based on "const" impossible.)

I understand it as:
Programmer will try to write code of function with 'in' parameters
without side effects - he is expressing following good wishes
(#1) "I am not going to change here anything",
(#2) "I swear you that I did my best to do not use other references
and threads to modify everything which is reachable from
this 'in' parameter".
(#3) Compiler in its turn will do its best to verify promises given
in #1 and #2 but without any warranties as it just impossible in CT.
(#4) Based on promises given above (mean that they can and
will be false as we are humans) optimizer will try to
"generate significantly better code".
And statement #5 is telling that this sequence of gentlemen
agreements is significantly better for optimization purposes
than 'const' agreements used in C++ (which are also gentlemen agreements).

Is this correct?

(Sorry, probably it sounds sarcastic, but this is how I am getting it, nothing really personal, I swear you :)

>> This is exactly referentional deep immutability -
>> "using this particular reference to the object it is impossible to change
>> state of the object and every sub-object reachable from that object"
>
> The key difference is that const and Javari encode the "immutability" in the type and the in/final semantics are not encoded in the type (hence my original statement that final/in aren't type modifiers). Please consider again the examples I posted comparing final and const "deep immutability".

Let's imagine that I have immutable collection of mutable objects e.g.
values of record in recordset - I can change values but not collection
itself.
Is it reasonable construction?

To use this system practically we need "mutable" keyword or such. In given record-buffer example I will need something like this:

void store( in mutable value[] recordValues)

>
>> This is what C++ and Javari are doing:
>>
>> "The specific constraint expressed is that the abstract state of the
>> object to which an immutable reference refers cannot be modified using
>> that reference. The abstract state is (part of) the transitively
>> reachable state: that is, the state of the object and all state reachable
>> from it by following references. The type system permits explicitly
>> excluding fields or objects from the abstract state of an object. For a
>> statically type-safe language, the type system guarantees reference
>> immutability."
>> Javari also allows to:
>> "If the language is extended with immutability downcasts, then run-time
>> checks enforce the reference immutability constraints."
>> by making specific changes in VM.
>>
>> C++ is using 'const' and Javari uses 'readonly' for marking parameters, fields and methods. http://pag.csail.mit.edu/~mernst/pubs/ref-immutability-oopsla2004-slides.pdf http://pag.csail.mit.edu/~mernst/pubs/ref-immutability-oopsla2004.pdf
>
> Walter's post as I understand it avoids using the type system or run-time checks to attempt to enforce immutability. Note the key phrase in the first sentance you quote: "cannot be modified using that reference". Walter is trying to find a solution where that would be replaced with "cannot be modified".

I understand it as: Walter is trying to find verification algorithm which
allows to prove
that any given object passed through 'in reference' will not be modified
by any other reference inside and outside of the function and in other
threads.
And intention is to do this without modification of type system and
without implementation of runtime checks and without any OS/hardware
support.
And all this above supposed to work reliable with slices and those "free
range chickens"
named pointers....

Did I get it right?

Sounds like "perpetuum mobile" project to be honest.

Moreover I believe this problem is close to the Halting Problem
of Turing Machine (which was proved to be unsolvable).
I think it is fundamentally impossible to prove real immutability of any
given memory location at compile time without type constraints.
If it would be possible then you will not need GC at all as
you will be able to delete exact set of unused resources at any
arbitrary source line of your program.

This is how I understand it.
I hope that I am wrong somewhere here.

Andrew Fedoniouk.
http://terrainformatica.com

> Let me try to reproduce of what I understand so far, (I will cite this): http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/26096
>
> "(#1) Deep immutable parameters would have unchanging values for the scope
> of that
> parameter, and also every sub-object reachable by that parameter would
> also
> be unchangeable.
> (#2)The values wouldn't change even by another reference or
> another thread. (This is quite unlike C++ "const".)
> (#3) "in" would be a promise by the programmer, and could not be
> guaranteed by the compiler
> (#4) - but - the optimizer can take advantage of this promise to generate
> perhaps
> significantly better code.
> (#5) (With C++ "const", values can change at any moment by another
> reference or another thread,
> making optimizations based on "const" impossible.)
>
> I understand it as:
> Programmer will try to write code of function with 'in' parameters
> without side effects - he is expressing following good wishes
> (#1) "I am not going to change here anything",
> (#2) "I swear you that I did my best to do not use other references
> and threads to modify everything which is reachable from
> this 'in' parameter".
> (#3) Compiler in its turn will do its best to verify promises given
> in #1 and #2 but without any warranties as it just impossible in CT.
> (#4) Based on promises given above (mean that they can and
> will be false as we are humans) optimizer will try to
> "generate significantly better code".
> And statement #5 is telling that this sequence of gentlemen
> agreements is significantly better for optimization purposes
> than 'const' agreements used in C++ (which are also gentlemen agreements).
>
> Is this correct?

yes - that's how I read it, too.

> (Sorry, probably it sounds sarcastic, but this is how I am getting it, nothing really personal, I swear you :)
>
>>> This is exactly referentional deep immutability -
>>> "using this particular reference to the object it is impossible to
>>> change
>>> state of the object and every sub-object reachable from that object"
>>
>> The key difference is that const and Javari encode the "immutability" in the type and the in/final semantics are not encoded in the type (hence my original statement that final/in aren't type modifiers). Please consider again the examples I posted comparing final and const "deep immutability".
>
> Let's imagine that I have immutable collection of mutable objects e.g.
> values of record in recordset - I can change values but not collection
> itself.
> Is it reasonable construction?
>
> To use this system practically we need "mutable" keyword or such. In given record-buffer example I will need something like this:
>
> void store( in mutable value[] recordValues)

The in/final proposal would not allow immutable collections of mutable objects - either everything is immutable or nothing is. If it is decided that is important then I agree either another keyword is needed or deep immutability needs to be dropped.

>>> This is what C++ and Javari are doing:
>>>
>>> "The specific constraint expressed is that the abstract state of the
>>> object to which an immutable reference refers cannot be modified using
>>> that reference. The abstract state is (part of) the transitively
>>> reachable state: that is, the state of the object and all state
>>> reachable from it by following references. The type system permits
>>> explicitly excluding fields or objects from the abstract state of an
>>> object. For a statically type-safe language, the type system guarantees
>>> reference immutability."
>>> Javari also allows to:
>>> "If the language is extended with immutability downcasts, then run-time
>>> checks enforce the reference immutability constraints."
>>> by making specific changes in VM.
>>>
>>> C++ is using 'const' and Javari uses 'readonly' for marking parameters, fields and methods. http://pag.csail.mit.edu/~mernst/pubs/ref-immutability-oopsla2004-slides.pdf http://pag.csail.mit.edu/~mernst/pubs/ref-immutability-oopsla2004.pdf
>>
>> Walter's post as I understand it avoids using the type system or run-time checks to attempt to enforce immutability. Note the key phrase in the first sentance you quote: "cannot be modified using that reference". Walter is trying to find a solution where that would be replaced with "cannot be modified".
>
> I understand it as: Walter is trying to find verification algorithm which
> allows to prove
> that any given object passed through 'in reference' will not be modified
> by any other reference inside and outside of the function and in other
> threads.
> And intention is to do this without modification of type system and
> without implementation of runtime checks and without any OS/hardware
> support.
> And all this above supposed to work reliable with slices and those "free
> range chickens"
> named pointers....
>
> Did I get it right?

I didn't get the impression that is holding him up. He explicitly says the verification algorithm can be as weak as the compiler author wants - in particular the verfication algorithm can be "always trust the programmer and check nothing". Maybe he is working on a fancy verification algorithm - who knows. I hope he isn't spending much time on it. I think he's mulling over designs to balance the trade-offs between C++ const use-cases, deep immutability and optimization opportunities. The general design is more important to get right than the verification algorithm.

>>
>> Let's imagine that I have immutable collection of mutable objects e.g.
>> values of record in recordset - I can change values but not collection
>> itself.
>> Is it reasonable construction?
>>
>> To use this system practically we need "mutable" keyword or such. In given record-buffer example I will need something like this:
>>
>> void store( in mutable value[] recordValues)
>
> The in/final proposal would not allow immutable collections of mutable objects - either everything is immutable or nothing is. If it is decided that is important then I agree either another keyword is needed or deep immutability needs to be dropped.
>

As more I am looking into the problem as more I like
simple solution of having read-only arrays and read-only
pointers.

It is a deterministic and natural solution - can be verified and enforced in 100% cases.

Combined with use of existing access specifiers
private/public/etc. will be more powerfull than 'const'
and yet simple.

> A variation on this is to just use the 'final' keyword and forget about
> marking output values. So an input parameter, local variable or field
> marked 'final' means "deep immutable" in Walter's sense for the lifetime
> of that variable. A final variable of array, pointer or reference type can
> be assigned new values but the contents of the array, pointer or reference
> (recursively) cannot change.
> void foo(final char[] str); // Walter's idea with 'final' instead of 'in'
> final char[] str = "blah"; // str contents are read-only
> struct Foo { final char[] str; }

It occured to me a benefit of using a keyword other than 'in' is that it
allows you to write
 void foo(final inout BigHonkinStruct x)
to get both pass-by-reference and immutability.

"Ben Hinkle" <ben.hinkle@gmail.com> wrote in message news:db3ejf$i7u$1@digitaldaemon.com...
>> A variation on this is to just use the 'final' keyword and forget about
>> marking output values. So an input parameter, local variable or field
>> marked 'final' means "deep immutable" in Walter's sense for the lifetime
>> of that variable. A final variable of array, pointer or reference type
>> can be assigned new values but the contents of the array, pointer or
>> reference (recursively) cannot change.
>> void foo(final char[] str); // Walter's idea with 'final' instead of 'in'
>> final char[] str = "blah"; // str contents are read-only
>> struct Foo { final char[] str; }
>
> It occured to me a benefit of using a keyword other than 'in' is that it
> allows you to write
> void foo(final inout BigHonkinStruct x)
> to get both pass-by-reference and immutability.
>

Yep, in/out is just byval/byref and has nothing common with constness.

BTW: You've provided example which has little sense :)

void foo(final inout BigHonkinStruct x)

As 'inout' tells us - information will flow in and out
but foo cannot modify x so it is only 'in' in fact.

But with immutable arrays and pointers in/out has perfect sense:

void foo(in BigHonkinStruct*# x) // passing x by reference
                          // struct pointed by x will not be modified inside
                          // foo

void foo(out BigHonkinStruct*# x) // returning reference to
                                                // const struct

void foo(inout BigHonkinStruct*# x)
      // reading some const struct and
      // returning reference to new const struct

Andrew.

> BTW: You've provided example which has little sense :)
>
> void foo(final inout BigHonkinStruct x)
>
> As 'inout' tells us - information will flow in and out
> but foo cannot modify x so it is only 'in' in fact.

inout is used often in D to get pass-by-reference semantics without intending to modify the contents.

"Ben Hinkle" <bhinkle@mathworks.com> wrote in message news:db3hbg$ke8$1@digitaldaemon.com...
>> BTW: You've provided example which has little sense :)
>>
>> void foo(final inout BigHonkinStruct x)
>>
>> As 'inout' tells us - information will flow in and out
>> but foo cannot modify x so it is only 'in' in fact.
>
> inout is used often in D to get pass-by-reference semantics without intending to modify the contents.

I know. And is it good? It is breaking basic DbC rules I guess.

In any case
      foo(in int* var)  / foo(in int*# var)
tells me more than:
      foo(inout int var)

In article <db3g4b$jdj$1@digitaldaemon.com>, Andrew Fedoniouk says...
>
>
>"Ben Hinkle" <ben.hinkle@gmail.com> wrote in message news:db3ejf$i7u$1@digitaldaemon.com...
>>> A variation on this is to just use the 'final' keyword and forget about
>>> marking output values. So an input parameter, local variable or field
>>> marked 'final' means "deep immutable" in Walter's sense for the lifetime
>>> of that variable. A final variable of array, pointer or reference type
>>> can be assigned new values but the contents of the array, pointer or
>>> reference (recursively) cannot change.
>>> void foo(final char[] str); // Walter's idea with 'final' instead of 'in'
>>> final char[] str = "blah"; // str contents are read-only
>>> struct Foo { final char[] str; }
>>
>> It occured to me a benefit of using a keyword other than 'in' is that it
>> allows you to write
>> void foo(final inout BigHonkinStruct x)
>> to get both pass-by-reference and immutability.
>>
>
>Yep, in/out is just byval/byref and has nothing common with constness.
>
>BTW: You've provided example which has little sense :)
>
>void foo(final inout BigHonkinStruct x)
>
>As 'inout' tells us - information will flow in and out
>but foo cannot modify x so it is only 'in' in fact.

With Walter's 'explicit in' idea, then having 'inout' "double" as a way to pass a byval variable (greater in size than a machine word more efficiently) wouldn't be needed - the compiler could easily decide that and just do the optimization. This can be more efficient with something even as small as a long or a double prec. fp var. on 32 bit machines.

so instead of

'void foo(final inout BigHonkinStruct x)'

or

'void foo(in BigHonkinStruct*# x)'

it would just be:

'void foo(in BigHonkinStruct x)'

With that in mind, I *still* say both 'implicit in' and 'explicit in' should be changed to act like Walter's proposal because that is what is expected in 99% of the cases anyhow, and the other 1% is when the programmer forgot the 'out' or 'inout' with byref vars.

If the compiler detects even the simple cases, then most of the remaining 1% wouldn't compile anyway and the programmer would simply have to change it to 'out' or 'inout' as it should have been in the first place <g>.

The other issue with using 'inout' as a substitute for '&' is that you can't pass a temporary:

struct S { int x, y, z; }
S initAnS(int x, int y, int z) { S s; s.x = x, s.y = y, s.z = z; return s; }
int foo(inout S s) { return s.x * s.y * s.z; }

void main()
{
int i = foo(initAnS(10,20,30)); // Error: initAnS(10,20,30) is not an lvalue
}

The optimizations aren't my biggest deal though -- IMHO, the param. storage specifiers should mean what they say or imply, it's just that the semantics of 'in' (both implicit and explicit) need to change to be like the const or 'readonly' vars. that we've all been talking about and then perhaps (if needed) a contrary keyword like 'mutable' could be added.

Will an 'immutable implicit in' be confusing for C/++ people at first? Perhaps, but not after the compiler spits out an error for the first few trivial cases - then it will just be "Ok, if I want to modify a function parameter, I have to specify 'out' or 'inout' or make a copy.

Maybe it won't be confusing at all because in C-land they have to use a pointer and in C++ land they have to use '&' so maybe making 'implicit in' act like a byval for even byref parameters will come more naturally and it's the VB, C# and Java people wo will be confused at first.

I think Walter had it right on his first pass here:

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/26096

- Dave