View mode: basic / threaded / horizontal-split · Log in · Help
December 14, 2005
Re: A safer/better C++?
"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.
December 14, 2005
Re: A safer/better C++?
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
December 14, 2005
Re: A safer/better C++?
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 +/
December 14, 2005
Re: A safer/better C++?
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
December 14, 2005
Re: A safer/better C++?
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
December 14, 2005
Re: A safer/better C++?
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 +/
December 14, 2005
Re: A safer/better C++?
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
December 14, 2005
Re: A safer/better C++?
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
December 14, 2005
Re: A safer/better C++?
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 +/
December 14, 2005
Re: A safer/better C++?
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 +/
3 4 5 6 7 8 9 10 11
Top | Discussion index | About this forum | D home