Why can't we define re-assignable const reference variable?

[Sergey Gromov]

Janice Caron <caron800 at googlemail.com> wrote:
> On 20/02/2008, Sergey Gromov <snake.scaly at gmail.com> wrote:
> >  > I mean, it was just too confusing for words. No way
> >  > can we /ever/ go back to that. For any type, T, const(T) absolutely
> >  > /must/ mean that T is const.
> >
> > My concept is very simple.  Everything within the scope of const is
> >  const, everything outside is not.
> 
> Not good enough. Everything inside the /brackets/ must be const.
> Otherwise, don't call it const, call it something else. Call it
> "tailconst" or "rebindable" or whatever, but don't call it const,
> because it isn't.
> 
> I want to be able to introduce newbies to D and tell them how
> wonderful it is. I can't do that if const(T) doesn't mean const T.
> Really.

I am a newbie.  I want consistency in the language.  This is what 
attracts me.

> Back it D2.007 - the version of const that you like, but most people
> didn't, we had five different kinds of const. Count them. Five. They
> were:
> 
>     final T // head const
>     const(T) // tail const
>     const T // fully const
>     invariant(T) // tail invariant
>     invariant T // fully invariant

Can't see anything wrong here.  Except that you omit the variable for 
some reason.  Const only has meaning when applied to a reference.  So:

	const(T) x;	// tail const
	const{T x;}	// full const

Simple.  Clean.

> ...and that's not counting the use of "in" in function declarations.
> It was just too silly for words.

As a newbie, I was really confused by a number of ways one can specify 
constness of an argument.  This deserves a separate post.  What I'm sure 
of, no "const," "const{}" or "const:" should be allowed there which all 
are different forms of a const attribute.

Note that my confusion was about 2.010 which you probably consider 
'fixed.'

> Right now, in D2.011, "invariant(char)[]" is a string. That makes
> absolutely perfect sense. Long may that remain.

Can't see any sense in making ptr and length variable.  This makes 
strings 'somewhat const' to me.  Not really const.

> What is your problem with just choosing a different word, or a
> different syntax? You'd get a lot more support for the idea that way.
> I certainly wouldn't be arguing with you in that case.

Actually, const() syntax is already different from const attribute.  
Probably if we had a tailconst attribute instead, so that it was 
possible to write

tailconst
{
	C c;
	int x;	// either illegal, or not affected
}

this would be quite enough, and pretty consistent.  This should of 
course deprecate the use of non-attribute const() form.  But it would 
have a strange effect for structs anyway: with "tailconst S s;", which 
in my syntax is "const(S) s;", you won't be able to "s.whatever = 
newValue", but it would be legal to

	tailconst S s = initializer;
	S var = s;	// contents copied
	var.whatever = newValue;
	s = var;	// legal for tailconst

otherwise generic algorithms won't work.

I see your main concern is educational.   This is resolved very simple, 
too: teach that /everything/ in D are objects, and everything is by 
reference.  But compiler resolves many of the references at compile 
time.  This is not strictly true because most references are resolved at 
language design time, but it doesn't invalidate the thesis itself.

-- 
SnakE