const

[Jason House]

Sean Kelly Wrote:

> == Quote from Oskar Linde (oskar.lindeREM at OVEgmail.com)'s article
> > Walter Bright wrote:
> > > I appreciate the time and effort you made to explain your thoughts. I'll
> > > try and answer them.
> > Thank you for your explanation. It must be quite an effort battling all
> > the negativism against it. I'll try to make this a constructive post.
> > > Benji Smith wrote:
> > >> CONST
> > [snip]
> > > I understand your and others' frustration with const, and here's what I
> > > think it is based on:
> ...
> 
> Well said.  Some questions below.
> 
> ...
> > Now, I will not discuss the keywords used for reference constancy, but I
> > think the keyword used to declare constants should be "const". Apart
> > from being how it already almost works in D2, it would have the major
> > advantage of making:
> > const x = 5;
> > mean exactly the same thing in D1 and D2!
> > So, without any loss of power, transitivity or anything else, one can
> > simplify the language and make the constancy of plain data compatible
> > between D2 and D1.
> 
> I think the need for const vs. invariant in D 2.0 is that the compiler isn't
> smart enough to know when the referenced data should actually never
> change, and because a bunch of interesting optimizations are available
> when the data really doesn't ever change, we have a keyword to hint to
> the compiler that this is true.  It's much like "register" in C/C++.  That
> said, I'm still not convinced that it's a good idea to allocate an additonal
> keyword simply to convey this information to the compiler.  I'd still like
> to believe that there's a better way, and like "register", I expect "invariant"
> to be rendered completely useless at some point in the future.


In my dream world implementation of all things const, D would do the following things:
  readonly (ro, or some variant) would mean a read only view
  invariant would mean the data never changes, period
  manifest declares a manifest constant
  const would have two meanings:
    1. Variable declarations - a true constant
    2. Function parameters - a promise not to modify the data

In both forms of const, optimizations are the compiler's job.

A constant *might* be made a manifest constant, but that's not the programmer's concern.  The compiler should make it manifest as appropriate (depends on both type and usage of the type)

As function inputs, it signifies the programmer's intent.  It's up to the compiler to deduce readonly or invariant based on what's getting fed to the function.  This vision has led me down the road of trying to figure out implicit const-related casting rules such that the compiler *could* do such optimizations.

One day maybe people will share that vision and we can talk about improving the const design instead of defending its current form.

    



> 
> 
> Sean