"Niko Korhonen" <niktheblak@hotmail.com> wrote in message news:dnolt3$eeo$1@digitaldaemon.com...
> My view is that D's had some positively *huge* breaking changes in the last couple of months, including but not limited to:
>
> * Type inference (the most major change; IMO should have been in D 2.0)
> * $ symbol in arrays
> * New features in Phobos
> * Refactoring and other changes in Phobos
> * String postfix literals
> * === and !== replaced with is and !is
> * .size replaced with .sizeof
>
> All of these changes are non-backwards compatible,

I don't agree, the type inference, $, new Phobos functions, and string postfix don't break existing code. The others are minor textual edits, and the compiler has good support for identifying the changes, and suggesting the fix. With this, fixing the code for them is not difficult or time consuming - there were no structural changes or rewrites necessary.

> and an even more major change is coming (stack allocation).

This won't break existing code.

> To me this hardly seems 'fixed'. If C# or Java would keep changing in this pace, nobody would dare to use them.
>
> The pace of breaking changes in D is *fast*, even when comparing against other alpha-stage languages. This is visible in e.g. GDC's constant struggle keep up with DMD.
>
> Given all this I don't blame anyone for not daring to use D in any major project. Projects whose timespan may be several years need such a level of fixture that D cannot offer in the foreseeable future.

Any project whose timespan is several years should archive the tools used to build the project, along with that project. Heck, gcc and dmc++ have seen breaking changes in the last year, and all along.

Walter Bright wrote:

> I don't agree, the type inference, $, new Phobos functions, and string postfix don't break existing code. The others are minor textual edits, and the compiler has good support for identifying the changes, and suggesting the fix. With this, fixing the code for them is not difficult or time consuming - there were no structural changes or rewrites necessary.

The only breakage that I saw was that the new features wouldn't work with an older compiler, so I would have to wait for GDC to catch up.

But in the end (and pretty darn quick too), it always has done so...
http://www.prowiki.org/wiki4d/wiki.cgi?HistoryRoadmap

--anders

Walter Bright wrote:
> "Niko Korhonen" <niktheblak@hotmail.com> wrote in message news:dnolt3$eeo$1@digitaldaemon.com...
> 
>>My view is that D's had some positively *huge* breaking changes in the last couple of months, including but not limited to:
>>
>>* Type inference (the most major change; IMO should have been in D 2.0)
>>* $ symbol in arrays
>>* New features in Phobos
>>* Refactoring and other changes in Phobos
>>* String postfix literals
>>* === and !== replaced with is and !is
>>* .size replaced with .sizeof
>>
>>All of these changes are non-backwards compatible,
> 
> 
> I don't agree, the type inference, $, new Phobos functions, and string postfix don't break existing code. The others are minor textual edits, and the compiler has good support for identifying the changes, and suggesting the fix. With this, fixing the code for them is not difficult or time consuming - there were no structural changes or rewrites necessary.

True :) I haven't been forced to commit any major changes in my code (to account for a new dmd release) ever since I've been using D.


-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d-pu s+: a-->----- C+++$>++++ UL P+ L+ E--- W++ N++ o? K? w++ !O !M V? PS- PE- Y PGP t 5 X? R tv-- b DI- D+ G e>+++ h>++ !r !y
------END GEEK CODE BLOCK------

Tomasz Stachowiak  /+ a.k.a. h3r3tic +/

Anders F Björklund wrote:
> AAs have also been through some dramatic changes, with the "in" etc ?
> And there's still a few "major annoyances" left in the D language...

Yes, that is very much a major change, thanks for pointing that one out!

> I think the idea and spirit of what I was trying to say that what we
> have now in D should be good enough to "freeze features" on and start
> fixing the bugs and get it released once - *then* move on to the 2.0 ?
> At least get the specification finalized, while fixing compiler bugs.

I'm still not sure are the current standard library, GC scheme, AA's and type inference ready for prime time. Plus a couple of uncertain features such as bit arrays, AA's, array initialization etc.

IMHO D should/must have a "pinned pointer" syntax in order to allow compacting GC's or explicitly state in the spec that "a compacting GC is not, will not and cannot be used in D, never ever ever". Otherwise this will be a *major* limitation in compiler/runtime implementation and it's going to cause *gargantuan* changes in existing code if it's implemented later on.

I also would like to see bit arrays and AA's in the standard library instead of the language; IMO D isn't high-enough level language for that. Not to mention that I downright abhor the "whisper syntax". In the last couple of months I've seen D gradually mutating towards C++ with new features that increase complexity. Please don't make it any more complicated than it already is.

-- 
Niko Korhonen
SW Developer

Walter Bright wrote:
> I don't agree, the type inference, $, new Phobos functions, and string postfix don't break existing code. The others are minor textual edits, and the compiler has good support for identifying the changes, and suggesting the fix. With this, fixing the code for them is not difficult or time consuming - there were no structural changes or rewrites necessary.

True, only === and AA are actually breaking changes but the other ones are still not backwards compatible.

>>and an even more major change is coming (stack allocation).
> 
> This won't break existing code.

True, but it changes the language semantics in a major way thus requiring re-education of D programmers.

Think of the "accidentally return a pointer to a stack-allocated object from a function" C++ scenario, please!

In a previous reply I mentioned that D is gradually mutating into C++; the heap/stack allocation separation that you are going to implement in D is IMHO a major step in that direction, especially since the syntax is almost like in C++.

> Any project whose timespan is several years should archive the tools used to build the project, along with that project. Heck, gcc and dmc++ have seen breaking changes in the last year, and all along. 

Yes, but for argument's sake consider a situation where a project has 5M lines of DMD 0.141 code. Assume that it turns out that DMD 0.141 has a nasty compiler bug that forces the project to use some pretty ugly workarounds. Suppose this bug was fixed in DMD 0.143, but 0.142 added a breaking change which would need tens or possibly hundreds of man-hours to track down the needed changes in the source. The customer doesn't want to pay for these hours so the project management refuses the compiler update. Bang! The project is forever stuck with DMD 0.141 and the programmers are likewise stuck using these ugly workarounds and can only dream about the nifty new features that DMD 0.150 brought; say bye-bye to employer morale.

I've seen a project at my work place that has stuck into Java 1.3.1_b24 forever because of some nasty breaking changes in the immediately following JDK version. It's horrible when that happens. Probably the worst thing that can happen in software development.

-- 
Niko Korhonen
SW Developer

Niko Korhonen wrote:
> Walter Bright wrote:
>>> and an even more major change is coming (stack allocation).
>>
>>
>> This won't break existing code.
> 
> 
> True, but it changes the language semantics in a major way thus requiring re-education of D programmers.
> 
> Think of the "accidentally return a pointer to a stack-allocated object from a function" C++ scenario, please!

DMD.141
-------

Object foo() {
	auto Object x = new Object;
	return x;		// error: escaping reference to auto local x
}

There you go :) DMD won't let you hurt yourself now and it won't let you when stack allocation is added.


> In a previous reply I mentioned that D is gradually mutating into C++; the heap/stack allocation separation that you are going to implement in D is IMHO a major step in that direction, especially since the syntax is almost like in C++.

No, it's a step towards better performance of D code so that former C/C++ programmers won't complain too much. As Walter said, it's not going to break existing code. Unless it's buggy, because then its behaviour might be undefined anyway.


> Yes, but for argument's sake consider a situation where a project has 5M lines of DMD 0.141 code. Assume that it turns out that DMD 0.141 has a nasty compiler bug that forces the project to use some pretty ugly workarounds. Suppose this bug was fixed in DMD 0.143, but 0.142 added a breaking change which would need tens or possibly hundreds of man-hours to track down the needed changes in the source. The customer doesn't want to pay for these hours so the project management refuses the compiler update. Bang! The project is forever stuck with DMD 0.141 and the programmers are likewise stuck using these ugly workarounds and can only dream about the nifty new features that DMD 0.150 brought; say bye-bye to employer morale.

Your assumptions are wrong. There is no D project I've ever heard of to have 5M lines of code. As D matures, I expect less and less features being added to the 'stable' compiler branch. I can't speak for Walter, but DMD will probably branch off into the 'beta' / 'development' / 'research' compiler which will adopt new features until it becomes the 'stable' release. People are already starting to do this with GDC.


> I've seen a project at my work place that has stuck into Java 1.3.1_b24 forever because of some nasty breaking changes in the immediately following JDK version. It's horrible when that happens. Probably the worst thing that can happen in software development.

Since D is so easy to parse, then perhaps we could have an automatic 'conversion tool' between DMD version X and Y ?


-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d-pu s+: a-->----- C+++$>++++ UL P+ L+ E--- W++ N++ o? K? w++ !O !M V? PS- PE- Y PGP t 5 X? R tv-- b DI- D+ G e>+++ h>++ !r !y
------END GEEK CODE BLOCK------

Tomasz Stachowiak  /+ a.k.a. h3r3tic +/

Tom S wrote:
> DMD.141
> -------
> 
> Object foo() {
>     auto Object x = new Object;
>     return x;        // error: escaping reference to auto local x
> }
> 
> There you go :) DMD won't let you hurt yourself now and it won't let you when stack allocation is added.


Object* f()
{
	auto Object obj = new Object();
	Object* ptr = &obj;
	return ptr;
} // The pointer is no longer valid

int main()
{
	Object* ptr = f();
	return 0;
}

Compiles OK and warns only "warning - rettest.d(5): function rettest.f no return at end of function". Boo-yeah :)

Actually I can argue that when a language allows pointers it's impossible to determine whether a local object reference is escaped during compile time. A nice casting round-trip should do the job.

> No, it's a step towards better performance of D code so that former C/C++ programmers won't complain too much. As Walter said, it's not going to break existing code. Unless it's buggy, because then its behaviour might be undefined anyway.

Well, I just feel that:

auto obj = new Object();
auto obj = Object();

is kind of ugly in the way of being very C++'ish. I would prefer the C#'s slightly ambiguous but nonetheless very nice method of using 'new' syntax for both heap and stack-allocated objects. Here's my adaptation of the concept for D (your mileage may vary):

auto class StackObj;
class HeapObj;

StackObj obj0; // Stack-allocated, default-value initialized
StackObj obj1 = new StackObj(); // Stack-allocated
HeapObj obj2 = new HeapObj(); // Heap-allocated

This doesn't solve the 'return &obj1' problem, but then again, nothing does.

> Since D is so easy to parse, then perhaps we could have an automatic 'conversion tool' between DMD version X and Y ?

Hmm, preferably not. Besides, who's going to do that? Walter, Derek and Anders are already busy!

-- 
Niko Korhonen
SW Developer

Tom S wrote:
> Your assumptions are wrong. There is no D project I've ever heard of to have 5M lines of code. As D matures, I expect less and less features being added to the 'stable' compiler branch. I can't speak for Walter, but DMD will probably branch off into the 'beta' / 'development' / 'research' compiler which will adopt new features until it becomes the 'stable' release. People are already starting to do this with GDC.

But that's not /now/ and given that the language spec/compiler has been in alpha stage for five years, I imagine it's not going to be so in a while.

Someone might want to start a 5MLoC D project now. It would be pretty great if they could since no one wants to start a 5MLoC project before there are any successful 5MLoC projects...

-- 
Niko Korhonen
SW Developer

Niko Korhonen wrote:
> Tom S wrote:
> 
>> DMD.141
>> -------
>>
>> Object foo() {
>>     auto Object x = new Object;
>>     return x;        // error: escaping reference to auto local x
>> }
>>
>> There you go :) DMD won't let you hurt yourself now and it won't let you when stack allocation is added.
> 
> 
> 
> Object* f()
> {
>     auto Object obj = new Object();
>     Object* ptr = &obj;
>     return ptr;
> } // The pointer is no longer valid
> 
> int main()
> {
>     Object* ptr = f();
>     return 0;
> }
> 
> Compiles OK and warns only "warning - rettest.d(5): function rettest.f no return at end of function". Boo-yeah :)

My point was that you get the same level of security when using stack allocation as when using heap allocation :P


> Actually I can argue that when a language allows pointers it's impossible to determine whether a local object reference is escaped during compile time. A nice casting round-trip should do the job.

/me agrees


> Well, I just feel that:
> 
> auto obj = new Object();
> auto obj = Object();
> 
> is kind of ugly in the way of being very C++'ish. I would prefer the C#'s slightly ambiguous but nonetheless very nice method of using 'new' syntax for both heap and stack-allocated objects. Here's my adaptation of the concept for D (your mileage may vary):
> 
> auto class StackObj;
> class HeapObj;
> 
> StackObj obj0; // Stack-allocated, default-value initialized
> StackObj obj1 = new StackObj(); // Stack-allocated
> HeapObj obj2 = new HeapObj(); // Heap-allocated

Sometimes I'd like to have a class object defined on the stack, sometimes on the heap (without RAII), would I have then to make 2 classes ? Is the D heap allocation syntax already 'frozen' ?


>> Since D is so easy to parse, then perhaps we could have an automatic 'conversion tool' between DMD version X and Y ?
> 
> 
> Hmm, preferably not. Besides, who's going to do that? Walter, Derek and Anders are already busy!

If I weren't busy with my stuff, I'd do it :/ Any volunteers ? ;)



-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d-pu s+: a-->----- C+++$>++++ UL P+ L+ E--- W++ N++ o? K? w++ !O !M V? PS- PE- Y PGP t 5 X? R tv-- b DI- D+ G e>+++ h>++ !r !y
------END GEEK CODE BLOCK------

Tomasz Stachowiak  /+ a.k.a. h3r3tic +/

Niko Korhonen wrote:

> Tom S wrote:
> 
>> Your assumptions are wrong. There is no D project I've ever heard of to have 5M lines of code. As D matures, I expect less and less features being added to the 'stable' compiler branch. I can't speak for Walter, but DMD will probably branch off into the 'beta' / 'development' / 'research' compiler which will adopt new features until it becomes the 'stable' release. People are already starting to do this with GDC.
> 
> 
> But that's not /now/ and given that the language spec/compiler has been in alpha stage for five years, I imagine it's not going to be so in a while.

As I said, I don't believe D to change so much in the following year or so. There aren't any drastic changes planned AFAICS


> Someone might want to start a 5MLoC D project now. It would be pretty great if they could since no one wants to start a 5MLoC project before there are any successful 5MLoC projects...

Ye, but it won't be a 5MLoC project from the beginning. It will have to grow. As it does, DMD will as well :P

Maybe I'm too optimistic about D... But hell... No other language suits my needs :D



-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d-pu s+: a-->----- C+++$>++++ UL P+ L+ E--- W++ N++ o? K? w++ !O !M V? PS- PE- Y PGP t 5 X? R tv-- b DI- D+ G e>+++ h>++ !r !y
------END GEEK CODE BLOCK------

Tomasz Stachowiak  /+ a.k.a. h3r3tic +/