www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Re: preparing for const, final, and invariant

reply bobef <ads aad.asd> writes:
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.

May 19 2007
next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
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

 
 
 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.


May 19 2007
next sibling parent reply bobef <asd asd.com> writes:
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

 
 
 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.



May 19 2007
parent reply Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
bobef wrote:
 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 :)
 

No, I don't think users care if I use const. I do think they care if the program runs quickly and is stable -- both of which const contributes to, by avoiding unnecessary copies of data and pre-empting bugs before they happen. Yes I can use trickery and break the type system to get around it -- but if I'm doing that, there's probably something wrong with the design to begin with. This /is/ aiding library writers, and app writers. Once this is done, hopefully the major issues will be the next to get attention. I really don't think the console is going away anytime soon. A friend recently needed a new log parsing utility. The one we tossed together in an afternoon in D, on the console, finished within minutes -- compared to the old (GUI) app he'd been using that took hours. GUI isn't always a blessing. (All this program even need as input was a filename. Adding GUI to something like that is merely bloat and slowdown.) Usability is important, I agree. But software that's quick and easy to write, is also quicker and easier to /make/ usable. And GUI isn't always the answer to usability. That's my stance in a tiny overly restrictive nutshell. (Walnut? Maybe pecan...) -- Chris Nicholson-Sauls
May 19 2007
parent antonio <antonio abrevia.net> writes:
Chris Nicholson-Sauls wrote:
 bobef wrote:
 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 :)

No, I don't think users care if I use const. I do think they care if the program runs quickly and is stable -- both of which const contributes to, by avoiding unnecessary copies of data and pre-empting bugs before they happen. Yes I can use trickery and break the type system to get around it -- but if I'm doing that, there's probably something wrong with the design to begin with. This /is/ aiding library writers, and app writers. Once this is done, hopefully the major issues will be the next to get attention. I really don't think the console is going away anytime soon. A friend recently needed a new log parsing utility. The one we tossed together in an afternoon in D, on the console, finished within minutes -- compared to the old (GUI) app he'd been using that took hours. GUI isn't always a blessing. (All this program even need as input was a filename. Adding GUI to something like that is merely bloat and slowdown.) Usability is important, I agree. But software that's quick and easy to write, is also quicker and easier to /make/ usable. And GUI isn't always the answer to usability. That's my stance in a tiny overly restrictive nutshell. (Walnut? Maybe pecan...) -- Chris Nicholson-Sauls

May be, Walter could be centered solving bugs and closely working with debugger developpements (ddbg?). anyway, "in" is a good hight level pogramming feature for people that uses D as hight level language (is expressive of an intention)
May 22 2007
prev sibling parent "Anders Bergh" <anders andersman.org> writes:
On 5/19/07, bobef <asd asd.com> wrote:
 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 :)

I think users want their applications to be safe and stable, and consts help with that. Of course, const is not a magical way to make code safer... but it helps. -- Anders
May 19 2007
prev sibling next sibling parent reply Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
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

 

Well here's something: I don't /want/ Walter working on a GUI lib. That's already being taken care of, with DFL, Tioport/SWT, Harmonia, and gtkD. (Probably a few others.) Choice is good, and there it is. What I /do/ want is Walter working on the things that we've all been asking for all this long while -- and that seems to be precisely what he's doing. Some of us do still write console applications, and daemons with no direct user input at all. (I look at the loooong list of software on our Linux boxes and remark that out of all of these, precious few have any GUI at all. Mainly, Kate and KDE.) If D were to go in a direction that only focused on application development, and only on graphical apps... I'd probably have a good cry, give a salute, and just start using Ruby for everything. Meanwhile, ask me sometime about the dozens of bits of at least one of my projects the new const'ness concepts will allow me to actually /write/ in a sane way in the first place. The project is on hold, has been for quite some while, all just waiting for something like this. -- Chris Nicholson-Sauls PS - Forward reference is using a symbol before it is defined. Most cases of forward reference in D are accounted for and resolved by the compiler, but there are a handful that it still can't handle. Pray some day it can handle them all -- here's hoping.
May 19 2007
next sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Chris Nicholson-Sauls" <ibisbasenji gmail.com> wrote in message 
news:f2mu3j$cek$1 digitalmars.com...
 PS - Forward reference is using a symbol before it is defined.  Most cases 
 of forward reference in D are accounted for and resolved by the compiler, 
 but there are a handful that it still can't handle.  Pray some day it can 
 handle them all -- here's hoping.

We shouldn't _have_ to hope. This is something that should have been fixed ages ago.
May 19 2007
prev sibling parent reply bobef <asd asd.com> writes:
I am not asking Walter to Write GUI libraries, but to fix what is preventing
other people from doing so.

And of course there are many console applications and daemons, but let get down
on earth. In many cases GUI applications are easier to use than console ones.
So many Linux console apps are getting GUI front ends. Although many geeks
won't believe it times are changing and the console interface has no future.


Chris Nicholson-Sauls Wrote:

 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

 

Well here's something: I don't /want/ Walter working on a GUI lib. That's already being taken care of, with DFL, Tioport/SWT, Harmonia, and gtkD. (Probably a few others.) Choice is good, and there it is. What I /do/ want is Walter working on the things that we've all been asking for all this long while -- and that seems to be precisely what he's doing. Some of us do still write console applications, and daemons with no direct user input at all. (I look at the loooong list of software on our Linux boxes and remark that out of all of these, precious few have any GUI at all. Mainly, Kate and KDE.) If D were to go in a direction that only focused on application development, and only on graphical apps... I'd probably have a good cry, give a salute, and just start using Ruby for everything. Meanwhile, ask me sometime about the dozens of bits of at least one of my projects the new const'ness concepts will allow me to actually /write/ in a sane way in the first place. The project is on hold, has been for quite some while, all just waiting for something like this. -- Chris Nicholson-Sauls PS - Forward reference is using a symbol before it is defined. Most cases of forward reference in D are accounted for and resolved by the compiler, but there are a handful that it still can't handle. Pray some day it can handle them all -- here's hoping.

May 19 2007
parent reply Georg Wrede <georg nospam.org> writes:
bobef wrote:
 Although many geeks won't believe it times are changing
 and the console interface has no future.

Hmm. That's as smart as saying that typewriters will obsolete the pen. They are both needed. Neither will completely replace the other.
May 19 2007
parent reply bobef <asd asd.com> writes:
I use pen twice a year. People have all this pocket PCs with digital pens and
stuff. Voice recognition is evolving too. Who knows in few years someone may
come up with a mind reading machine... I know it is hard to change one's habits
but loot at things from another view point. Even if you and me don't want to
give up the console (yes, I am still using it too), we are aging and the newer
people don't have such habits like consoles and pens... So these tools are
indeed fading away... Nothing is permanent, you know...

Georg Wrede Wrote:

 bobef wrote:
 Although many geeks won't believe it times are changing
 and the console interface has no future.

Hmm. That's as smart as saying that typewriters will obsolete the pen. They are both needed. Neither will completely replace the other.

May 19 2007
parent reply "Aziz K." <aziz.kerim gmail.com> writes:
On Sun, 20 May 2007 00:21:40 +0200, bobef <asd asd.com> wrote:
 bobef wrote:
 Although many geeks won't believe it times are changing
 and the console interface has no future.

Hmm. That's as smart as saying that typewriters will obsolete the pen. They are both needed. Neither will completely replace the other.


Even if every PC had voice recognition, I don't think it would be perfect, because even humans often misunderstand what another fellow meant to say. Language is pretty complex, and there can be a lot of ambiguity even in simple sentences. I wouldn't feel very comfortable about telling my PC to delete a certain folder, while it could very well destroy the wrong one. Maybe the computer could ask you to confirm the command every time before it is executed, or even allow you to edit the command in a pop-up text box before execution. I'm not sure though where the added benefit of a CPU-intensive voice-recognition program is, whilst it should be more effective to directly type the command that is on your mind in the console. So I don't think that the console is unnecessary or that it will be replaced by anything else anytime soon. It would be better to enhance it rather than get rid of it. To my mind the console is absolutely indispensible for certain tasks, and it is often much easier to type in a series of commands than to accomplish the same with a GUI driven program. I don't think the console and the GUI are in conflict, but they very much complement each other. When I switched to Linux I really began to appreciate how powerful a console can be, that's why I have to cringe every time I have to use the Windows abomination of a console :-)
May 20 2007
parent reply Don Clugston <dac nospam.com.au> writes:
Aziz K. wrote:
 On Sun, 20 May 2007 00:21:40 +0200, bobef <asd asd.com> wrote:
 bobef wrote:
 Although many geeks won't believe it times are changing
 and the console interface has no future.

Hmm. That's as smart as saying that typewriters will obsolete the pen. They are both needed. Neither will completely replace the other.


Even if every PC had voice recognition, I don't think it would be perfect, because even humans often misunderstand what another fellow meant to say. Language is pretty complex, and there can be a lot of ambiguity even in simple sentences. I wouldn't feel very comfortable about telling my PC to delete a certain folder, while it could very well destroy the wrong one. Maybe the computer could ask you to confirm the command every time before it is executed, or even allow you to edit the command in a pop-up text box before execution. I'm not sure though where the added benefit of a CPU-intensive voice-recognition program is, whilst it should be more effective to directly type the command that is on your mind in the console. So I don't think that the console is unnecessary or that it will be replaced by anything else anytime soon. It would be better to enhance it rather than get rid of it. To my mind the console is absolutely indispensible for certain tasks, and it is often much easier to type in a series of commands than to accomplish the same with a GUI driven program. I don't think the console and the GUI are in conflict, but they very much complement each other. When I switched to Linux I really began to appreciate how powerful a console can be, that's why I have to cringe every time I have to use the Windows abomination of a console :-)

Agreed. My experience of D has really reinforced to me that GUIs are evil for development. When developing logic or algorithms, it's a hundred times easier doing it with a console app. Run your GUI for testing and developing your GUI, and for *nothing else*.
May 20 2007
parent Sean Kelly <sean f4.ca> writes:
Don Clugston wrote:
 
 Agreed. My experience of D has really reinforced to me that GUIs are 
 evil for development. When developing logic or algorithms, it's a 
 hundred times easier doing it with a console app. Run your GUI for 
 testing and developing your GUI, and for *nothing else*.

Many of the C/C++ examples in MSDN are terrible for exactly this reason. There are perhaps 5-10 lines of useful information buried in pages of useless stuff. What I tend to do is develop algorithms and such separately in a console app and only move it into the real app once I've got it working properly. Sean
May 20 2007
prev sibling next sibling parent Ary Manzana <ary esperanto.org.ar> writes:
I agree with you (althought I don't like your tone, but it's 
understandable).

I think D has in mind this sentence: "D is a language you should feel 
very comfortable in when writing applications, and that lets the user 
focus on his problem instead of fighting with the compiler". (I think I 
can recall a sentence like this one in a video about D given by Walter).

Well... with the problem of forward references this is not true. You 
focus on your problem until the compiler can't compile your code because 
you are using forward referneces. Then you have to fight with the 
compiler, try to hack it and trick it, to get your way. The const, 
final, scope keywords surely will help making code safer, but their lack 
doesn't prevent users from compiling their programs.

bobef escribió:
 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

 
 
 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.


May 19 2007
prev sibling parent reply BLS <nanali yyy.fr> writes:
I agree. 
(and I am afraid that reflection will take along long time)
Bjoern

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

May 19 2007
parent reply Brad Roberts <braddr puremagic.com> writes:
Not that this debate has any value, since const, et al are currently 
being implemented and that's not remotely likely to change, but here's 
my opinion, for what it's worth:

For any non-trivial application, const (and it's stronger brother 
invariant) is a must to allow me and the people I work with to both 
specify the behavior of routines in their signature, and to actually 
provide enforcement.  I can't consider a language without the ability to 
make these sorts of guarantees without stupid work around like copying 
data left and right a usable language.  It's an interesting toy, but it 
can't graduate to anything besides toy apps.  I recognize that non-toy 
apps have been written with D, and that's great.  So, for me, const is 
an 'every app' layer feature, or at least any library / application of 
significant size.  There's no way in hell that 'const' can be called a 
nerd feature.

Reflection, while a very very powerful feature, is something that's 
useful in a subset of applications.  Additionally, it's not like 
reflection has been totally ignored.  The features of it have _also_ 
been increasing over time.  D might not match Java yet, but few features 
of this weight are black and white.  Between CTFE, Mixins, and the 
compile time reflection that's already available, I suspect it's 
possible to write a reflection library that covers a high percentage of 
java's functionality.  I highly encourage anyone who is in serious need 
of runtime reflection take a stab at it and report back a prioritized 
list of what's missing.

Later,
Brad

BLS wrote:
 I agree. (and I am afraid that reflection will take along long time) 
 Bjoern
 
 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 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....
 


May 19 2007
parent Walter Bright <newshound1 digitalmars.com> writes:
Brad Roberts wrote:
 For any non-trivial application, const (and it's stronger brother 
 invariant) is a must to allow me and the people I work with to both 
 specify the behavior of routines in their signature, and to actually 
 provide enforcement.

The combination of const, invariant, final, and scope will allow one to be much more expressive on the intended usage of a variable than C++ does, along with enforcement of it. One downside is there's no dipping one's toe into const-correctness. It's got to be done whole hog.
May 19 2007