[Issue 1961] Allow "scoped const" contracts

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=1961





------- Comment #3 from andrei at metalanguage.com  2008-03-31 22:59 -------
(In reply to comment #2)
> On 01/04/2008, d-bugmail at puremagic.com <d-bugmail at puremagic.com> wrote:
> > Since some people already complain that the const
> >  regime is already complicated,
> 
> Yes, they complain about the fact that the current regime forces us to
> duplicate many functions three times. (C++ makes us do it twice, which
> is bad enough!) :-)
> 
> They complain about the choice of words, "const" and "invariant". They
> /especially/ complain most furious about the word "enum", and the
> pointlessness of "in".
> 
> They complain that "const R f()" looks like f is returning a const(R).
> 
> But they don't (often) complain about transitivity, or anything that
> really matters.

I think the choice of words is a classic dilemma. Whatever words are chosen,
some won't like them, and they will be the ones to voice their opinion. I think
this will just pass. What I'm worried about is arms thrown in the air, "This
was supposed to be simpler than C++!" etc.

I agree that prefix const for methods is confusing. I personally like
const(this), as you proposed. 

I believe "in" will become more interesting once we figure "scope" out (no pun
intended).

And enum... you'll have to yank that out from my dead cold hands. Extending
enum instead of adding yet another way of defining symbolic constants is The
Right Thing to do. I am sure people would have realized how ridiculous the
whole "manifest" thing is if we first proposed it. We just can't define one
more way for each kind of snow there is.

But by and large, as Walter said, although the current constancy regime is
excellent, we need to find a good PR consultant :o).

> >  I fear that people might say that inout adds
> >  even more complication.
> 
> It's a wildcard. People understand wildcards. It's simple enough to
> explain in terms of "this stands for mutable, const or invariant".
> From that point of view, it can be presented not as a new flavor of
> constancy, but as token which stands for any of the existing flavors.
> I think that with that description, people will get it.

I didn't say they don't understand. I just said they have to run to the manual
when they see it. It's yet another thing to learn. 

> However, I agree that simplifying const is something we should do
> /first/, before throwing in new stuff. Priorities. :-)

The challenge is how...


--