any news on const/invariant?

[0ffh]

Derek Parnell wrote:
> On Tue, 27 Nov 2007 12:12:51 +0100, 0ffh wrote:
>>  I think the difference is not so grand as you make it.
> 
> I do not think it as "so grand", whatever that means. 
> 
> My point is that any help that a compiler can give to the coder in
> preventing coding errors is a worthwhile pursuit. Sure, there are
> diminishing returns and maybe this is one of them. I'm not sure because I
> have not analyzed any empirical statistics.

Neither am I. But I've lived a reasonably long life coding without "const"
of any kind, so I really wonder what all the fuzz is about, when a simple,
straightforward implementation (probably better than none) is not enough.

> I am simply saying, and this seems to be very hard to get across, that if
> there is some syntax to express the design concept of "the pointer may not
> be modified but the items pointed to can be", then the compiler can detect
> at compile time when the coder attempts to change the pointer, and issue
> the appropriate warning.

Well, the point is not so hard to get across as you think. I agree that,
ideally, any coding error should be flagged by the compiler. I suppose we
agree that this gets hard as the potential errors get nontrivial.
Give me some room to hyperbole, and I'll tell you this: We can make a super
coding-error resistant language by just requiring that every function must 
be coded in triplicate, in different languages. The compiler will check if
all three implementations are identical, otherwise it'll fail with an
error. This is where you're heading, albeit from a long way away. =)

> A compiler exists to make life easier for the coder.
> If this truely is a case where "Head const turned out to be an
> unexplainable, incomprehensible feature." and/or is too hard to implement,
> then I'll go with the flow. I haven't seen evidence of that being the case
> yet, regardless of Walter's statements so far.

Actually, I'll now change hats and tell you my opinion:
Simple features should be easily reachable, advanced features should exist.
So I think that simple const as is now planned should be reachable using
a simple syntax, and advanced concepts of const should ideally be possible,
but in case of doubt by using a more complicated syntax. I don't think that
the last const-proposal by Walter was really much too complicated. The
problem is more that most people here were immediately trying to grok it in
all it's aspects, and some were a bit turned off that some of those tries
have not met instant gratification.
And apart from all that - from a /very/ personal POV - I don't need it. =)

regards, frank