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


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


 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

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?
 


 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.
 


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?
 


 No.
 


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?


 No.


 
 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?
 


 No.
 


 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?


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?
 


 No.
 


 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?


 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.
 


 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.
 


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.
 


 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.
 


 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?


No.


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?


 
 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  

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  

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

 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. 

 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.


 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.


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




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



 


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





 
 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++, 

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 


pure addition in each case.

I'd like to see aspect-oriented programming and reflection in D on par 

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 next 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
prev sibling parent reply Danny <mindstorm8191 yahoo.com> writes:
eao197 Wrote:


 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


I don't think a planned time-out in a language evolution would be a good idea. 
Yes, changes to the language may make older programs incompatible with the new
versions, and that would be quite bad for the language in general.  But D needs
to continue to evolve, if it is going to, until its basically done.  People can
then begin building libraries for it, and grow its code base.  If we were to
pause D's evolution and pick it up again later, it would cause all the existing
code to no longer work, leaving people to either give up the old working code,
modify it or find something else to use.

If D is going to evolve, we need to hurry up and finish that process, so that
D's code base can begin growing.
Jun 07 2007
parent Derek Parnell <derek psych.ward> writes:
On Thu, 07 Jun 2007 23:56:06 -0400, Danny wrote:


 eao197 Wrote:

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




 

 I don't think a planned time-out in a language evolution would be a good idea.


I had a friend that used to say "The problem with making plans is that just
gives me another thing I'll have change." Of course it was a joke but
making a plan does add the responsibility of keeping it up to date with the
many changes to it.

-- 
Derek Parnell
Melbourne, Australia
"Justice for David Hicks!"
skype: derek.j.parnell
Jun 08 2007