preparing for const, final, and invariant

[bobef]

Do you think that any user cares about if you use consts in your code or not? This is what I mean when I talk about usability. We write applications not code. We should focus on the usability. If it is easier to write - good, but the application is what is important, no the code (yes, of course it matters too). Plus what consts are you talking about in C++? Just cast them to void* and back to the type without const... If you want to modify it nothing is stopping you, if not just don't do it :)


Bill Baxter Wrote:

> To me const is not "fancy stuff".  It's a big hole that's long needed 
> some implementation in D.  Right now we have two choices for passing big 
> objects/structs to functions - pass it by value (SLOOW but SAFE) or pass 
> it by reference (FAST but UNSAFE).  Neither is particularly attractive. 
>   Const will make it possible to write functions that are both FAST and 
> SAFE.  Coming from C++, the lack of const in D seems like a joke. 
> Painful though it may be, it's great that Walter is doing something 
> about it.
> 
> --bb
> 
> bobef wrote:
> > Without any disrespect to the great work you are doing, let me put it in another way: In order to make a good, *usable* application, is this "const final scope" thing more important or having a good GUI library? There are not many console applications these days, you know. And they are not very *usable*. And, as we all know, choosing a GUI for D is not like choosing a GUI for C++. So why instead of adding nerd stuff to the language, make it sooooo much more *usable*, by fixing the reflection stuff that Tioport needs to produce libraries which are not 10mb or 20mb? Or... it kind of sucks when half of my code won't compile, or compiles in specific order only, because of some forward reference errors. I don't even know what forward reference is, but I know that using (simple) consts and aliases is something perfectly legal. I don't know if this second example is more usable than the final cosnt thing, just because I can't think of any use of it, but this is because I rarely u
> se fancy stuff that breaks my code in the next version of DMD... But I am making this example to show that D (or DMD) still have so many things to fix the way it is now, we don't need some new fancy stuff before the old things work....
> > 
> > 
> > Walter Bright Wrote:
> > 
> >> This is coming for the D 2.0 beta, and it will need some source code 
> >> changes. Specifically, for function parameters that are arrays or 
> >> pointers, start using 'in' for them.
> >>
> >> 'in' will mean 'scope const final', which means:
> >>
> >> final - the parameter will not be reassigned within the function
> >> const - the function will not attempt to change the contents of what is 
> >> referred to
> >> scope - the function will not keep a reference to the parameter's data 
> >> that will persist beyond the scope of the function
> >>
> >> For example:
> >>
> >> int[] g;
> >>
> >> void foo(in int[] a)
> >> {
> >>      a = [1,2];	// error, a is final
> >>      a[1] = 2;   // error, a is const
> >>      g = a;	// error, a is scope
> >> }
> >>
> >> Do not use 'in' if you wish to do any of these operations on a 
> >> parameter. Using 'in' has no useful effect on D 1.0 code, so it'll be 
> >> backwards compatible.
> >>
> >> Adding in all those 'in's is tedious, as I'm finding out :-(, but I 
> >> think the results will be worth the effort.
> > 
>