preparing for const, final, and invariant

[bobef]

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 use 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.