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.

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

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

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.

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

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

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

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

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

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

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