www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Do we need a time-out in D evolution?

reply eao197 <eao197 intervale.ru> writes:
I'm watching for discussions 'Stepping back and looking at constness from  
another angle' here and 'resizeable arrays: T[new]' & 'preparing for  
const, final, and invariant' in digitalmars.D.announce and I'm sad. I  
occasionally locked to D may be from 2003 -- it was a constantly changing  
language. At the end of 2006 I thought that D is stable enough to start to  
use it. And in Jan 2007 the v.1.000 went out. I thought that in near time  
D would have only bug fix releases and it is a time when various tools for  
D (like libraries and IDEs) would be produced.

But I was wrong.

What we have now? The language which keeps their evolution. Lack of  
libraries, lack of tools, lack of documentation (books and tutorials). As  
a consequence -- lack of users. And we don't get much new users and new  
applications without new libraries/tools/documentation.

As a programmer I need a stable language. A language in which I can write  
a domain-specific library and forget about its maintenace for three of  
five years (as for some of my C++ libraries those I wrote in 2002-2003). I  
need to write applications and because of that I need a quality and stable  
compiler, a quality and stable standard library, and quality third party  
libraries. And third party libraries' writters need a stable tools too.

But now, when I'm writting some D code, I know that in near feature the  
next D version will be here. And that version broke my code because of  
consts and new syntax of resizeable arrays. So why to start a new big  
project on D if its codebase will be obsolete in few months?

And I'm affraid that after adding consts/final/invariant support to D the  
language keeps their envolution :(

Yes consts/final/invariant is a great addition to the language. But D now  
is very powerful language. It is now more powerful than C++0x will be. So  
may be it is better to stop add new features and make a stable platform  
for library/tools writters at first and then for applications writters?  
AFAIK, every successful languages were going such way -- the good initial  
release and some new releases later with years of stability beetwen them.  
And I'm affraid that C++0x will be here before D would get a stable  
language with enough libraries and tools.

May be it is better to concentrate on improvement of the current  
implementation (fast precise GC instead of the current conservative GC,  
for example) instead of introducing incompatible changes in the language?

And my main question is: will be D a constanly changing language or will  
be there some time-outs in its evolution?

-- 
Regards,
Yauheni Akhotnikau
Jun 05 2007
next sibling parent reply Clay Smith <clayasaurus gmail.com> writes:
eao197 Wrote:

 I'm watching for discussions 'Stepping back and looking at constness from  
 another angle' here and 'resizeable arrays: T[new]' & 'preparing for  
 const, final, and invariant' in digitalmars.D.announce and I'm sad. I  
 occasionally locked to D may be from 2003 -- it was a constantly changing  
 language. At the end of 2006 I thought that D is stable enough to start to  
 use it. And in Jan 2007 the v.1.000 went out. I thought that in near time  
 D would have only bug fix releases and it is a time when various tools for  
 D (like libraries and IDEs) would be produced.
 
 But I was wrong.
 
 What we have now? The language which keeps their evolution. Lack of  
 libraries, lack of tools, lack of documentation (books and tutorials). As  
 a consequence -- lack of users. And we don't get much new users and new  
 applications without new libraries/tools/documentation.
 
 As a programmer I need a stable language. A language in which I can write  
 a domain-specific library and forget about its maintenace for three of  
 five years (as for some of my C++ libraries those I wrote in 2002-2003). I  
 need to write applications and because of that I need a quality and stable  
 compiler, a quality and stable standard library, and quality third party  
 libraries. And third party libraries' writters need a stable tools too.
 
 But now, when I'm writting some D code, I know that in near feature the  
 next D version will be here. And that version broke my code because of  
 consts and new syntax of resizeable arrays. So why to start a new big  
 project on D if its codebase will be obsolete in few months?
 
 And I'm affraid that after adding consts/final/invariant support to D the  
 language keeps their envolution :(
 
 Yes consts/final/invariant is a great addition to the language. But D now  
 is very powerful language. It is now more powerful than C++0x will be. So  
 may be it is better to stop add new features and make a stable platform  
 for library/tools writters at first and then for applications writters?  
 AFAIK, every successful languages were going such way -- the good initial  
 release and some new releases later with years of stability beetwen them.  
 And I'm affraid that C++0x will be here before D would get a stable  
 language with enough libraries and tools.
 
 May be it is better to concentrate on improvement of the current  
 implementation (fast precise GC instead of the current conservative GC,  
 for example) instead of introducing incompatible changes in the language?
 
 And my main question is: will be D a constanly changing language or will  
 be there some time-outs in its evolution?
 
 -- 
 Regards,
 Yauheni Akhotnikau

D 1.0 is locked, the features you are talking about are D 2.0 features.
Jun 05 2007
parent reply BCS <ao pathlink.com> writes:
Reply to Clay,

 eao197 Wrote:
 
 I'm watching for discussions 'Stepping back and looking at constness
 from  another angle' here and 'resizeable arrays: T[new]' &
 'preparing for  const, final, and invariant' in
 digitalmars.D.announce and I'm sad. I  occasionally locked to D may
 be from 2003 -- it was a constantly changing  language. At the end of
 2006 I thought that D is stable enough to start to  use it. And in
 Jan 2007 the v.1.000 went out. I thought that in near time  D would
 have only bug fix releases and it is a time when various tools for  D
 (like libraries and IDEs) would be produced.
 
 But I was wrong.
 
 What we have now? The language which keeps their evolution. Lack of
 libraries, lack of tools, lack of documentation (books and
 tutorials). As  a consequence -- lack of users. And we don't get much
 new users and new  applications without new
 libraries/tools/documentation.
 
 As a programmer I need a stable language. A language in which I can
 write  a domain-specific library and forget about its maintenace for
 three of  five years (as for some of my C++ libraries those I wrote
 in 2002-2003). I  need to write applications and because of that I
 need a quality and stable  compiler, a quality and stable standard
 library, and quality third party  libraries. And third party
 libraries' writters need a stable tools too.
 
 But now, when I'm writting some D code, I know that in near feature
 the  next D version will be here. And that version broke my code
 because of  consts and new syntax of resizeable arrays. So why to
 start a new big  project on D if its codebase will be obsolete in few
 months?
 
 And I'm affraid that after adding consts/final/invariant support to D
 the  language keeps their envolution :(
 
 Yes consts/final/invariant is a great addition to the language. But D
 now  is very powerful language. It is now more powerful than C++0x
 will be. So  may be it is better to stop add new features and make a
 stable platform  for library/tools writters at first and then for
 applications writters?  AFAIK, every successful languages were going
 such way -- the good initial  release and some new releases later
 with years of stability beetwen them.  And I'm affraid that C++0x
 will be here before D would get a stable  language with enough
 libraries and tools.
 
 May be it is better to concentrate on improvement of the current
 implementation (fast precise GC instead of the current conservative
 GC,  for example) instead of introducing incompatible changes in the
 language?
 
 And my main question is: will be D a constanly changing language or
 will  be there some time-outs in its evolution?
 
 --
 Regards,
 Yauheni Akhotnikau

features.

we're all so used to using beta around here that that has almost no meaning
Jun 05 2007
next sibling parent Lutger <lutger.blijdestijn gmail.com> writes:
BCS wrote:
 Reply to Clay,
 D 1.0 is locked, the features you are talking about are D 2.0
 features.

we're all so used to using beta around here that that has almost no meaning

Well yes but should it not have meaning? D certainly has to come to a point somewhere in time where a stable release is made, and that has to be something more than what happened with version 1.0. Where that point in time is only Walter can tell, but it's clear some people feel stability is needed for further adoption and tackling large projects. Perhaps it is time to revisit what 'version 1.0' is about for the coming split in maintenance and 2.0 branches, call it 1.5? It seems a good place in time. On the other hand, if pervasive changes are made indeed then it may not be such a good idea after all.
Jun 05 2007
prev sibling parent Charlie <charlie.fats gmail.com> writes:
BCS wrote:
 Reply to Clay,
 
 eao197 Wrote:

 I'm watching for discussions 'Stepping back and looking at constness
 from  another angle' here and 'resizeable arrays: T[new]' &
 'preparing for  const, final, and invariant' in
 digitalmars.D.announce and I'm sad. I  occasionally locked to D may
 be from 2003 -- it was a constantly changing  language. At the end of
 2006 I thought that D is stable enough to start to  use it. And in
 Jan 2007 the v.1.000 went out. I thought that in near time  D would
 have only bug fix releases and it is a time when various tools for  D
 (like libraries and IDEs) would be produced.

 But I was wrong.

 What we have now? The language which keeps their evolution. Lack of
 libraries, lack of tools, lack of documentation (books and
 tutorials). As  a consequence -- lack of users. And we don't get much
 new users and new  applications without new
 libraries/tools/documentation.

 As a programmer I need a stable language. A language in which I can
 write  a domain-specific library and forget about its maintenace for
 three of  five years (as for some of my C++ libraries those I wrote
 in 2002-2003). I  need to write applications and because of that I
 need a quality and stable  compiler, a quality and stable standard
 library, and quality third party  libraries. And third party
 libraries' writters need a stable tools too.

 But now, when I'm writting some D code, I know that in near feature
 the  next D version will be here. And that version broke my code
 because of  consts and new syntax of resizeable arrays. So why to
 start a new big  project on D if its codebase will be obsolete in few
 months?

 And I'm affraid that after adding consts/final/invariant support to D
 the  language keeps their envolution :(

 Yes consts/final/invariant is a great addition to the language. But D
 now  is very powerful language. It is now more powerful than C++0x
 will be. So  may be it is better to stop add new features and make a
 stable platform  for library/tools writters at first and then for
 applications writters?  AFAIK, every successful languages were going
 such way -- the good initial  release and some new releases later
 with years of stability beetwen them.  And I'm affraid that C++0x
 will be here before D would get a stable  language with enough
 libraries and tools.

 May be it is better to concentrate on improvement of the current
 implementation (fast precise GC instead of the current conservative
 GC,  for example) instead of introducing incompatible changes in the
 language?

 And my main question is: will be D a constanly changing language or
 will  be there some time-outs in its evolution?

 -- 
 Regards,
 Yauheni Akhotnikau

features.

we're all so used to using beta around here that that has almost no

Agreed, and AFAIK , bug fixes aren't being applied to 1.0 , and they we're some apparently large bugs
 And my main question is: will be D a constanly changing language or
 will  be there some time-outs in its evolution?



I've also been tracking since 2003, its now 1/2 way though 2007, and I don't think D is anywhere near slowing down, if anything it seems to be gaining momentum. But I have resigned to using it in commercial stuff, when D has finally ( I'm genuinely guessing 3 - 4 years ) slowed to a stop, its going to be an amazing language. And I don't really want it to stop improving, I did at one point, but I think some of the new stuff is really going to drive some innovation in the programming world.
Jun 05 2007
prev sibling next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
eao197 wrote:
 I'm watching for discussions 'Stepping back and looking at constness 
 from another angle' here and 'resizeable arrays: T[new]' & 'preparing 
 for const, final, and invariant' in digitalmars.D.announce and I'm sad. 
 I occasionally locked to D may be from 2003 -- it was a constantly 
 changing language. At the end of 2006 I thought that D is stable enough 
 to start to use it. And in Jan 2007 the v.1.000 went out. I thought that 
 in near time D would have only bug fix releases and it is a time when 
 various tools for D (like libraries and IDEs) would be produced.
 
 But I was wrong.
 
 What we have now? The language which keeps their evolution. Lack of 
 libraries, lack of tools, lack of documentation (books and tutorials). 
 As a consequence -- lack of users. And we don't get much new users and 
 new applications without new libraries/tools/documentation.
 
 As a programmer I need a stable language. A language in which I can 
 write a domain-specific library and forget about its maintenace for 
 three of five years (as for some of my C++ libraries those I wrote in 
 2002-2003). I need to write applications and because of that I need a 
 quality and stable compiler, a quality and stable standard library, and 
 quality third party libraries. And third party libraries' writters need 
 a stable tools too.

Of all the features under consideration for D, const is the one most likely to have sweeping repercussions throughout the language. So if D is ever to get a serious const, it better happen sooner rather than later, precisely so it can settle down and become stable. The longer Walter waits, the more libraries and code that will be affected and need to change. There are *no* other proposals on the table that I know of that will be require such major changes to the language. None. Const is the big daddy. Reflection things may be big in terms of implementation work, but impact on backwards compatability should be pretty much nil. So far Walter has spent, what, about a month focused on const? If it works out then great. The issue will be settled, and no longer be a cloud looming on the horizon. If it doesn't, well then too the issue will be settled, and no longer be a cloud looming on the horizon. Either way, the big daddy change will be behind us. --bb
Jun 05 2007
parent reply eao197 <eao197 intervale.ru> writes:
On Wed, 06 Jun 2007 02:04:05 +0400, Bill Baxter  
<dnewsgroup billbaxter.com> wrote:

 Of all the features under consideration for D, const is the one most  
 likely to have sweeping repercussions throughout the language.  So if D  
 is ever to get a serious const, it better happen sooner rather than  
 later, precisely so it can settle down and become stable.  The longer  
 Walter waits, the more libraries and code that will be affected and need  
 to change.  There are *no* other proposals on the table that I know 	of  
 that will be require such major changes to the language.  None.  Const  
 is the big daddy.  Reflection things may be big in terms of  
 implementation work, but impact on backwards compatability should be  
 pretty much nil.

 So far Walter has spent, what, about a month focused on const?  If it  
 works out then great.  The issue will be settled, and no longer be a  
 cloud looming on the horizon.  If it doesn't, well then too the issue  
 will be settled, and no longer be a cloud looming on the horizon. Either  
 way, the big daddy change will be behind us.

My question was inspiried by const/final/invariant discussion. But my question is not about necessarity of adding const/final/invariant. So let take me some explanation. At first, I'm C++ programmer and I like 'const' in C++. Sometimes it really helps to avoid bug (last case was a few days ago). Because of that I want to see consts in D (but current situation with const/final/invariant looks too complicated for me). But the question isn't in const or AST macros or something else. The question is in incompatible changes to language after the short time since v.1.000. It is not good I think. I think it always be something cool and desirable for including in language. Even if we don't know now what it will be. For example: why thought about const/final/invariant at Jan 2007 when v.1.000 was released? Because of that must be some moment when Walter say: "We stop adding new features. Now we take two or three years of language stability and see what happens here". I thought v.1.014 is a good moment for that. But now we are talking about consts... So my question is: "Is there a planed time-out in D evolution?" -- Regards, Yauheni Akhotnikau
Jun 06 2007
next sibling parent reply Johan Granberg <lijat.meREM OVEgmail.com> writes:
eao197 wrote:

 On Wed, 06 Jun 2007 02:04:05 +0400, Bill Baxter
 <dnewsgroup billbaxter.com> wrote:
 
 Of all the features under consideration for D, const is the one most
 likely to have sweeping repercussions throughout the language.  So if D
 is ever to get a serious const, it better happen sooner rather than
 later, precisely so it can settle down and become stable.  The longer
 Walter waits, the more libraries and code that will be affected and need
 to change.  There are *no* other proposals on the table that I know  of
 that will be require such major changes to the language.  None.  Const
 is the big daddy.  Reflection things may be big in terms of
 implementation work, but impact on backwards compatability should be
 pretty much nil.

 So far Walter has spent, what, about a month focused on const?  If it
 works out then great.  The issue will be settled, and no longer be a
 cloud looming on the horizon.  If it doesn't, well then too the issue
 will be settled, and no longer be a cloud looming on the horizon. Either
 way, the big daddy change will be behind us.

My question was inspiried by const/final/invariant discussion. But my question is not about necessarity of adding const/final/invariant. So let take me some explanation. At first, I'm C++ programmer and I like 'const' in C++. Sometimes it really helps to avoid bug (last case was a few days ago). Because of that I want to see consts in D (but current situation with const/final/invariant looks too complicated for me). But the question isn't in const or AST macros or something else. The question is in incompatible changes to language after the short time since v.1.000. It is not good I think. I think it always be something cool and desirable for including in language. Even if we don't know now what it will be. For example: why thought about const/final/invariant at Jan 2007 when v.1.000 was released? Because of that must be some moment when Walter say: "We stop adding new features. Now we take two or three years of language stability and see what happens here". I thought v.1.014 is a good moment for that. But now we are talking about consts... So my question is: "Is there a planed time-out in D evolution?"

Didn't Walter say that he would branch the compiler into a current stable (what we have now) and an experimental 2.0 compiler. If that is done isn't that a clear signal to everyone that the 1.014 (or whatewer the version is at the moment) compiler is the one to use for production code?
Jun 06 2007
next sibling parent reply eao197 <eao197 intervale.ru> writes:
On Wed, 06 Jun 2007 13:26:40 +0400, Johan Granberg  
<lijat.meREM OVEgmail.com> wrote:

 So my question is: "Is there a planed time-out in D evolution?"

Didn't Walter say that he would branch the compiler into a current stable (what we have now) and an experimental 2.0 compiler. If that is done isn't that a clear signal to everyone that the 1.014 (or whatewer the version is at the moment) compiler is the one to use for production code?

Here is my vision: * I start to use D1.0 for production. In near few months Tango 1.0 will be released and everything is fine. * I spend 4-5 months to port some of my tools to D and then 4-5 months produce and deploy some part of our system in D. * At this time (early 2008) there is the working version of D2.0. So after I produce some production code what will be with Tango, for example? Would its athors want to support and improve Tango for D1.0 and Tango for D2.0 at the same time? What should I do with my D1.0 code when D2.0 will be there? I think it is better to port my code to D2.0. But this means than I need yet month or more for rewritting and retesting, but not producing new code. It's not a big problem I know that there won't be another incompatible version D3.0 after a half-year after D2.0. But I don't know that now, because the history shows that D constantly changed. -- Regards, Yauheni Akhotnikau
Jun 06 2007
parent Lars Ivar Igesund <larsivar igesund.net> writes:
eao197 wrote:

 Here is my vision:
 
 * I start to use D1.0 for production. In near few months Tango 1.0 will be
 released and everything is fine.
 
 * I spend 4-5 months to port some of my tools to D and then 4-5 months
 produce and deploy some part of our system in D.
 
 * At this time (early 2008) there is the working version of D2.0.
 
 So after I produce some production code what will be with Tango, for
 example? Would its athors want to support and improve Tango for D1.0 and
 Tango for D2.0 at the same time? What should I do with my D1.0 code when
 D2.0 will be there? I think it is better to port my code to D2.0. But this
 means than I need yet month or more for rewritting and retesting, but not
 producing new code.

D 2.0 features will be applied to Tango where they can strengthen already existing contracts between user-code and the library. Examples of this may be subtle usage of const. We would expect such language related changes to avoid breaking existing user source code. -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Jun 06 2007
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Johan Granberg wrote:
 Didn't Walter say that he would branch the compiler into a current stable
 (what we have now) and an experimental 2.0  compiler. If that is done isn't
 that a clear signal to everyone that the 1.014 (or whatewer the version is
 at the moment) compiler is the one to use for production code?

It's getting pretty clear to me that the 1.0 series won't get any new features, just bug fixes, as the recent 1.015 release suggests. The new features will all go into the 2.0 series.
Jun 07 2007
next sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Walter Bright wrote:
 It's getting pretty clear to me that the 1.0 series won't get any new
 features, just bug fixes, as the recent 1.015 release suggests.
 
 The new features will all go into the 2.0 series.

Glad to hear it, in that the D 1.0 compilers will now be getting more stable. Not glad to hear it, in that it means more work for you. This brings up an interesting question: will D 2.0 have a -v1 switch? :P Again, thanks for all the hard work you're putting in for us. -- Daniel
Jun 07 2007
parent Walter Bright <newshound1 digitalmars.com> writes:
Daniel Keep wrote:
 This brings up an interesting question: will D 2.0 have a -v1 switch? :P

No, I don't see that much point to it that justifies the complexity.
 Again, thanks for all the hard work you're putting in for us.

You're welcome!
Jun 07 2007
prev sibling next sibling parent reply BCS <ao pathlink.com> writes:
Reply to Walter,

 Johan Granberg wrote:
 
 Didn't Walter say that he would branch the compiler into a current
 stable (what we have now) and an experimental 2.0  compiler. If that
 is done isn't that a clear signal to everyone that the 1.014 (or
 whatewer the version is at the moment) compiler is the one to use for
 production code?
 

features, just bug fixes, as the recent 1.015 release suggests. The new features will all go into the 2.0 series.

will the 2.0 series have an extern(D1) if and when somthing breaks linking?
Jun 07 2007
parent reply Walter Bright <newshound1 digitalmars.com> writes:
BCS wrote:
 will the 2.0 series have an extern(D1) if and when somthing breaks linking?

No.
Jun 07 2007
parent reply BCS <ao pathlink.com> writes:
Reply to Walter,

 BCS wrote:
 
 will the 2.0 series have an extern(D1) if and when somthing breaks
 linking?
 


Bummer
Jun 08 2007
parent reply Walter Bright <newshound1 digitalmars.com> writes:
BCS wrote:
 Reply to Walter,
 
 BCS wrote:

 will the 2.0 series have an extern(D1) if and when somthing breaks
 linking?


Bummer

It's not that it's a bad idea, it's just that it would be problematic to implement. What if the behavior of parts of Phobos changes, and one part of the code depends on 1 library behavior, and another part depends on 2? What if trying to accommodate both simultaneously is not practical? How to test all those combinations?
Jun 08 2007
parent reply BCS <ao pathlink.com> writes:
Reply to Walter,

 BCS wrote:
 
 Reply to Walter,
 
 BCS wrote:
 
 will the 2.0 series have an extern(D1) if and when somthing breaks
 linking?
 



to implement. What if the behavior of parts of Phobos changes, and one part of the code depends on 1 library behavior, and another part depends on 2? What if trying to accommodate both simultaneously is not practical? How to test all those combinations?

Well in that case I hope we'll get it when D2.0 comes out of beta. (or maybe alpha) Aside: This sort of plays into a thought I had as to how D might be able to avoid the mess that C++ seems to have gotten into. How about if each major version of D is not required to be backwards comparable with the last version. Where possible the extern(D<ver>) will be provided for backwards (and maybe forwards) compatibility. However If code can't be mapped automatically, then it isn't directly callable and that is assumed to be the cost of keeping a clean language.
Jun 08 2007
next sibling parent reply Thomas Kuehne <thomas-dloop kuehne.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

BCS schrieb am 2007-06-09:
 Reply to Walter,

 BCS wrote:
 
 Reply to Walter,
 
 BCS wrote:
 
 will the 2.0 series have an extern(D1) if and when somthing breaks
 linking?
 



to implement. What if the behavior of parts of Phobos changes, and one part of the code depends on 1 library behavior, and another part depends on 2? What if trying to accommodate both simultaneously is not practical? How to test all those combinations?

Well in that case I hope we'll get it when D2.0 comes out of beta. (or maybe alpha) Aside: This sort of plays into a thought I had as to how D might be able to avoid the mess that C++ seems to have gotten into. How about if each major version of D is not required to be backwards comparable with the last version. Where possible the extern(D<ver>) will be provided for backwards (and maybe forwards) compatibility. However If code can't be mapped automatically, then it isn't directly callable and that is assumed to be the cost of keeping a clean language.

For some modules like std.math supporting Dv1 and Dv2 at the same time is most likely not difficult, however for the "rest" ... My experience with Flectioned is that supporting multiple runtime libraries(GPhobos, Phobos, Tango) in D - or in the above case versions - can be a real pain. Supporting a Dv1-Dv2-mix in one binary might be possible (depends on how the overload rules change) but would require a lot of work with very little reward. The nice part about the Dv1 -> Dv2 change is that the vast majority of problems are going to be triggered at compile time (exception: some casts and assembler). In general I'm against an "extern(D<ver>)". In some isolated cases it might be useful however usually a feature test instead of a version test is going to be less bug prone. Thomas -----BEGIN PGP SIGNATURE----- iQIVAwUBRmx3CrZlboUnBhRKAQLFZw/7BWXvNHADKrf4OCJhh1sKo10Fn3UjFW3p Oc8rv5kP9a2hh8NMmkCbjYgtZw5w95wraEFSS3pj1+8iH+sJsCEDnefplchUumxP G5eN5bKdIOb12anSuP4mnWZkzXov5TzIJdoi+fJWaEVm1lBdn+JRabfa34mKtPoc AZp1LReEqScPwpJsy50DyFEabncxYE0yhXWFjx2GrCd/oJym5vHHcekXwmyVauDk pVf8+ywwy9FjXFlKgy9ZHXaYnIY30iEvVzZ6L0gzO1UZrFHJQrr9mFoD4xuTV25I zbP/RgYqGxYUYtKBTVDiVAejSR5an44xDpzMz2G2ll3B28rum8BYyGQWa6JzHjQI EWKOYe//GrLt8pCuoFoHWJIG2E0/lr93tQexl1/WoU/pqgW4Gn1hp95vegoog6d0 TYt64pSk+dTE6VWPFX/DLm/Nt0Lq7P+BgixxTFfSDE00nMT+L3Crn64nLMBYOzk4 Dq1bkVIpIUTJgFkJ8iXgW9F5eZkBEfoqo2PZzeaoi8DutcRcd54e5Z97GPlcGZZk jDVB23v4udstLFCF9LDMgHZyP3ntQMZ/ozbsNUYyfpET6/a3nKX3yOGAfCm20uF3 4ivEeeTig9Oh/vsr801bxC3rh/q8AvGOaClUik76XQPdPZ4WnDGXpDV+VwUIr8bF GRhLt4ORd8s= =3HHw -----END PGP SIGNATURE-----
Jun 10 2007
parent reply BCS <ao pathlink.com> writes:
Reply to Thomas,

 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
 BCS schrieb am 2007-06-09:
 
 Reply to Walter,
 


 Well in that case I hope we'll get it when D2.0 comes out of beta.
 (or maybe alpha)
 
 Aside:
 
 This sort of plays into a thought I had as to how D might be able to
 avoid the mess that C++ seems to have gotten into. How about if each
 major version of D is not required to be backwards comparable with
 the last version. Where possible the extern(D<ver>) will be provided
 for backwards (and maybe forwards) compatibility.  However If code
 can't be mapped automatically, then it isn't directly callable and
 that is assumed to be the cost of keeping a clean language.
 

is most likely not difficult, however for the "rest" ... My experience with Flectioned is that supporting multiple runtime libraries(GPhobos, Phobos, Tango) in D - or in the above case versions - can be a real pain. Supporting a Dv1-Dv2-mix in one binary might be possible (depends on how the overload rules change) but would require a lot of work with very little reward. The nice part about the Dv1 -> Dv2 change is that the vast majority of problems are going to be triggered at compile time (exception: some casts and assembler). In general I'm against an "extern(D<ver>)". In some isolated cases it might be useful however usually a feature test instead of a version test is going to be less bug prone.

What about cases where someone ships a Dv1 closed source lib and I need to link it with my app that uses Dv2? It would be nice to be able to link such stuff together at least as well as D links to C. I wouldn't mind having a few corner cases where their is calling signature that can't be used from one to the other, but in the main, I expect that stuff will be inter linkable. p.s. I am NOT thinking about being able to do direct import of Dv1 code by Dv2 code. I would expect that some sort of header files would be built that looks a lot like the stuff under std.c.
Jun 10 2007
parent Thomas Kuehne <thomas-dloop kuehne.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

BCS schrieb am 2007-06-10:
 Reply to Thomas,

 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
 BCS schrieb am 2007-06-09:
 
 Reply to Walter,
 


 Well in that case I hope we'll get it when D2.0 comes out of beta.
 (or maybe alpha)
 
 Aside:
 
 This sort of plays into a thought I had as to how D might be able to
 avoid the mess that C++ seems to have gotten into. How about if each
 major version of D is not required to be backwards comparable with
 the last version. Where possible the extern(D<ver>) will be provided
 for backwards (and maybe forwards) compatibility.  However If code
 can't be mapped automatically, then it isn't directly callable and
 that is assumed to be the cost of keeping a clean language.
 

is most likely not difficult, however for the "rest" ... My experience with Flectioned is that supporting multiple runtime libraries(GPhobos, Phobos, Tango) in D - or in the above case versions - can be a real pain. Supporting a Dv1-Dv2-mix in one binary might be possible (depends on how the overload rules change) but would require a lot of work with very little reward. The nice part about the Dv1 -> Dv2 change is that the vast majority of problems are going to be triggered at compile time (exception: some casts and assembler). In general I'm against an "extern(D<ver>)". In some isolated cases it might be useful however usually a feature test instead of a version test is going to be less bug prone.

What about cases where someone ships a Dv1 closed source lib and I need to link it with my app that uses Dv2? It would be nice to be able to link such stuff together at least as well as D links to C. I wouldn't mind having a few corner cases where their is calling signature that can't be used from one to the other, but in the main, I expect that stuff will be inter linkable.

The most direct solution would be to ask for a Dv2 version of the closed source lib. If there is sufficent demand it is very likely that the lib is going to be ported rather sooner than later. User code might be inter linkable. The real problem could be the runtime internals(including the GC). In a sence this is the current GDC versus DMD issue on steroids. Currently an object file generated by GDC can't be linked against one generated by DMD. And no GDC and DMD aren't feature identical, thus closed source lib providers already should have a flexible enough source to support DMD + Phobos, DMD + Tango, GDC + GPhobos and GDC + Tango within one source tree. Especiall considering that Dv2 is going to be - after some testing ofcourse - the D mainline, adding Dv2 support to the mix shouldn't be too difficult. Thomas -----BEGIN PGP SIGNATURE----- iQIVAwUBRm0DD7ZlboUnBhRKAQK2MQ//d/19rJJt7A26zRN88e2yQQZ/8HvrpDga 4HvI/eBcVpJh4yI/rTak3mN98OoiJ8O2Ht2rqQ+M9YvZksQZnpVa1t/m55FcWx/8 QTeefF7Ah7GJku1333j7jlC/xEGli5wyJPbJGkMVQ+fLuC8lDRfCL4XcHrdPfv7P KJKuxhW4vibI1za007SySRdkHya59Dw97y52bi3VpXj/+q/cgjT9S+HvZHSgFe1s FNIc+l6olZtRGzD5dDbGcF4siihzBuQt7Zm22by6Cb219227r8Oes7aIra1NSuP1 AV2tdPspZyCcz++fJYOjBmqY+Jb7f1RMNxEXwHWGZIxwDYvOfATggV+ftXviZVjk IBiDk0FjDyajyVuh/XL2+mDPBu7h48PVNdn+KQ2cvcxAMw07wqA2zv/QjXdbdSrU wyMVkhS6vzB71GkI1w8AtETQ7k06iDhUZxP+tAX2GDRYPKL33Ifi/Z9yT6AUqJ7O O5WFu/5f9kFMxzYF33/IFEApXpjqzT5DIkfHYy+ii9GLfLLybb8frnIOSo5fYlUw lUYQZjVeZDIuZvTZADL/sqvnJ/A25sddEPTgvmT+HlwCbqFWRQZIES1HuI7TRWw4 mGS9qFXkXXyAwCDHIStA9ipdzvAkEMbgmthKcn8R2HzrxkCOFwZonGbAMD6IaxUx 512PeQHmoAg= =zJLt -----END PGP SIGNATURE-----
Jun 11 2007
prev sibling parent Leandro Lucarella <llucax gmail.com> writes:
BCS, el  9 de junio a las 00:20 me escribiste:
 Reply to Walter,
 
BCS wrote:
Reply to Walter,
BCS wrote:
will the 2.0 series have an extern(D1) if and when somthing breaks
linking?



to implement. What if the behavior of parts of Phobos changes, and one part of the code depends on 1 library behavior, and another part depends on 2? What if trying to accommodate both simultaneously is not practical? How to test all those combinations?

Well in that case I hope we'll get it when D2.0 comes out of beta. (or maybe alpha) Aside: This sort of plays into a thought I had as to how D might be able to avoid the mess that C++ seems to have gotten into. How about if each major version of D is not required to be backwards comparable with the last version. Where possible the extern(D<ver>) will be provided for backwards (and maybe forwards) compatibility. However If code can't be mapped automatically, then it isn't directly callable and that is assumed to be the cost of keeping a clean language.

You can allways use C-linking for legacy code. Which makes me think it could be really useful some kind of tool to automatically expose a class as plain C functions and structs (AKA, C bindings for D code). -- LUCA - Leandro Lucarella - Usando Debian GNU/Linux Sid - GNU Generation ------------------------------------------------------------------------ E-Mail / JID: luca lugmen.org.ar GPG Fingerprint: D9E1 4545 0F4B 7928 E82C 375D 4B02 0FE0 B08B 4FB2 GPG Key: gpg --keyserver pks.lugmen.org.ar --recv-keys B08B4FB2 ------------------------------------------------------------------------ Y no es el centro del Universo! El sol gira alrededor de la tierra! Miles de girasoles no pueden estar equivocados! -- Inodoro Pereyra
Jun 11 2007
prev sibling parent reply eao197 <eao197 intervale.ru> writes:
On Fri, 08 Jun 2007 00:33:42 +0400, Walter Bright  
<newshound1 digitalmars.com> wrote:

 Johan Granberg wrote:
 Didn't Walter say that he would branch the compiler into a current  
 stable
 (what we have now) and an experimental 2.0  compiler. If that is done  
 isn't
 that a clear signal to everyone that the 1.014 (or whatewer the version  
 is
 at the moment) compiler is the one to use for production code?

It's getting pretty clear to me that the 1.0 series won't get any new features, just bug fixes, as the recent 1.015 release suggests. The new features will all go into the 2.0 series.

But for me it looks like: it is better to wait the next version of D language than writing something in D1.0 and rewritting it later. I think a part of the problem is that there are many technologists and early adopters in D community. They all with you have made great and incredible work for D -- thank you for that! But it is time now when more and more pragmatics looks to D as a serious alternative to C++ (Java, C#, you name it). And pragmatics have different view and different demands for the language stability and the language evolution. So please listen our wishes too. As a pragmatic (I hope) I think it is a very sad when a language gets incompatible changes. I didn't need to rewrite my C++ code when switched from one C++ version to another, the same for Java, the same for Ruby. C# is a good example too. So I ask you: don't make D3.0 (and even D4.0) incompatible with D2.0 please. -- Regards, Yauheni Akhotnikau
Jun 07 2007
parent reply Carlos Santander <csantander619 gmail.com> writes:
eao197 escribió:
 
 But for me it looks like: it is better to wait the next version of D 
 language than writing something in D1.0 and rewritting it later.
 

But it wouldn't be rewriting because the bulk of everything would be there. See below.
 I think a part of the problem is that there are many technologists and 
 early adopters in D community. They all with you have made great and 
 incredible work for D -- thank you for that! But it is time now when 
 more and more pragmatics looks to D as a serious alternative to C++ 
 (Java, C#, you name it). And pragmatics have different view and 
 different demands for the language stability and the language evolution. 
 So please listen our wishes too.
 
 As a pragmatic (I hope) I think it is a very sad when a language gets 
 incompatible changes. I didn't need to rewrite my C++ code when switched 
 from one C++ version to another, the same for Java, the same for Ruby. 
 C# is a good example too. So I ask you: don't make D3.0 (and even D4.0) 
 incompatible with D2.0 please.
 

I might be wrong, but I don't think Dv2 will be incompatible with Dv1 in a major way. If you start coding now, perhaps you'll have to branch your code to make use of the shiny new features of Dv2, but I don't foresee many changes. Of course, I guess that depends on your actual code and the features you want to use, but I still wouldn't be so worried. -- Carlos Santander Bernal
Jun 08 2007
parent reply eao197 <eao197 intervale.ru> writes:
On Fri, 08 Jun 2007 20:22:09 +0400, Carlos Santander  
<csantander619 gmail.com> wrote:

 I might be wrong, but I don't think Dv2 will be incompatible with Dv1 in  
 a major way. If you start coding now, perhaps you'll have to branch your  
 code to make use of the shiny new features of Dv2, but I don't foresee  
 many changes. Of course, I guess that depends on your actual code and  
 the features you want to use, but I still wouldn't be so worried.

I don't agree with you. As a C++ programmer I'm big fun of 'const' -- it have saved me from bugs several times. So when const became a part of D I certaintly rewrite my code with use of const/final/invariant. To show you how it can affect my project I can say -- in one my rather big C++ library (~46K lines) there are 121 *.hpp files with ~280 const methods and ~900 const parameters. I think it is not too easy to write all that staff without const at first and then carefully rewrite and retest it with const. -- Regards, Yauheni Akhotnikau
Jun 08 2007
next sibling parent reply Regan Heath <regan netmail.co.nz> writes:
eao197 Wrote:
 On Fri, 08 Jun 2007 20:22:09 +0400, Carlos Santander  
 <csantander619 gmail.com> wrote:
 
 I might be wrong, but I don't think Dv2 will be incompatible with Dv1 in  
 a major way. If you start coding now, perhaps you'll have to branch your  
 code to make use of the shiny new features of Dv2, but I don't foresee  
 many changes. Of course, I guess that depends on your actual code and  
 the features you want to use, but I still wouldn't be so worried.

I don't agree with you. As a C++ programmer I'm big fun of 'const' -- it have saved me from bugs several times. So when const became a part of D I certaintly rewrite my code with use of const/final/invariant. To show you how it can affect my project I can say -- in one my rather big C++ library (~46K lines) there are 121 *.hpp files with ~280 const methods and ~900 const parameters. I think it is not too easy to write all that staff without const at first and then carefully rewrite and retest it with const.

Another reason for const by default with implicit 'in'. If this was implemented then you wouldn't need to re-write anything to get the full benefit where function parameters are concerned. You would need to add const to return values and method signatures, but that would be a lot less to add/recode. Regan
Jun 08 2007
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Regan Heath wrote:
 eao197 Wrote:
 On Fri, 08 Jun 2007 20:22:09 +0400, Carlos Santander  
 <csantander619 gmail.com> wrote:

 I might be wrong, but I don't think Dv2 will be incompatible with Dv1 in  
 a major way. If you start coding now, perhaps you'll have to branch your  
 code to make use of the shiny new features of Dv2, but I don't foresee  
 many changes. Of course, I guess that depends on your actual code and  
 the features you want to use, but I still wouldn't be so worried.

have saved me from bugs several times. So when const became a part of D I certaintly rewrite my code with use of const/final/invariant. To show you how it can affect my project I can say -- in one my rather big C++ library (~46K lines) there are 121 *.hpp files with ~280 const methods and ~900 const parameters. I think it is not too easy to write all that staff without const at first and then carefully rewrite and retest it with const.

Another reason for const by default with implicit 'in'. If this was implemented then you wouldn't need to re-write anything to get the full benefit where function parameters are concerned. You would need to add const to return values and method signatures, but that would be a lot less to add/recode.

Indeed. If D 2.0 were default const, to make your code totally const correct would involve basically while not compiled: try to compile fix compiler error about non-mutable parameter that should be mutable With non-default const it will be more like foreach function in entire codebase: read source code add 'in' to each parameter that looks unmodified Hmm ...I guess you could just go through and manually add 'in' to every parameter everywhere as a first pass (or use a tool to do it), then use the first procedure above. You know I wonder if in general using a tool (an IDE) could be a reasonable way to simulate const-by-default for those who want it. Smart IDEs already know when you're typing function parameter lists, and could be made to always stick in an 'in ' by default after every '(' and ',', in the parameter list. Then you'd have to hit backspace (once) to get rid of it if it's not what you want. --bb
Jun 08 2007
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
eao197 wrote:
 I don't agree with you. As a C++ programmer I'm big fun of 'const' -- it 
 have saved me from bugs several times. So when const became a part of D 
 I certaintly rewrite my code with use of const/final/invariant. To show 
 you how it can affect my project I can say -- in one my rather big C++ 
 library (~46K lines) there are 121 *.hpp files with ~280 const methods 
 and ~900 const parameters. I think it is not too easy to write all that 
 staff without const at first and then carefully rewrite and retest it 
 with const.

My experience with const-correctness is you can largely ignore it unless you are writing libraries. If you are transforming bug-free, tested code into const-correct code, it won't need much testing. Adding const isn't likely to break anything at runtime, just at compile time. Also, although the design is a bit on the complex side, I don't think that complexity will show through much in user code. With type inference and 'in' parameters, I don't think you'll have to write 'const' all that often - certainly much less than in C++.
Jun 09 2007
next sibling parent reply Sean Kelly <sean f4.ca> writes:
Walter Bright wrote:
 eao197 wrote:
 I don't agree with you. As a C++ programmer I'm big fun of 'const' -- 
 it have saved me from bugs several times. So when const became a part 
 of D I certaintly rewrite my code with use of const/final/invariant. 
 To show you how it can affect my project I can say -- in one my rather 
 big C++ library (~46K lines) there are 121 *.hpp files with ~280 const 
 methods and ~900 const parameters. I think it is not too easy to write 
 all that staff without const at first and then carefully rewrite and 
 retest it with const.

My experience with const-correctness is you can largely ignore it unless you are writing libraries. If you are transforming bug-free, tested code into const-correct code, it won't need much testing. Adding const isn't likely to break anything at runtime, just at compile time. Also, although the design is a bit on the complex side, I don't think that complexity will show through much in user code. With type inference and 'in' parameters, I don't think you'll have to write 'const' all that often - certainly much less than in C++.

I'll admit that one of my reservations about 'const' is the need to potentially write twice as many class methods. I don't suppose there's any way around this? Sean
Jun 09 2007
next sibling parent reply gareis <dhasenan gmail.com> writes:
Sean Kelly wrote:
 Walter Bright wrote:
 eao197 wrote:
 I don't agree with you. As a C++ programmer I'm big fun of 'const' -- 
 it have saved me from bugs several times. So when const became a part 
 of D I certaintly rewrite my code with use of const/final/invariant. 
 To show you how it can affect my project I can say -- in one my 
 rather big C++ library (~46K lines) there are 121 *.hpp files with 
 ~280 const methods and ~900 const parameters. I think it is not too 
 easy to write all that staff without const at first and then 
 carefully rewrite and retest it with const.

My experience with const-correctness is you can largely ignore it unless you are writing libraries. If you are transforming bug-free, tested code into const-correct code, it won't need much testing. Adding const isn't likely to break anything at runtime, just at compile time. Also, although the design is a bit on the complex side, I don't think that complexity will show through much in user code. With type inference and 'in' parameters, I don't think you'll have to write 'const' all that often - certainly much less than in C++.

I'll admit that one of my reservations about 'const' is the need to potentially write twice as many class methods. I don't suppose there's any way around this? Sean

Either you need to modify your function's parameter, in which case you can't write a const version, or you don't need to modify your function's parameter, in which case you just pass it in as const. So how do you need to write additional methods? -gareis
Jun 10 2007
next sibling parent Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
gareis wrote:
 Sean Kelly wrote:
 I'll admit that one of my reservations about 'const' is the need to 
 potentially write twice as many class methods.  I don't suppose 
 there's any way around this?

Either you need to modify your function's parameter, in which case you can't write a const version, or you don't need to modify your function's parameter, in which case you just pass it in as const. So how do you need to write additional methods?

When the return value should have a different type depending on the types of the parameters and/or "this"? For instance, when you want to return a slice of a string you might want the slice to have the same "constness" as one of the parameters (or "this" in case of a String class). This would require either overloading on constness (i.e. extra methods) or perhaps some template magic. The latter option might not be available if you need the method(s) to be overridable, by the way. Also, it might even be triple the methods in some cases: mutable/const/invariant.
Jun 10 2007
prev sibling parent Sean Kelly <sean f4.ca> writes:
gareis wrote:
 Sean Kelly wrote:
 I'll admit that one of my reservations about 'const' is the need to 
 potentially write twice as many class methods.  I don't suppose 
 there's any way around this?

Either you need to modify your function's parameter, in which case you can't write a const version, or you don't need to modify your function's parameter, in which case you just pass it in as const. So how do you need to write additional methods?

class MyClass { const char[] slice() const { ... } char[] slice() { ... } } Sean
Jun 10 2007
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Sean Kelly wrote:
 Walter Bright wrote:
 eao197 wrote:
 I don't agree with you. As a C++ programmer I'm big fun of 'const' -- 
 it have saved me from bugs several times. So when const became a part 
 of D I certaintly rewrite my code with use of const/final/invariant. 
 To show you how it can affect my project I can say -- in one my 
 rather big C++ library (~46K lines) there are 121 *.hpp files with 
 ~280 const methods and ~900 const parameters. I think it is not too 
 easy to write all that staff without const at first and then 
 carefully rewrite and retest it with const.

My experience with const-correctness is you can largely ignore it unless you are writing libraries. If you are transforming bug-free, tested code into const-correct code, it won't need much testing. Adding const isn't likely to break anything at runtime, just at compile time. Also, although the design is a bit on the complex side, I don't think that complexity will show through much in user code. With type inference and 'in' parameters, I don't think you'll have to write 'const' all that often - certainly much less than in C++.

I'll admit that one of my reservations about 'const' is the need to potentially write twice as many class methods. I don't suppose there's any way around this? Sean

Good question, I wonder if this has been given any thought by Walter and others on this, and if perhaps a solution like Javari's romaybe has been considered. It might be really a problem if we have to write multiple versions of the same version, which like Frits said, may be 3 and not just 2 versions. -- Bruno Medeiros - MSc in CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Jun 11 2007
prev sibling parent reply eao197 <eao197 intervale.ru> writes:
On Sun, 10 Jun 2007 08:00:30 +0400, Walter Bright  
<newshound1 digitalmars.com> wrote:

 I don't agree with you. As a C++ programmer I'm big fun of 'const' --  
 it have saved me from bugs several times. So when const became a part  
 of D I certaintly rewrite my code with use of const/final/invariant. To  
 show you how it can affect my project I can say -- in one my rather big  
 C++ library (~46K lines) there are 121 *.hpp files with ~280 const  
 methods and ~900 const parameters. I think it is not too easy to write  
 all that staff without const at first and then carefully rewrite and  
 retest it with const.

My experience with const-correctness is you can largely ignore it unless you are writing libraries. If you are transforming bug-free, tested code into const-correct code, it won't need much testing. Adding const isn't likely to break anything at runtime, just at compile time.

But I'm mostly library writer than application writer. On my work I write domain-specific or more general purpose libraries which then used in application development by me and my colleagues. A long time ago I had some expirience of modifying C++ code without consts to code with consts. Main trouble was to identify methods which must be declared as const -- it required full code review.
 Also, although the design is a bit on the complex side, I don't think  
 that complexity will show through much in user code. With type inference  
 and 'in' parameters, I don't think you'll have to write 'const' all that  
 often - certainly much less than in C++.

May be you right. But as I can see main problem with porting D code to D code with const will be const methods in classes, not const parameter nor const inside methods. -- Regards, Yauheni Akhotnikau
Jun 09 2007
parent reply Walter Bright <newshound1 digitalmars.com> writes:
eao197 wrote:
 A long time ago I had some expirience of modifying C++ code without 
 consts to code with consts. Main trouble was to identify methods which 
 must be declared as const -- it required full code review.

I suspect that it can be done by declaring all as const, then removing const from those that generate compile time errors. If you err on the side of adding too many const's, your program won't crash, it just won't compile. I'll also argue that if a full code review was required, that the code documentation was either incomplete or unreliable. Having const will reduce the problem by bringing the documentation into the semantic information of the code, and so reduce the need for code reviews in the future.
Jun 10 2007
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Walter Bright wrote:
 eao197 wrote:
 A long time ago I had some expirience of modifying C++ code without
 consts to code with consts. Main trouble was to identify methods which
 must be declared as const -- it required full code review.

I suspect that it can be done by declaring all as const, then removing const from those that generate compile time errors. If you err on the side of adding too many const's, your program won't crash, it just won't compile.

Whoops. I think you just gave the "const by default" camp a big crate of those cool incendiary rounds. I've been thinking about it, and I have to agree with both camps on a lot of their arguments. const by default is safer and clearer, whilst mutable by default is obvious and more consistent with how we're already writing code. Since the new const stuff is going to require at least a few alpha releases to get the kinks out, why not allow for both? How hard would it be to add a switch (say -constdefault) to the compiler *just* for the initial alpha releases? That way, instead of arguing over hypothetical situations, we can actually sit down and work out the pros and cons of both. An ideological fight to the death, if you will. const by default in one corner, mutable by default in the other, throw in some lightsabres and let the problem sort itself out. :P -- Daniel
Jun 10 2007
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Daniel Keep wrote:
 I've been thinking about it, and I have to agree with both camps on a
 lot of their arguments.  const by default is safer and clearer, whilst
 mutable by default is obvious and more consistent with how we're already
 writing code.

const by default is too big a change, and I'm reluctant to do something so far out of the mainstream of these types of languages.
Jun 10 2007
next sibling parent reply Deewiant <deewiant.doesnotlike.spam gmail.com> writes:
Walter Bright wrote:
 const by default is too big a change, and I'm reluctant to do something
 so far out of the mainstream of these types of languages.

Perl 6 has const by default for subroutine parameters. Okay, so it's not "this type of language", but it's worth mentioning as it's still _Perl_, a language steadily a couple or more places above D in the TIOBE index. -- Remove ".doesnotlike.spam" from the mail address.
Jun 10 2007
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Deewiant wrote:
 Walter Bright wrote:
 const by default is too big a change, and I'm reluctant to do something
 so far out of the mainstream of these types of languages.

Perl 6 has const by default for subroutine parameters. Okay, so it's not "this type of language", but it's worth mentioning as it's still _Perl_, a language steadily a couple or more places above D in the TIOBE index.

By "these types of languages", I mean C-style compiled languages. There are many functional languages where const is the default.
Jun 10 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Walter Bright wrote:
 Deewiant wrote:
 Walter Bright wrote:
 const by default is too big a change, and I'm reluctant to do something
 so far out of the mainstream of these types of languages.

Perl 6 has const by default for subroutine parameters. Okay, so it's not "this type of language", but it's worth mentioning as it's still _Perl_, a language steadily a couple or more places above D in the TIOBE index.

By "these types of languages", I mean C-style compiled languages. There are many functional languages where const is the default.

Hey, Perl is a "curly brace" language too! ;-) Here's the lo-down on Perl 6: http://www.perl.com/pub/a/2003/07/29/exegesis6.html They're using the syntax sub Foo(Num x) { ... } # x is const ref sub Foo(Num x is rw) { ... } # x is 'read-write' ref sub Foo(Num x is copy) { ... } # x is pass by value --bb
Jun 10 2007
parent reply Dave <Dave_member pathlink.com> writes:
Bill Baxter wrote:
 Walter Bright wrote:
 Deewiant wrote:
 Walter Bright wrote:
 const by default is too big a change, and I'm reluctant to do something
 so far out of the mainstream of these types of languages.

Perl 6 has const by default for subroutine parameters. Okay, so it's not "this type of language", but it's worth mentioning as it's still _Perl_, a language steadily a couple or more places above D in the TIOBE index.

By "these types of languages", I mean C-style compiled languages. There are many functional languages where const is the default.

Hey, Perl is a "curly brace" language too! ;-) Here's the lo-down on Perl 6: http://www.perl.com/pub/a/2003/07/29/exegesis6.html They're using the syntax sub Foo(Num x) { ... } # x is const ref sub Foo(Num x is rw) { ... } # x is 'read-write' ref sub Foo(Num x is copy) { ... } # x is pass by value

Funny thing is since the whole history of Perl revolves around practicality, to me this is a pretty strong argument that the time is ripe for a C-style compiled language to try the same thing.
 --bb

Jun 10 2007
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Dave wrote:
 Bill Baxter wrote:
 Walter Bright wrote:
 Deewiant wrote:
 Walter Bright wrote:
 const by default is too big a change, and I'm reluctant to do 
 something
 so far out of the mainstream of these types of languages.

Perl 6 has const by default for subroutine parameters. Okay, so it's not "this type of language", but it's worth mentioning as it's still _Perl_, a language steadily a couple or more places above D in the TIOBE index.

By "these types of languages", I mean C-style compiled languages. There are many functional languages where const is the default.

Hey, Perl is a "curly brace" language too! ;-) Here's the lo-down on Perl 6: http://www.perl.com/pub/a/2003/07/29/exegesis6.html They're using the syntax sub Foo(Num x) { ... } # x is const ref sub Foo(Num x is rw) { ... } # x is 'read-write' ref sub Foo(Num x is copy) { ... } # x is pass by value

Funny thing is since the whole history of Perl revolves around practicality, to me this is a pretty strong argument that the time is ripe for a C-style compiled language to try the same thing.

That may have been true about Perl up to version 5. But... From wikipedia: """ The Perl 6 design process was first announced on July 19, 2000, on day 4 of that year's Perl Conference,[2] by Larry Wall in his State of the Onion 2000 talk. """ A 7-year-and-counting design/release cycle is pretty much as far from practical as you can get. But still Perl is well known and widely used, and I suspect if Perl 6 is ever released it will eventually be adopted by most Perl hackers. Though with Perl 6 taking such a long time to get out, one can't help but fear that the "second-system effect" is at work here. (http://en.wikipedia.org/wiki/Second-system_effect) --bb
Jun 10 2007
prev sibling next sibling parent Charlie <charlie.fats gmail.com> writes:
Walter Bright wrote:
 Daniel Keep wrote:
 I've been thinking about it, and I have to agree with both camps on a
 lot of their arguments.  const by default is safer and clearer, whilst
 mutable by default is obvious and more consistent with how we're already
 writing code.

const by default is too big a change, and I'm reluctant to do something so far out of the mainstream of these types of languages.

I'd argue const, which only has one ( terrible ) implementation in curly brace languages ( C++ ), is already out of the mainstream. And decorating everything with const just plain sucks. If your argument is really that most people will be turned off by default const, Id argue that more people are turned off by default mutable. D has a chance to improve this paradigm, why are we sticking with an approach that most people agree is weak/broken already ? Charlie
Jun 10 2007
prev sibling next sibling parent Regan Heath <regan netmail.co.nz> writes:
Walter Bright Wrote:
 Daniel Keep wrote:
 I've been thinking about it, and I have to agree with both camps on a
 lot of their arguments.  const by default is safer and clearer, whilst
 mutable by default is obvious and more consistent with how we're already
 writing code.

const by default is too big a change, and I'm reluctant to do something so far out of the mainstream of these types of languages.

... :(
Jun 10 2007
prev sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:f4gg3j$hc$1 digitalmars.com...

 const by default is too big a change, and I'm reluctant to do something so 
 far out of the mainstream of these types of languages.

"These types of languages"? You mean "C++"? What other languages are like D, anyway?
Jun 10 2007
parent reply Dave <Dave_member pathlink.com> writes:
Jarrett Billingsley wrote:
 "Walter Bright" <newshound1 digitalmars.com> wrote in message 
 news:f4gg3j$hc$1 digitalmars.com...
 
 const by default is too big a change, and I'm reluctant to do something so 
 far out of the mainstream of these types of languages.

"These types of languages"? You mean "C++"? What other languages are like D, anyway?

Just about any other imperative language (BASIC, Fortran, Pascal, Ada, Oberon and of course C, C++, C# and Java, the LAMP languages, yada, yada, etc...), so Walter may have a point. OTOH, since 'mutable by default' has been done ad nauseum for imperative languages, and the above is really an onerous list to try and compete against for mind-share, maybe D 2.0 _should_ try 'const by default'.
Jun 10 2007
parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Dave" <Dave_member pathlink.com> wrote in message 
news:f4i50m$2ct5$1 digitalmars.com...
 OTOH, since 'mutable by default' has been done ad nauseum for imperative 
 languages, and the above is really an onerous list to try and compete 
 against for mind-share, maybe D 2.0 _should_ try 'const by default'.

Which is one of my big reasons for giving it a shot. It's just time to try something different.
Jun 10 2007
prev sibling parent reply Oliver Dick <oliver evilstorm.de> writes:
eao197 schrieb:
 Because of that must be some moment when Walter say: "We stop adding new 
 features. Now we take two or three years of language stability and see 
 what happens here". 

I totally agree. Beside of the fact that support for const is really an important language feature, I think it's necessary to stop the evolution at some point. With version 1.0 released in Jan 2007 I started to take a closer look at D and considered to use it for production code. But the upcoming months showed that the following 1.xxx releases weren't just maintenance releases but constantly introduced new language features. There is no roadmap on the website - no plans to create a standard for D - it seemed to me that it was nothing more than a playground to try out cool language features. And therefore not ready for production code yet. I hope I'm wrong, since D is the language I've always searched for.
Jun 07 2007
parent gareis <dhasenan gmail.com> writes:
Oliver Dick wrote:
 eao197 schrieb:
 Because of that must be some moment when Walter say: "We stop adding 
 new features. Now we take two or three years of language stability and 
 see what happens here". 

I totally agree. Beside of the fact that support for const is really an important language feature, I think it's necessary to stop the evolution at some point.

Not to stop it -- just to move on to things that won't break existing code. For example, C# and Java didn't get generics anywhere near their initial releases; Java got generics in 1.5 and C# in 2.0. But that was a pure addition in each case. I'd like to see aspect-oriented programming and reflection in D on par with that of C#. (Now that I see Flectioned, std.traits, and TypeInfo, I think it'd be possible to come up with a Rhino Mocks equivalent for D, if there's a way to get function names. That still leaves AOP.) But even if these are left behind until a 3.0 release, that's fine. All existing code would still work. I suppose we'll eventually just replace evolution with aggregation.
 With version 1.0 released in Jan 2007 I started to take a closer look at 
 D and considered to use it for production code. But the upcoming months 
 showed that the following 1.xxx releases weren't just maintenance 
 releases but constantly introduced new language features.
 
 There is no roadmap on the website - no plans to create a standard for D 
 - it seemed to me that it was nothing more than a playground to try out 
 cool language features. And therefore not ready for production code yet.
 
 I hope I'm wrong, since D is the language I've always searched for.

At some point, if the language doesn't stabilize, people using D will just settle on a particular version to use for production code. Then it'll be a matter of switching to gdc since it'll get bugfixes and the sort of improvements that don't break existing code. Though I think that, the sooner there's a stable consensus, the more likely it is that D will have a respectable role in production environments. Currently, all my friends who program mock me over my use of the language. I suppose using D would be much more of an issue for me if I were writing code that required more than the standard library. D has been around since 1998, I believe, and is able to link with C code, yet it still has very few libraries available.
Jun 07 2007
prev sibling next sibling parent reply Falk-Florian Henrich <schreibmalwieder hammerfort.de> writes:
Am Tue, 05 Jun 2007 20:25:03 +0400 schrieb eao197:

 I'm watching for discussions 'Stepping back and looking at constness
 from another angle' here and 'resizeable arrays: T[new]' & 'preparing
 for const, final, and invariant' in digitalmars.D.announce and I'm sad.
 I occasionally locked to D may be from 2003 -- it was a constantly
 changing language. At the end of 2006 I thought that D is stable enough
 to start to use it. And in Jan 2007 the v.1.000 went out. I thought that
 in near time D would have only bug fix releases and it is a time when
 various tools for D (like libraries and IDEs) would be produced.
 
 But I was wrong.
 
 What we have now? The language which keeps their evolution. Lack of
 libraries, lack of tools, lack of documentation (books and tutorials).
 As a consequence -- lack of users. And we don't get much new users and
 new applications without new libraries/tools/documentation.
 
 As a programmer I need a stable language. A language in which I can
 write a domain-specific library and forget about its maintenace for
 three of five years (as for some of my C++ libraries those I wrote in
 2002-2003). I need to write applications and because of that I need a
 quality and stable compiler, a quality and stable standard library, and
 quality third party libraries. And third party libraries' writters need
 a stable tools too.
 
 But now, when I'm writting some D code, I know that in near feature the
 next D version will be here. And that version broke my code because of
 consts and new syntax of resizeable arrays. So why to start a new big
 project on D if its codebase will be obsolete in few months?
 
 And I'm affraid that after adding consts/final/invariant support to D
 the language keeps their envolution :(
 
 Yes consts/final/invariant is a great addition to the language. But D
 now is very powerful language. It is now more powerful than C++0x will
 be. So may be it is better to stop add new features and make a stable
 platform for library/tools writters at first and then for applications
 writters? AFAIK, every successful languages were going such way -- the
 good initial release and some new releases later with years of stability
 beetwen them. And I'm affraid that C++0x will be here before D would get
 a stable language with enough libraries and tools.
 
 May be it is better to concentrate on improvement of the current
 implementation (fast precise GC instead of the current conservative GC,
 for example) instead of introducing incompatible changes in the
 language?
 
 And my main question is: will be D a constanly changing language or will
 be there some time-outs in its evolution?

I totally agree. The priority given to the "hunt for features" will take us nowhere. Instead of designing and implementing a couple of new features every other month it would be more appropriate to first fix at least the major bugs in the compiler. D already as an amazing set of features which surely can be used to produce awesome code. On the other hand, the compiler is buggy and does not comply with the language specification. Let me give a concrete example [1]: The D spec allows for parametric polymorphism via template functions. This sounds great, but the compiler's broken type inference algorithm renders it useless: If I have a function template F that takes some ordinary function f as a parameter [2] the spec allows me to use overloaded variants of f as instantiation parameter to F. Unfortunately, the type inference (in template.c) is simply a mess of intertwined gotos and other unreadable stuff [3]. Worse, it cannot cope with the situation [4]: Instead of choosing the appropriate overload of f, it just takes the first variant it finds in the source file. This renders parametric polymorphism unusable in practice. Maybe, all this sounds a bit harsh, but it's simply the truth. My purpose of stating these problems is surely not to insult anyone, but to show that completing the implementation of the existing concepts is much more worthwhile (as of 2007) than crafting some "killer feature". Otherwise, I fear D's user base will not grow any further. Falk [1] Many people (including myself) have mentioned this bug before. I repeat the story here, because I think it shows how the usefulness of a feature vanishes completely if its implementation was done in a haste. [2] Via this technique a lot of keyword bloat (foreach etc) could be avoided -- if the compiler would obey the spec. [3] I tried to debug it but didn't succeed, since I'm not a compiler expert and the documentation is not very helpful. [4] There are many, many other problems with D's type inference. This finally led me to the conclusion that its implementation is a dirty hack -- which I don't know the reason for, since there exist working type inference algorithms at least since the seventies.
Jun 06 2007
parent Dejan Lekic <dejan.lekic gmail.com> writes:
 [2] Via this technique a lot of keyword bloat (foreach etc) could be 
 avoided -- if the compiler would obey the spec.

That "bloat" made me switch from C++ to D, after 15 years of professional C++ programming. You can always use the "-1" switch and forget about changes in D, right?
Jun 06 2007
prev sibling parent reply Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
Not yet.

Some people don't yet believe there's a valid reason to switch to D. 
Some point out const as the major lacking feature. I would definitely 
like to see some extra features in the language.

We'll have two branches that should satisfy the folks writing libs and 
the folks that want to ride the cutting edge.

As long as critical bugs are fixed quickly, I'd say... Walter, keep on 
rocking!


-- 
Tomasz Stachowiak
http://h3.team0xf.com/
h3/h3r3tic on #D freenode
Jun 06 2007
parent Frank Benoit <keinfarbton googlemail.com> writes:
 As long as critical bugs are fixed quickly, I'd say... Walter, keep on
 rocking!

This is what i think
Jun 06 2007