Read-only array reference

[Hasan Aljudy]

Bruno Medeiros wrote:
> Hasan Aljudy wrote:
<snip proposal>
>>
>> So, what do you think about this proposal?
>> Is it practical? Does it solve most of the const issues?
>> Does it even make sense, or is it just stupid all-together?
>>
<snip>
> 
> 
> Indeed, if I understood your proposal correctly, I think it is 
> unpractical, if not down-right senseless. :p
> 
> Why?
> Ok, first, what do we want exactly? We want a mechanism that allows us 
> to specify a readonly contract for a variable, that is, declare a 
> variable (or function parameter) that should be a "read-only view" 
> (using Andrei Alexandrescu's term) of another data/object.

No, if you check my proposal, it was a reply to kris's statement:
"this whole discussion is basically about array types, since others can 
happily be passed by value anyway."

and that is also my understanding.

structs, enums, and native types can hapily be passed by value - no 
const feature needed.
classes can provide interfaces for read-only access, or a class can be 
made immutable - no const feature needed.

The only thing left is arrays.

Look at Java, it has one of the best/richest/most robust libraries I've 
ever seen, and it doesn't have any const feature per se. The only thing 
it has that D doesn't is immutable strings.

So, according to my understanding of the issue, if D would have 
read-only array references, the const issue would mostly be solved.

> 
> Your proposal allows us to do that, but one has to encapsulate/declare 
> the var, inside a "constant array of the type of that var"? Why not just 
> declare it as a "constant var of it's respective type"? For example, if 
> I want to declare a function that receives a readonly Object, I have to:
> 
>   ... func(Object[$] obj) {
>      obj[0].doStuff();
>      int b = obj[0].num;

No, if you do this, according to my proposal, then you cannot modify the 
list of "Object" references inside "obj", but there's no guarantee on 
the actual instances that are referred to by these references.

> Have to access obj as an array, even though it is only one Object?
> Why not just:
> 
>   ... func(readonly Object obj) {
>      obj.doStuff();
>      int b = obj.num;
> 
> Similarly, on the return type:
> 
<snip>
> 
>   readonly Object func(...) {
>     obj2 = new Object();
>     ...
> 
>     // **** Want to return a readonly obj2: ****
>     return obj2;
>   }
> 

I am under the impression that C++ like constness is out of the question <g>

> 
> Plus, your proposal is omissive in many important aspects. For example, 
> how about the transitive property? If I have:
>   int **[$] cptr;
> can I change *(cptr[0]) or **(cptr[0])? Similarly for a struct:
>   struct Fuu { int[] iar; }
>   Fuu[$] cfuu;
> can I change (cfuu[0]).iar[ix] ?  (where ix is some index)

you can do what you want with the array reference ..
when ever you access an element of the array you're getting a copy of 
that element.
if that element is a pointer, you're getting a copy of the pointer.
if you don't want this to happen, don't frickin use pointers when you 
don't want others to manipulate your array!!

<snip>
> 
> BTW, Javari is the Java modification described in that paper, which has 
> reference immutability added to the Java language.
> 

I need to ask .. what did javari *really* add to java?
Is there something that's impossible with java but possible with javari?

.
.
.

no?
I thought so.