Does D support it at all?

"Chris Sokol" <chris@echosproject.org> wrote in message news:bgv1t6$1ijj$1@digitaldaemon.com...
> Does D support it at all?

D supports const as a storage class, but not as a type modifier.

What's the rationale again?

"Walter" <walter@digitalmars.com> wrote in message news:bgvd22$1sna$1@digitaldaemon.com...
>
> "Chris Sokol" <chris@echosproject.org> wrote in message news:bgv1t6$1ijj$1@digitaldaemon.com...
> > Does D support it at all?
>
> D supports const as a storage class, but not as a type modifier.
>
>

1) Too complicated (look at all the wierd rules and perterbations it causes
with template specialization and overloading).
2) Too confusing.
3) Insufficient utility.
4) Optimizers can't reliably use the info anyway.
5) Ugly.

"Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bgvdh2$1t4n$1@digitaldaemon.com...
> What's the rationale again?
>
> "Walter" <walter@digitalmars.com> wrote in message news:bgvd22$1sna$1@digitaldaemon.com...
> >
> > "Chris Sokol" <chris@echosproject.org> wrote in message news:bgv1t6$1ijj$1@digitaldaemon.com...
> > > Does D support it at all?
> >
> > D supports const as a storage class, but not as a type modifier.
> >
> >
>
>

"Walter" <walter@digitalmars.com> wrote in news:bh1f3a$psi$1@digitaldaemon.com:

> 4) Optimizers can't reliably use the info anyway.

Optimizing *library writers* need that info to write optimized code that is *robust*.

Quotting from Phobos string.d:

/************** Constants ****************/
const char[16] hexdigits = "0123456789ABCDEF";

/***********************************************
* Convert to char[].
*/
char[] toString(uint u)
{
   char[uint.size * 3] buffer;
   int ndigits;
   char c;
   char[] result;

   ndigits = 0;
   if (u < 10)
      // Avoid storage allocation for simple stuff
      result = digits[u .. u + 1];
   else
   {
      while (u)
      {
         c = (u % 10) + '0';
         u /= 10;
         ndigits++;
         buffer[buffer.length - ndigits] = c;
      }
      result = new char[ndigits];
      result[] = buffer[buffer.length - ndigits .. buffer.length];
   }
   return result;
}


Looks like nice code ?

But the code isn't robust as this example proves:
int main(char args[][])
{
   char[] digit=toString(1);
   assert(digit[0] == '1');
   digit[0]='9';

   char[] digit2=toString(1);
   assert(digit2[0] == '1');   // assertion fails !
   return 0;
}

> 1) Too complicated (look at all the wierd rules and perterbations it
causes
> with template specialization and overloading).

I cannot contest that it's complicated, as you're the expert on compiler-waltering.

> 2) Too confusing.

Disagree. Seems perfectly clear to me.

> 3) Insufficient utility.

You couldn't be more wrong

> 4) Optimizers can't reliably use the info anyway.

Have no knowledge here

> 5) Ugly.

Not meaningful. Most things in SE are ugly until you get used to them like, say, D's templates ... ;)

"Farmer" <itsFarmer.@freenet.de> wrote in message news:Xns93D2F2BCBD361itsFarmer@63.105.9.61...
> "Walter" <walter@digitalmars.com> wrote in news:bh1f3a$psi$1@digitaldaemon.com:
>
> > 4) Optimizers can't reliably use the info anyway.
>
> Optimizing *library writers* need that info to write optimized code that
is
> *robust*.
>
> Quotting from Phobos string.d:
>
> /************** Constants ****************/
> const char[16] hexdigits = "0123456789ABCDEF";
>
> /***********************************************
> * Convert to char[].
> */
> char[] toString(uint u)
> {
>    char[uint.size * 3] buffer;
>    int ndigits;
>    char c;
>    char[] result;
>
>    ndigits = 0;
>    if (u < 10)
>       // Avoid storage allocation for simple stuff
>       result = digits[u .. u + 1];
>    else
>    {
>       while (u)
>       {
>          c = (u % 10) + '0';
>          u /= 10;
>          ndigits++;
>          buffer[buffer.length - ndigits] = c;
>       }
>       result = new char[ndigits];
>       result[] = buffer[buffer.length - ndigits .. buffer.length];
>    }
>    return result;
> }
>
>
> Looks like nice code ?
>
> But the code isn't robust as this example proves:
> int main(char args[][])
> {
>    char[] digit=toString(1);
>    assert(digit[0] == '1');
>    digit[0]='9';
>
>    char[] digit2=toString(1);
>    assert(digit2[0] == '1');   // assertion fails !
>    return 0;
> }

The assumption that Phobos uses throughout is copy-on-write. That means that unless you're the generator of a string, if you modify it, make a copy first. This avoids the problems the code snippet shows, while retaining max performance.

"Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bh3rhp$u1$1@digitaldaemon.com...
> > 1) Too complicated (look at all the wierd rules and perterbations it
> causes
> > with template specialization and overloading).
> I cannot contest that it's complicated, as you're the expert on compiler-waltering.
>
> > 2) Too confusing.
> Disagree. Seems perfectly clear to me.

'Seems' is the operative word here <g>. Const has a seductive simplicity that's a mirage. Check out all the weird and wild ways it influences function overloading, argument deduction, partial specialization, and partial ordering.

> > 3) Insufficient utility.
> You couldn't be more wrong

Show me where it's useful. I finally stripped it out of my code, as it never found a bug after 15 years using it thinking it might help find a bug.

> > 4) Optimizers can't reliably use the info anyway.
> Have no knowledge here

I have a lot of practice trying to make use of const info in the optimizer. There isn't any. The optimizer always winds up having to assume that the data pointed to by a pointer to const changes anyway. Then there's 'mutable', const casts, etc. Const doesn't guarantee that the underlying data doesn't change, so it is useless for optimization.

> > 5) Ugly.
> Not meaningful. Most things in SE are ugly until you get used to them
like,
> say, D's templates ... ;)

I see all the 'const' qualifiers over and over as obfuscation. API declarations look a lot cleaner and straightforward without them.

>>>3) Insufficient utility.
>>
>>You couldn't be more wrong
> 
> 
> Show me where it's useful. I finally stripped it out of my code, as it never
> found a bug after 15 years using it thinking it might help find a bug.

Hi, Mathew.

I would be very interested in hearing about the utility of const.  I'm not disputing your assertion, but I haven't had the same experience.

We also dropped the use of const from our coding style at work, and I can't remember spending 1 minute tracking down a bug that const would have prevented.

Perhaps there was a better way, but I feel like we were force to drop the use of 'const' pointers.  The problem is that it was too much for our guys to type on 90% of all object handles passed to functions.  I had a hell of a time enforcing it.  Overall, it seemed to hurt our programmers ability to work together.  Perhaps a 'variable' keyword or some such to declare what parameters get modified would have worked out.

To me, it seems Walter has chosen good middle ground by supporting the use of 'const' only as a storage class modifier.

Bill

Walter has done so by sacrificing the language's ability to pass around constants except by copying them.  Think about big arrays of constants, or constant structures.

To safely pass a constant by reference you have to be able to ensure that nobody will alter the original version.

Once you start passing pointers around to various functions it becomes impossible to statically ascertain whether a given call will violate the constness of the data you are essentially passing in by reference.  Thus to be certain, the compiler is forced to make a copy of all const data before passing it by reference.

One way around this is make the static checking more robust, by say decorating the function signature with information about how the function modifies its reference parameters, and information about all functions this function might call with those parameters so that checking can pursue all possible routes by which the function might alter the parameter.  Only once this has been done can the compiler safely pass in the original const data instead of a copy.

I believe the same problem exists for determining register saving when using so-called fastcall calling conventions.  If you can determine a called function will not clobber a register, you are safe to assume you can leave values there over the call, and much saving and restoring can be prevented or at least delayed to the point where it must be done due to the limited number of registers.

With const, however, a protocol for parameter passing is not so easy.  You surely want to avoid copying data as much as possible, but occasionally it might be worth copying the data if that would be easier than burdening an entire call with restrictions.

I certainly wouldn't want a language to permit anyone to modify data I declare as a constant.  Yet I want to be able to pass those constants to functions by reference without them being copied, so long as the function is safe for passing const data to.  And if I try to pass a constant to a function that will potentially modify the contents, I wish to be warned at compile time instead of having silent copies generated that I can't keep track of.

The compiler is probably much better at keeping tabs on what functions do or do not alter their parameters than I am.  Therefore it should be assigned the task of adorning parameters with constness, as well as making sure const data only gets passed by reference to those sorts of parameters.  An error would mention the const data passed, as well as point out at least one bit of offending code which prevents such a call, directly or indirectly, preferrably with some sort of route taken thru the code by which said problem could happen.  That would be enough info for a programmer that wished the function to actually be const-safe to eradicate the offending writes.

Presto, D language syntax and grammar doesn't change, just the semantics slightly altered with a validity check inserted into the compiler, which it should enforce to the best of its ability.

Problem solved, everybody happy.  ;)  Except poor Walter, who would have to implement it.

Does anyone else think const in C++ is a poor attempt at letting the user decorate info that a sophisticated enough compiler could be able to figure out on its own?  Somewhat akin to the "register" keyword, which "aids" the compiler by disallowing any possibility of aliasing the value stored?  It's also something the compiler can figure out for you, something that modern compilers do.  They even do a pretty good job at it, from what I understand, though C++'s laxity with pointers allows hideous data flow spaghetti that even the best compilers cannot sort out.

Whatever it takes to get the compiler to make good code.  I often must sound like I'm asking for alot.

Another nice thing about keeping track of constness is that a pointer to constant data need never be freed, but that affects D very little since it's built around garbage collection which gives you this anyway, for free.  ;)

Yet another nice thing about passing constants is that it serves as an indicator to the optimizer that it might be able to generate a custom version of the function tailored with the constant completely inlined.  It's something people would want to do (identity matrix, anybody?) and I would expect the compiler to try to take advantage of such a situation.

Sean

"Bill Cox" <bill@viasic.com> wrote in message news:bh85p6$1324$1@digitaldaemon.com...
> >>>3) Insufficient utility.
> >>
> >>You couldn't be more wrong
> >
> >
> > Show me where it's useful. I finally stripped it out of my code, as it
never
> > found a bug after 15 years using it thinking it might help find a bug.
>
> Hi, Mathew.
>
> I would be very interested in hearing about the utility of const.  I'm not disputing your assertion, but I haven't had the same experience.
>
> We also dropped the use of const from our coding style at work, and I can't remember spending 1 minute tracking down a bug that const would have prevented.
>
> Perhaps there was a better way, but I feel like we were force to drop the use of 'const' pointers.  The problem is that it was too much for our guys to type on 90% of all object handles passed to functions.  I had a hell of a time enforcing it.  Overall, it seemed to hurt our programmers ability to work together.  Perhaps a 'variable' keyword or some such to declare what parameters get modified would have worked out.
>
> To me, it seems Walter has chosen good middle ground by supporting the use of 'const' only as a storage class modifier.
>
> Bill