Seems like idea of having only arrays and pointers immutable is still not clear ...

Dave wrote:

> Basically, what I (and I think Regan) have in mind is that the compiler
> would
> enforce 'in' params. the same way a C++ compiler would enforce "const
> [type]" or
> "const [type] &" params. for analogous types in C++. That way you would
> get 'C++
> const' functionality for params by default (implicit in params would act
> like
> Walter's 'explicit in' proposal too).
>
> The difference would be that in D, although it wouldn't be enforced
> "deeply" by
> the compiler (because as you've pointed out many times that isn't
> practical),
> implicit and explicit 'in' would carry a 'gentlemen's agreement' that
> these are
> immutable so that 'in' could have semantic value.

******************************************************************
**
**  Anyone already can do deep protection
**  enforcement in D at any level he/she wants. Now.
**  Verified by compiler at compile time in 100% of cases.
**  Without "cluttering".
**
******************************************************************

See:

class Field
{
   package char[] _name;

   public char[]  name() { return _name; }
}

'name' attribute of the Field *will* be protected. You cannot change its value outside of its package. Right?

Wrong!

char[] s = myfield.name;
s[0] = 0; // do you like it?

Again, protection is already there. It is not exactly 'const' in C/C++
but it will cover 95% protection cases. You always can implement
readonly or other restricting policy on struct/object level.
You can build as robust as needed type system *now*!

******************************************************************
**
** The main problem is that ONLY arrays and pointers
** cannot be protected in D.
**
******************************************************************
(Sorry for such style of emphasis.)

Consider this:
// somwhere in class RecordsetView ....

Field[] fields = myrecordset.fields;

// and in galaxy far, far away....

fields.sort; // pretty harmless, isn't it?

// and in far future, in other galaxy
// on the other side of the Universe
// somebody will get big bang in carefully
// crafted library.

D, you want that?

Andrew.
http://terrainformatica.com

On Thu, 14 Jul 2005 21:31:30 -0700, Andrew Fedoniouk <news@terrainformatica.com> wrote:
> Seems like idea of having only arrays and pointers immutable is still not
> clear ...
>
> Dave wrote:
>
>> Basically, what I (and I think Regan) have in mind is that the compiler
>> would
>> enforce 'in' params. the same way a C++ compiler would enforce "const
>> [type]" or
>> "const [type] &" params. for analogous types in C++. That way you would
>> get 'C++
>> const' functionality for params by default (implicit in params would act
>> like
>> Walter's 'explicit in' proposal too).
>>
>> The difference would be that in D, although it wouldn't be enforced
>> "deeply" by
>> the compiler (because as you've pointed out many times that isn't
>> practical),
>> implicit and explicit 'in' would carry a 'gentlemen's agreement' that
>> these are
>> immutable so that 'in' could have semantic value.
>
> ******************************************************************
> **
> **  Anyone already can do deep protection
> **  enforcement in D at any level he/she wants. Now.
> **  Verified by compiler at compile time in 100% of cases.
> **  Without "cluttering".
> **
> ******************************************************************
>
> See:
>
> class Field
> {
>    package char[] _name;
>
>    public char[]  name() { return _name; }
> }
>
> 'name' attribute of the Field *will* be protected. You cannot change
> its value outside of its package. Right?
>
> Wrong!
>
> char[] s = myfield.name;
> s[0] = 0; // do you like it?
>
> Again, protection is already there. It is not exactly 'const' in C/C++
> but it will cover 95% protection cases. You always can implement
> readonly or other restricting policy on struct/object level.
> You can build as robust as needed type system *now*!
>
> ******************************************************************
> **
> ** The main problem is that ONLY arrays and pointers
> ** cannot be protected in D.
> **
> ******************************************************************

IMO making 'in' immutable is part of the solution. A pointer passed as 'in' would be immutable (as would the data it referred to, or possible combinations of this). An array passed as 'in' would be immutable (as would the data to which it referred, or possible combinations of this).

The other half of the solution is to have an immutable (or mutable) keyword and allow it to be applied to return values and declared variables.

The real problem remains that it's impossible to verify the immutability in 100% of cases without hardware support or runtime overhead. (at least that is the conclusion I have come to based on these threads).

That leaves x% verifiable immutability with compile time verification.

Another point of view (raised by Walter) is aliasing, an 'in' parameter, supposedly immutable may in fact have a mutable reference in another thread and may in fact change during the function execution.

I don't know about you, but I'm not asking for protection from this. I see immutable 'in' not as a contract _to_ the function but rather one _by_ the function. In other words the guarantee is only that function itself _will not_ change the parameter, not that it will not change during function execution.

Regan

"Regan Heath" <regan@netwin.co.nz> wrote in message news:opstxuikhn23k2f5@nrage.netwin.co.nz...
> On Thu, 14 Jul 2005 21:31:30 -0700, Andrew Fedoniouk <news@terrainformatica.com> wrote:
>> Seems like idea of having only arrays and pointers immutable is still not clear ...
>>
>> Dave wrote:
>>
>>> Basically, what I (and I think Regan) have in mind is that the compiler
>>> would
>>> enforce 'in' params. the same way a C++ compiler would enforce "const
>>> [type]" or
>>> "const [type] &" params. for analogous types in C++. That way you would
>>> get 'C++
>>> const' functionality for params by default (implicit in params would act
>>> like
>>> Walter's 'explicit in' proposal too).
>>>
>>> The difference would be that in D, although it wouldn't be enforced
>>> "deeply" by
>>> the compiler (because as you've pointed out many times that isn't
>>> practical),
>>> implicit and explicit 'in' would carry a 'gentlemen's agreement' that
>>> these are
>>> immutable so that 'in' could have semantic value.
>>
>> ******************************************************************
>> **
>> **  Anyone already can do deep protection
>> **  enforcement in D at any level he/she wants. Now.
>> **  Verified by compiler at compile time in 100% of cases.
>> **  Without "cluttering".
>> **
>> ******************************************************************
>>
>> See:
>>
>> class Field
>> {
>>    package char[] _name;
>>
>>    public char[]  name() { return _name; }
>> }
>>
>> 'name' attribute of the Field *will* be protected. You cannot change its value outside of its package. Right?
>>
>> Wrong!
>>
>> char[] s = myfield.name;
>> s[0] = 0; // do you like it?
>>
>> Again, protection is already there. It is not exactly 'const' in C/C++
>> but it will cover 95% protection cases. You always can implement
>> readonly or other restricting policy on struct/object level.
>> You can build as robust as needed type system *now*!
>>
>> ******************************************************************
>> **
>> ** The main problem is that ONLY arrays and pointers
>> ** cannot be protected in D.
>> **
>> ******************************************************************
>
> IMO making 'in' immutable is part of the solution. A pointer passed as 'in' would be immutable (as would the data it referred to, or possible combinations of this). An array passed as 'in' would be immutable (as would the data to which it referred, or possible combinations of this).
>
> The other half of the solution is to have an immutable (or mutable) keyword and allow it to be applied to return values and declared variables.
>
> The real problem remains that it's impossible to verify the immutability in 100% of cases without hardware support or runtime overhead. (at least that is the conclusion I have come to based on these threads).
>
> That leaves x% verifiable immutability with compile time verification.
>
> Another point of view (raised by Walter) is aliasing, an 'in' parameter, supposedly immutable may in fact have a mutable reference in another thread and may in fact change during the function execution.
>
> I don't know about you, but I'm not asking for protection from this. I see immutable 'in' not as a contract _to_ the function but rather one _by_ the function. In other words the guarantee is only that function itself _will not_ change the parameter, not that it will not change during function execution.
>
> Regan

Regan, let's try first to do not break what is already working.
'in' is 'in' and let it live alone - it is a parameter passing designator.
Not more not less.

Second: Here I am getting serious language barrier:

"In other words the guarantee is only that function itself _will
not_ change the parameter, not that it will not change during function
 execution."

I cannot understand who will guarantee and what?
One unknown programmer to other unknown programmer?

If yes then let's just rename 'in' into  'i_swear_you'  and this is it.

Wooohoooo:

i_swear_you_not int foo( i_swear_you int bar  ) {  }

D then will be renamed into  :D

On Thu, 14 Jul 2005 22:23:30 -0700, Andrew Fedoniouk <news@terrainformatica.com> wrote:
> "Regan Heath" <regan@netwin.co.nz> wrote in message
> news:opstxuikhn23k2f5@nrage.netwin.co.nz...
>> On Thu, 14 Jul 2005 21:31:30 -0700, Andrew Fedoniouk
>> <news@terrainformatica.com> wrote:
>>> Seems like idea of having only arrays and pointers immutable is still not
>>> clear ...
>>>
>>> Dave wrote:
>>>
>>>> Basically, what I (and I think Regan) have in mind is that the compiler
>>>> would
>>>> enforce 'in' params. the same way a C++ compiler would enforce "const
>>>> [type]" or
>>>> "const [type] &" params. for analogous types in C++. That way you would
>>>> get 'C++
>>>> const' functionality for params by default (implicit in params would act
>>>> like
>>>> Walter's 'explicit in' proposal too).
>>>>
>>>> The difference would be that in D, although it wouldn't be enforced
>>>> "deeply" by
>>>> the compiler (because as you've pointed out many times that isn't
>>>> practical),
>>>> implicit and explicit 'in' would carry a 'gentlemen's agreement' that
>>>> these are
>>>> immutable so that 'in' could have semantic value.
>>>
>>> ******************************************************************
>>> **
>>> **  Anyone already can do deep protection
>>> **  enforcement in D at any level he/she wants. Now.
>>> **  Verified by compiler at compile time in 100% of cases.
>>> **  Without "cluttering".
>>> **
>>> ******************************************************************
>>>
>>> See:
>>>
>>> class Field
>>> {
>>>    package char[] _name;
>>>
>>>    public char[]  name() { return _name; }
>>> }
>>>
>>> 'name' attribute of the Field *will* be protected. You cannot change
>>> its value outside of its package. Right?
>>>
>>> Wrong!
>>>
>>> char[] s = myfield.name;
>>> s[0] = 0; // do you like it?
>>>
>>> Again, protection is already there. It is not exactly 'const' in C/C++
>>> but it will cover 95% protection cases. You always can implement
>>> readonly or other restricting policy on struct/object level.
>>> You can build as robust as needed type system *now*!
>>>
>>> ******************************************************************
>>> **
>>> ** The main problem is that ONLY arrays and pointers
>>> ** cannot be protected in D.
>>> **
>>> ******************************************************************
>>
>> IMO making 'in' immutable is part of the solution. A pointer passed as
>> 'in' would be immutable (as would the data it referred to, or possible
>> combinations of this). An array passed as 'in' would be immutable (as
>> would the data to which it referred, or possible combinations of this).
>>
>> The other half of the solution is to have an immutable (or mutable)
>> keyword and allow it to be applied to return values and declared
>> variables.
>>
>> The real problem remains that it's impossible to verify the immutability
>> in 100% of cases without hardware support or runtime overhead. (at least
>> that is the conclusion I have come to based on these threads).
>>
>> That leaves x% verifiable immutability with compile time verification.
>>
>> Another point of view (raised by Walter) is aliasing, an 'in' parameter,
>> supposedly immutable may in fact have a mutable reference in another
>> thread and may in fact change during the function execution.
>>
>> I don't know about you, but I'm not asking for protection from this. I see
>> immutable 'in' not as a contract _to_ the function but rather one _by_ the
>> function. In other words the guarantee is only that function itself _will
>> not_ change the parameter, not that it will not change during function
>> execution.
>>
>> Regan
>
> Regan, let's try first to do not break what is already working.
> 'in' is 'in' and let it live alone - it is a parameter passing designator.
> Not more not less.

This is where we disagree. For all the reasons previously mentioned.

> Second: Here I am getting serious language barrier:
>
> "In other words the guarantee is only that function itself _will
> not_ change the parameter, not that it will not change during function
>  execution."
>
> I cannot understand who will guarantee and what?

Compiler will check function for immutable violations.

> One unknown programmer to other unknown programmer?

The programmer of the function will guarantee it, the compiler will enfore it.

Regan

> Consider this:
> // somwhere in class RecordsetView ....
>
> Field[] fields = myrecordset.fields;
>
> // and in galaxy far, far away....
>
> fields.sort; // pretty harmless, isn't it?
>
> // and in far future, in other galaxy
> // on the other side of the Universe
> // somebody will get big bang in carefully
> // crafted library.
>
> D, you want that?

I'm less worried about this happening in D than in other languages since D
emphasizes COW so strongly. Let me make an analogy with the law that in the
US cars should drive on the right side of the road. Now one can drive a car
on either side and there are odd cases where it does happen and sometimes an
accident results. But usually it doesn't. That situation is better than a
country where there is no law about what side to drive on and so every
driver needs to be extremely careful about what's coming at them. Would the
US have fewer car accidents if it were impossible to drive on the wrong
side? Yes. Would it be a significant difference? Probably not.
That analogy isn't perfect since so many users of D will come from C++ or
Java they are used to driving on the wrong side of the road (so to speak)
and they don't know the rules of the road in D. To me that's the strongest
rationale for immutability (for catching errors not for optimizations) in D:
protection from people who don't know the rules of the road in D.

In article <db8apd$269e$1@digitaldaemon.com>, Ben Hinkle says...
>
>> Consider this:
>> // somwhere in class RecordsetView ....
>>
>> Field[] fields = myrecordset.fields;
>>
>> // and in galaxy far, far away....
>>
>> fields.sort; // pretty harmless, isn't it?
>>
>> // and in far future, in other galaxy
>> // on the other side of the Universe
>> // somebody will get big bang in carefully
>> // crafted library.
>>
>> D, you want that?
>
>I'm less worried about this happening in D than in other languages since D
>emphasizes COW so strongly. Let me make an analogy with the law that in the
>US cars should drive on the right side of the road. Now one can drive a car
>on either side and there are odd cases where it does happen and sometimes an
>accident results. But usually it doesn't. That situation is better than a
>country where there is no law about what side to drive on and so every
>driver needs to be extremely careful about what's coming at them. Would the
>US have fewer car accidents if it were impossible to drive on the wrong
>side? Yes. Would it be a significant difference? Probably not.
>That analogy isn't perfect since so many users of D will come from C++ or
>Java they are used to driving on the wrong side of the road (so to speak)
>and they don't know the rules of the road in D. To me that's the strongest
>rationale for immutability (for catching errors not for optimizations) in D:
>protection from people who don't know the rules of the road in D.
>

I'm with you - it's not only the optimizations, it's consistency, clarity and ease-of-use that I think will benefit here.

There were adjustments that C/C++ users had to make to move to Java w.r.t. parameter passing and I don't think it will be too much to ask for new D users as well. Especially since D doesn't have 'const' and '&' to confuse things. And in the long run will make things easier once one is accustomed to the way things should be done, because, again, it's more consistent.

To an earlier statement about "in" being just 'a parameter passing designator', as such it clearly (in my mind at least) should enforce that expectation (at least to a pratical degree) consistently regardless of if the type being passed lives on the stack or the heap. in/out/inout are supposed to be analogous to the IDL. In the IDL, a change made to an "in" referant should not live past the function call. For example, in DCOM at least, changes to an "in" referant are simply not propogated back to the callee (and no, I'm not suggesting that kind of overhead here). Since there is no de/serialization barrier for D function calls, that barrier should be what the compiler allows to be consistent with the IDL idea.

The way C++ "const" parameters are treated by the compiler I think is a reasonable demarkation as to what should be enforced for 'in' parameters in D.

- Dave

>> To me that's the strongest
>>rationale for immutability (for catching errors not for optimizations) in
>>D:
>>protection from people who don't know the rules of the road in D.
>
> I'm with you - it's not only the optimizations, it's consistency, clarity
> and
> ease-of-use that I think will benefit here.

To be clear when I said "(for catching errors not for optimizations)" I meant "the rationale for adding immutability for catching errors as opposed to the rationale for adding immutability optimizations". I didn't mean that the catching errors rationale is stronger than the optimizations rationale or any other rationale. I just meant that the rationale for catching errors will in practice only catch people who don't know D's rules of the road.

In article <db8i4p$2bhm$1@digitaldaemon.com>, Ben Hinkle says...
>
>>> To me that's the strongest
>>>rationale for immutability (for catching errors not for optimizations) in
>>>D:
>>>protection from people who don't know the rules of the road in D.
>>
>> I'm with you - it's not only the optimizations, it's consistency, clarity
>> and
>> ease-of-use that I think will benefit here.
>
>To be clear when I said "(for catching errors not for optimizations)" I meant "the rationale for adding immutability for catching errors as opposed to the rationale for adding immutability optimizations". I didn't mean that the catching errors rationale is stronger than the optimizations rationale or any other rationale. I just meant that the rationale for catching errors will in practice only catch people who don't know D's rules of the road.
>

For the record, they are about equal in weight for me but I could pretty easily be persuaded that the catching errors part is more important.. Even if optimization opportunities are not presented. What I've been blathering on about regarding making 'in' like 'const' still makes enough sense to me to make it a worthwhile change IMHO.

Another point on the potential optimizations that may be a hangup to this 'in' as 'const' idea (not directed at you Ben, just more thoughts on the matter). An optimization should not be done unless it is safe. Safe to me means that both the unoptimized and optimized versions will always produce a correct result given the same input if the rules of the language are followed. In this case (with the proposed new rules for 'in') the result could be wrong whether or not an optimization is performed if the rules aren't followed, but either way will be correct 100% of the time if the rules are followed. That doesn't mean the compiler has to strictly enforce those rules, and it doesn't mean that just because the D optimizer produces a different result than a C optimizer for what *looks like* the same code, that the D optimizer is wrong - it's just operating under a different set of rules. D is *not* C ;)

COW for example is a 'rule' of D that allows optimizations, but the rule is not enforced nor is COW done automagically by the compiler or runtime. If the rules of COW aren't followed, then an incorrect result may happen regardless of compiler optimizations. It's up to the programmer to follow the rules and if the compiler gives them help in that by catching transgressions to rules like COW and 'in', more power.

"Regan Heath" <regan@netwin.co.nz> wrote in message news:opstx8grmf23k2f5@nrage.netwin.co.nz...
> On Thu, 14 Jul 2005 22:23:30 -0700, Andrew Fedoniouk <news@terrainformatica.com> wrote:
>> "Regan Heath" <regan@netwin.co.nz> wrote in message news:opstxuikhn23k2f5@nrage.netwin.co.nz...
>>> On Thu, 14 Jul 2005 21:31:30 -0700, Andrew Fedoniouk <news@terrainformatica.com> wrote:
>>>> Seems like idea of having only arrays and pointers immutable is still
>>>> not
>>>> clear ...
>>>>
>>>> Dave wrote:
>>>>
>>>>> Basically, what I (and I think Regan) have in mind is that the
>>>>> compiler
>>>>> would
>>>>> enforce 'in' params. the same way a C++ compiler would enforce "const
>>>>> [type]" or
>>>>> "const [type] &" params. for analogous types in C++. That way you
>>>>> would
>>>>> get 'C++
>>>>> const' functionality for params by default (implicit in params would
>>>>> act
>>>>> like
>>>>> Walter's 'explicit in' proposal too).
>>>>>
>>>>> The difference would be that in D, although it wouldn't be enforced
>>>>> "deeply" by
>>>>> the compiler (because as you've pointed out many times that isn't
>>>>> practical),
>>>>> implicit and explicit 'in' would carry a 'gentlemen's agreement' that
>>>>> these are
>>>>> immutable so that 'in' could have semantic value.
>>>>
>>>> ******************************************************************
>>>> **
>>>> **  Anyone already can do deep protection
>>>> **  enforcement in D at any level he/she wants. Now.
>>>> **  Verified by compiler at compile time in 100% of cases.
>>>> **  Without "cluttering".
>>>> **
>>>> ******************************************************************
>>>>
>>>> See:
>>>>
>>>> class Field
>>>> {
>>>>    package char[] _name;
>>>>
>>>>    public char[]  name() { return _name; }
>>>> }
>>>>
>>>> 'name' attribute of the Field *will* be protected. You cannot change its value outside of its package. Right?
>>>>
>>>> Wrong!
>>>>
>>>> char[] s = myfield.name;
>>>> s[0] = 0; // do you like it?
>>>>
>>>> Again, protection is already there. It is not exactly 'const' in C/C++
>>>> but it will cover 95% protection cases. You always can implement
>>>> readonly or other restricting policy on struct/object level.
>>>> You can build as robust as needed type system *now*!
>>>>
>>>> ******************************************************************
>>>> **
>>>> ** The main problem is that ONLY arrays and pointers
>>>> ** cannot be protected in D.
>>>> **
>>>> ******************************************************************
>>>
>>> IMO making 'in' immutable is part of the solution. A pointer passed as 'in' would be immutable (as would the data it referred to, or possible combinations of this). An array passed as 'in' would be immutable (as would the data to which it referred, or possible combinations of this).
>>>
>>> The other half of the solution is to have an immutable (or mutable) keyword and allow it to be applied to return values and declared variables.
>>>
>>> The real problem remains that it's impossible to verify the immutability in 100% of cases without hardware support or runtime overhead. (at least that is the conclusion I have come to based on these threads).
>>>
>>> That leaves x% verifiable immutability with compile time verification.
>>>
>>> Another point of view (raised by Walter) is aliasing, an 'in' parameter, supposedly immutable may in fact have a mutable reference in another thread and may in fact change during the function execution.
>>>
>>> I don't know about you, but I'm not asking for protection from this. I
>>> see
>>> immutable 'in' not as a contract _to_ the function but rather one _by_
>>> the
>>> function. In other words the guarantee is only that function itself
>>> _will
>>> not_ change the parameter, not that it will not change during function
>>> execution.
>>>
>>> Regan
>>
>> Regan, let's try first to do not break what is already working.
>> 'in' is 'in' and let it live alone - it is a parameter passing
>> designator.
>> Not more not less.
>
> This is where we disagree. For all the reasons previously mentioned.
>
>> Second: Here I am getting serious language barrier:
>>
>> "In other words the guarantee is only that function itself _will
>> not_ change the parameter, not that it will not change during function
>>  execution."
>>
>> I cannot understand who will guarantee and what?
>
> Compiler will check function for immutable violations.

It is easy to say, try to describe such "check".

>
>> One unknown programmer to other unknown programmer?
>
> The programmer of the function will guarantee it, the compiler will enfore it.

How?

class Recordset
{
    Field[] fields() { ... } // supposed to be readonly
    Value[] values() { ... } // may be readonly, may be not
}

static Field f;

bool Foo( in Recordset rs )
{
    rs.fields[0].foo();
    rs.values[0].bar();
    f = rs.fields[0];
}

Given Foo example above try to describe
what needs to be done by compiler to
verify immutability of rs parameter.

Dave wrote:

> In article <db8i4p$2bhm$1@digitaldaemon.com>, Ben Hinkle says...
> 
>>>>To me that's the strongest
>>>>rationale for immutability (for catching errors not for optimizations) in D:
>>>>protection from people who don't know the rules of the road in D.
>>>
>>>I'm with you - it's not only the optimizations, it's consistency, clarity and
>>>ease-of-use that I think will benefit here.
>>
>>To be clear when I said "(for catching errors not for optimizations)" I meant "the rationale for adding immutability for catching errors as opposed to the rationale for adding immutability optimizations". I didn't mean that the catching errors rationale is stronger than the optimizations rationale or any other rationale. I just meant that the rationale for catching errors will in practice only catch people who don't know D's rules of the road.
>>
> 
> 
> For the record, they are about equal in weight for me but I could pretty easily
> be persuaded that the catching errors part is more important.. Even if
> optimization opportunities are not presented. What I've been blathering on about
> regarding making 'in' like 'const' still makes enough sense to me to make it a
> worthwhile change IMHO.
> 
> Another point on the potential optimizations that may be a hangup to this 'in'
> as 'const' idea (not directed at you Ben, just more thoughts on the matter). An
> optimization should not be done unless it is safe. Safe to me means that both
> the unoptimized and optimized versions will always produce a correct result
> given the same input if the rules of the language are followed. In this case
> (with the proposed new rules for 'in') the result could be wrong whether or not
> an optimization is performed if the rules aren't followed, but either way will
> be correct 100% of the time if the rules are followed. That doesn't mean the
> compiler has to strictly enforce those rules, and it doesn't mean that just
> because the D optimizer produces a different result than a C optimizer for what
> *looks like* the same code, that the D optimizer is wrong - it's just operating
> under a different set of rules. D is *not* C ;)
> 
> COW for example is a 'rule' of D that allows optimizations, but the rule is not
> enforced nor is COW done automagically by the compiler or runtime. If the rules
> of COW aren't followed, then an incorrect result may happen regardless of
> compiler optimizations. It's up to the programmer to follow the rules and if the
> compiler gives them help in that by catching transgressions to rules like COW
> and 'in', more power.
> 
> 

How about just an expression like the following( weird off the top of my head, look at the semantics, not syntax):


char[] a = "Some valuable data";
const( a )
{
  func1(a);
  func2(a);
}

Then the compiler could do an analysis of the functions which are called in the const-block and warn if functions called within attempt to change the data.

Feasible?

-DavidM

PS.  Curious as to what instances do you think const presents optimizations?