Jarrett Billingsley wrote:
> "Sean Kelly" <sean@f4.ca> wrote in message news:f3uoj5$1b1i$1@digitalmars.com...
> 
>> Most array algorithms would apply.  But I'm still not sure I see the point of having an immutable reference, because it's just passed by value anyway.  Who cares if the size of the array is modified within a function where it's not passed by reference?  The change is just local to the function anyway.
> 
> If that array is pointing into some meaningful area of memory (like in the example, a texture buffer), resizing the array could (probably would) move the array around, which I guess isn't illegal but then the function operating on the array wouldn't be accessing the correct place.  Prevent them from changing the length, it prevents them from accessing anywhere but there. 

Well yeah.  I don't personally think this is a problem because it doesn't affect the callee in any way, but I can see how others might disagree.  Doesn't 'final' do this now though?


Sean

Bruno Medeiros wrote:
> Walter Bright wrote:
>> Derek Parnell wrote:
>>> What is the syntax for an immutable array of mutable characters?
>>
>> There isn't one. Such a construct is appealing in the abstract, but I haven't run across a legitimate use for it yet.
> 
> What, there isn't one? Isn't that what final does? Like this:
>   final char[] charar = new char[](20);
> 
>   charar[1] = 'x'; // Allowed
>   charar = new char[](20); // Not allowed
>   charar.length = 10; // Not allowed

Final only works at the outermost level. There is no way to have a mutable pointer to a const pointer to mutable data.

Started new thread with reply: resizeable arrays: T[new]

Derek Parnell wrote:
> On Sun, 27 May 2007 12:06:06 -0700, Walter Bright wrote:
> 
>> Derek Parnell wrote:
>>> See, this is what is weird ... I can have an invariant string which can be
>>> changed, thus making it not really invariant in the English language sense.
>>> I'm still thinking that "invariant" means "does not change ever". 
>> Where you're going wrong is that there are two parts to a dynamic array - the contents of the array, and the ptr/length values of the array.
>>
>> 	invariant(char)[]
>>
>> immutalizes (look ma! I coined a new word!) only the contents of the array.
>>
>> 	invariant(char[])
>>
>> immutalizes the contents and the ptr/length values.
> 
> I know that you know that I know this about arrays already (did I really
> just say that!?) so I assume you are talking to the greater audience that
> we have here.
> 
> So to immutalize (see it must be a real word as someone else is using
> it<g>) just the ptr/length parts I'd use ...
> 
>   invariant char([])   ?????
>   char invariant[]     ????
> 
> and 
> 
>   invariant char[]
> 
> is the same as 
> 
>   invariant (char[])
> 
> right?
> 
> 
>>> But it seems that I'm wrong ...
>>>
>>>  invariant char[] x;  x = "abc".dup;  // The string 'x' now contains "abc";
>>>  x = "def".dup;  // The string (which is not supposed to change
>>>                  // i.e invariant) has been changed to "def".
>>>
>>> Now this is counter-intuitive (read: *WEIRD*), no?
> 
> In my thinking the term 'string' refers to the whole ptr/length/content
> group. So when one says that a string is immutable I'm thinking they are
> saying that every aspect of the string does not change. This is where I
> suspect that we are having terminology problems.
>  
>> The first issue is that you've confused:
>> 	invariant char[] x;
>> with:
>> 	invariant(char)[] x;
> 
> Yep - guilty as charged, your honour. Actually it is not so much confusion
> rather just a poor typing regime, as I really did understand the difference
> but I typed in the wrong thing. But let's continue ...
> 
>> Remember, there are TWO parts to an array, and the invariantness can be controlled for either independently, or both. This isn't different from in C++ there are two parts to a char*, the char part, and the pointer part.
> 
> What is the syntax for controlling *just* the reference part of an array?
> 
>>> Okay, I've got that now ... but how to remember that two terms that mean
>>> the same in English actually mean different things in D <G>
>> English is imprecise and ambiguous, that's why we have mathematical languages, and programming languages.
> 
> Has anyone got a dictionary in which "constant" and "invariant" are not
> synonyms? Sure I agree that "English is imprecise and ambiguous" when taken
> as a whole but not every word is such. So when one uses English words in a
> programming language the natural thing is to assume that the programming
> language meaning has a high degree of correlation with the English meaning.
> 
> 
>>>   invariant char[] x; // The data pointed to by 'x' cannot be changed
>>>                       // by anything anytime during the execution
>>>                       // of the program.
>>>                       // (So how do I populate it then? Hmmmm ...)
>> You can't populate an invariant(char)[] array (which is what you meant, not invariant char[]). The way to get one is to cast an existing array to invariant.
> 
>   char[] name;
>   name = GetUserName();
> 
>   invariant (char)[] newb = cast(invariant)name;
> 
>   void foo() { name[0] = toUpperCase(name[0]); }  // Is this valid?
> 
>   foo(); // What about this?
> 
>>>   const char[] y;    // The data pointed to by 'y' cannot be changed
>>>                      // by anything anytime during the execution
>>>                      // of the program when using the 'y' variable,
>>>                      // however using another variable that also
>>>                      // refers to y's data, or some of it, is ok.
>> Yes, but here again, const(char)[].
> 
> Yeah yeah yeah ... I can see how an alias is going to be a boon.
> 
> 
>>> Thanks. So 'final' means that it can be changed (from its initial default
>>> value) once and only once.
>> No. 'final' means it is set only at initialization.
> 
> And initialization means "on the same statement that declares the
> variable"? 
> 
> In English, initialization means whenever some thing is initialized rather
> than one specific type of initialization.
> 
> 
>>> /* --- Scenario #1 --- */
>>>   final int r;
> 
> Ok, so the above "initializes" the symbol to zero, being the default value
> of an int, and it cannot be changed to anything else now.
> 
>>>   r = randomer(); // succeeds
>> Nope, this fails. Try:
>> 	final int r = randomer();
> 
> Got it.
> 
>>> I have no real knowledge of C++ or its const, and I'm still weirded out by
>>> it all <G>
>> I'm beginning to realize that unless one understands how types are represented at run time, one will never understand const.
> 
> Nah, it's probably just me that's being thick, ... and I *do* understand
> the run-time implementation of the D constructs.
> 
FWIW, I feel the documentation is going to need LOTS of examples.  The text is sufficient to point folk in the right general direction, but the examples will be necessary to highlight the minimal distinctions.

And as my C++ is really quite minimal, and predates templates being generally available, I don't think I'm being confused by how C++ uses it.

OTOH, I fequently need to do things like:
char[] stuff	=	"alperferous";
stuff	=	stuff[0..5] ~ "if" ~ stuff[5..length];
(silly example, but it's short!)
Given what I've read so far I suppose this means that I just keep avoiding const & invariant, but I do think of this as string manipulation, as thus "Strings are constant by default" sets warning bells ringing.  (Probably inappropriately, admittedly.  But perhaps this should be said differently in the documentation.)