At the risk of appearing ignorant, I don't know everything about D.
However in D I have noticed the following.

It is a policy decision in D that a class is ALWAYS on the heap and passed
by REFERENCE. (I know there is a keyword to put a class object on the stack
but this is not facile and needing a workaround is poor language design).
This is effectively FORCED Java.
A D struct is on the stack and is NOT a class and has NO inheritance.

I have issues with this philosophy.

It seems FUNDAMENTAL to me that a programmer needs both stack and heap
objects and should KNOW when to use each and should ALWAYS have a choice.

ALL struct VARIABLES when declared are initialised to their .init value.
Just in case a programmer "forgets" to initialize them.
This is like using a sledgehammer instead of a scalpel.
Could you answer me WHY??
ALL classes when declared are instantiated on the heap
and their constructor called. Again I ask WHY??

Why can't the programmer have the freedom to build his own objects
when he wants to with the compiler advising of errors ?

Of course I have more to say about this but I need answers to these questions
to proceed.

On Friday, 14 September 2012 at 22:18:57 UTC, David Currie:

> Could you answer me WHY??

Take a look at the D FAQ, maybe some of your questions are answered there, this will save some time to people here.

And your questions that are missing in the FAQ are better added there, because they are quite basic and common.

The keyword "scoped" you probably refer to is deprecated when it's used to allocate class instances on the stack. Currently there is emplace() to allocate class instances in-place. emplace() is not perfect and it's not much "safe", but maybe it will become good enough.

Regarding the missing struct inheritance, take a look at "alias this" (and template mixins), to compose struct behaviors. It's not inheritance, but often it's quite handy.

Bye,
bearophile

David Currie wrote:
> At the risk of appearing ignorant, I don't know everything about D.
> However in D I have noticed the following.
>
> It is a policy decision in D that a class is ALWAYS on the heap and passed
> by REFERENCE. (I know there is a keyword to put a class object on the stack
> but this is not facile and needing a workaround is poor language design).
> This is effectively FORCED Java.
> A D struct is on the stack and is NOT a class and has NO inheritance.
>
> I have issues with this philosophy.

I'm not comfortable with it either. But as you know, there is scoped!MyClass library solution. One thing I miss is a Scoped!MyClass struct so I could embed my classes into structs without using heap. Then a construct() function could be used on it to init members and to call constructors (emplace() may be used to do that).

> ALL struct VARIABLES when declared are initialised to their .init value.
> Just in case a programmer "forgets" to initialize them.
> This is like using a sledgehammer instead of a scalpel.
> Could you answer me WHY??

For safety and for easier generic programming. You can always disable automatic initialization by using void initializer.

> ALL classes when declared are instantiated on the heap
> and their constructor called. Again I ask WHY??

This is wrong. Classes when declared are initialized to null (unless void initializer is used). They're not automatically instantiated. You must explicitly instantiate them using _new_ operator.

On Saturday, September 15, 2012 00:19:07 David Currie wrote:
> At the risk of appearing ignorant, I don't know everything about
> D.
> However in D I have noticed the following.
> 
> It is a policy decision in D that a class is ALWAYS on the heap
> and passed
> by REFERENCE. (I know there is a keyword to put a class object on
> the stack
> but this is not facile and needing a workaround is poor language
> design).
> This is effectively FORCED Java.
> A D struct is on the stack and is NOT a class and has NO
> inheritance.
> 
> I have issues with this philosophy.
> 
> It seems FUNDAMENTAL to me that a programmer needs both stack and
> heap
> objects and should KNOW when to use each and should ALWAYS have a
> choice.
> 
> ALL struct VARIABLES when declared are initialised to their .init
> value.
> Just in case a programmer "forgets" to initialize them.
> This is like using a sledgehammer instead of a scalpel.
> Could you answer me WHY??
> ALL classes when declared are instantiated on the heap
> and their constructor called. Again I ask WHY??
> 
> Why can't the programmer have the freedom to build his own objects when he wants to with the compiler advising of errors ?
> 
> Of course I have more to say about this but I need answers to
> these questions
> to proceed.

Classes are polymorphic. They have inheritance and virtual functions. Polymorphism makes no sense with a variable on the stack. Having inheritance with objects on the stack risks object slicing ( http://en.wikipedia.org/wiki/Object_slicing ). Sure, you _can_ have a polymorphic object which is on the stack (which is why C++ allows classes on the stack and why D has std.typecons.scoped), but it's the sort of thing that tends to be begging for bugs.

The designers of D decided that it's was cleaner and safer to separate objects which were meant to be polymorphic and those which were meant to be non- polymorphic (as is often considered best practice in C++), and since having polymorphic objects means that you're not using their polymorphism and having them on the stack can be dangerous, it was decided to follow Java and C#'s example and make all classes into reference types which live on the heap (though unlike Java and C#, we _can_ put such objects on the stack if we really want to via std.typecons.scoped). But unlike Java and C#, we have structs which are full-on objects with constructors and destructors and are the same in classes in pretty much every way except that they have no polymorphism and normally go on the stack.

The result is safer than what C++ has but is still very powerful. And since it's arguably best practice not to put objects which are meant to use polymorphism on the stack in C++ anyway, it's not even really restricting you from much in comparison to C++ (and std.typecons.scoped makes it possible to put classes on the stack if you really want to, making the restrictions even less).

You can like it or not, but separating structs and classes and making classes reference types on the heap is a design decision based on the best practices and common bugs in C++. And it works very well. Upon occasion, it can be limiting (hence why we have std.typecons.scoped), but I don't think that you're going to find very many D programmers who think that the separation of structs and classes was a bad idea.

- Jonathan M Davis

On Saturday, September 15, 2012 03:58:50 Jonathan M Davis wrote:
> You can like it or not, but separating structs and classes and making classes reference types on the heap is a design decision based on the best practices and common bugs in C++. And it works very well. Upon occasion, it can be limiting (hence why we have std.typecons.scoped), but I don't think that you're going to find very many D programmers who think that the separation of structs and classes was a bad idea.

You should keep in mind that D's general philosophy is to make the defaults safe but to allow you to do more powerful, dangerous stuff when you need to. The result is that it's just as powerful as C++ when you need it to be but that it's a lot safer in general, meaning that you're going to have fewer bugs in your code.

A prime example of this is the fact that all variables are default- initialized. This way, you never have problems with variables being initialized to garbage, which can cause non-deterministic, hard-to-track-down bugs. But if you really need the extra speed of a variable not being initialized when it's declared, then you can initialize it to void. e.g.

int i = void;

This makes it so that code is far less error-prone in general while still allowing you to have the same down to the metal speed that C/C++ offers when you really need it. And it's that philosophy which governs a lot of D's features.

- Jonathan M Davis

On Sat, 15 Sep 2012 13:05:47 +0200, Jonathan M Davis <jmdavisProg@gmx.com> wrote:

> if you really need the extra speed of a variable not being
> initialized when it's declared, then you can initialize it to void.

It's also worth noting that default-initialization may be elided when
the optimizer finds that the variable is definitely initialized before
use later in the code.

-- 
Simen

On Saturday, 15 September 2012 at 10:58:07 UTC, Jonathan M Davis wrote:
> Classes are polymorphic. They have inheritance and virtual functions.
> Polymorphism makes no sense with a variable on the stack. Having inheritance
> with objects on the stack risks object slicing (
> http://en.wikipedia.org/wiki/Object_slicing ). Sure, you _can_ have a
> polymorphic object which is on the stack (which is why C++ allows classes on
> the stack and why D has std.typecons.scoped), but it's the sort of thing that
> tends to be begging for bugs.
>
> The designers of D decided that it's was cleaner and safer to separate objects
> which were meant to be polymorphic and those which were meant to be non-
> polymorphic (as is often considered best practice in C++), and since having
> polymorphic objects means that you're not using their polymorphism and having
> them on the stack can be dangerous, it was decided to follow Java and C#'s
> example and make all classes into reference types which live on the heap
> (though unlike Java and C#, we _can_ put such objects on the stack if we
> really want to via std.typecons.scoped). But unlike Java and C#, we have
> structs which are full-on objects with constructors and destructors and are
> the same in classes in pretty much every way except that they have no
> polymorphism and normally go on the stack.
>
> The result is safer than what C++ has but is still very powerful. And since
> it's arguably best practice not to put objects which are meant to use
> polymorphism on the stack in C++ anyway, it's not even really restricting you
> from much in comparison to C++ (and std.typecons.scoped makes it possible to
> put classes on the stack if you really want to, making the restrictions even
> less).
>
> You can like it or not, but separating structs and classes and making classes
> reference types on the heap is a design decision based on the best practices
> and common bugs in C++. And it works very well. Upon occasion, it can be
> limiting (hence why we have std.typecons.scoped), but I don't think that
> you're going to find very many D programmers who think that the separation of
> structs and classes was a bad idea.
>
> You should keep in mind that D's general philosophy is to make the defaults
> safe but to allow you to do more powerful, dangerous stuff when you need to.
> The result is that it's just as powerful as C++ when you need it to be but
> that it's a lot safer in general, meaning that you're going to have fewer bugs
> in your code.
>
> A prime example of this is the fact that all variables are default-
> initialized. This way, you never have problems with variables being
> initialized to garbage, which can cause non-deterministic, hard-to-track-down
> bugs. But if you really need the extra speed of a variable not being
> initialized when it's declared, then you can initialize it to void. e.g.
>
> int i = void;
>
> This makes it so that code is far less error-prone in general while still
> allowing you to have the same down to the metal speed that C/C++ offers when
> you really need it. And it's that philosophy which governs a lot of D's
> features.
>
> - Jonathan M Davis

I have SO MANY issues with the above statements I wouldnt know where to start.
I have been attempting to raise these (and many related) issues before.

Firstly, responding in particular to Jonathan M Davis (albeit rather late),
I concede your comments are made in good faith and are even ACCURATE.
My problem is that they are INSUFFICIENT.

I haven't announced to regular viewers that I STARTED these issues by writing direct to Walter (twice) that I had some language extension IDEAS I thought would be VALUABLE to ALL. Such Ideas would make a welcome addition to ANY language but for me D comes closest.
(A C like language with NO header files alone is worth 50%).
Naturally all he could really do was to send me along to the forums.

However, I can see that if I am to receive the usual polite refusal,
and I really wish to make a POINT I'd better be armed.

I would need to be able to speak your language (learn D)
before I should expect you to speak mine (implement My Ideas).
I can see here that my best bet is to learn D.

Can one learn it all online?  What is the best D book?

On Tue, 18 Sep 2012 01:07:43 -0400, David Currie <curriedr@iinet.net.au> wrote:

> On Saturday, 15 September 2012 at 10:58:07 UTC, Jonathan M Davis wrote:
>
> I haven't announced to regular viewers that I STARTED these issues by writing direct to Walter (twice) that I had some language extension IDEAS I thought would be VALUABLE to ALL. Such Ideas would make a welcome addition to ANY language but for me D comes closest.
> (A C like language with NO header files alone is worth 50%).
> Naturally all he could really do was to send me along to the forums.
>
> However, I can see that if I am to receive the usual polite refusal,
> and I really wish to make a POINT I'd better be armed.
>
> I would need to be able to speak your language (learn D)
> before I should expect you to speak mine (implement My Ideas).
> I can see here that my best bet is to learn D.
>
> Can one learn it all online?  What is the best D book?

"The D Programming Language" is the official book for D, written by one of the main contributors, Andrei Alexandrescu.

http://www.amazon.com/The-Programming-Language-Andrei-Alexandrescu/dp/0321635361/ref=sr_1_1?ie=UTF8&qid=1347967853&sr=8-1&keywords=the+d+programming+language

Note, this only covers the core language, and a bit of the library.  The standard library is very much in flux, and so writing a book at this point would be a bit premature.  If you want to learn the language as quickly as possible, this is probably the best way, the book is very good.  I should note that many of the concepts in the book are not yet implemented, but the book is considered to be more official than the reference implementation.  In other words, TDPL is what the language *should* be on official release.  So you may run into several features that are described in the book, but don't work.

You can, of course, learn very very much by reading the documentation, online at dlang.org.  The documentation is more of a specification, but it should be quite possible to learn it that way (I did).  The dlang.org documentation more closely follows the reference compiler, and is in fact, released along with the compiler.

I will warn you, that there will very likely be no point at which you will be able to convince Walter to abandon his core beliefs and fundamentally modify D.  There are certainly areas which are not yet set in stone, and in the library is probably the best place you will be able to influence the language.  But I would advise you right now, do not expect to *ever* see D change it's policy towards class allocation on the stack.

As you alluded to, we already have a way to allocate classes on the stack, and that way is being deprecated, due to the dangers it poses.  That should give you a clue that the language designers are not really keen on introducing something similar, even if you feel it is better (I have first-hand experience with this, try convincing Walter that we need tail-const...).  It's like trying to sell an iPhone to someone who had one and hated it.  "Yeah, but this iPhone is even better than the last one!" doesn't really cut it (I'm looking at you, Nick :)

I don't want to sound harsh, or build a strawman for your ideas (of which you likely have many that haven't been expressed here), but if they are of the same grain, you will likely be disappointed.

However, I am fairly confident that you will enjoy D, even if it doesn't do things exactly the way you want.  And D might even be able to do things the way you want, there are some incredibly smart people here who can use D's immense code generation power to build types that do exactly what you want without adding language features.

There are so many things I wish D did differently, but it is still far and above better than any other language I use.  And I also hope that you can contribute ideas that *are* able to be included in the language.  I think everyone here is interested in improving D!

Hope this helps.

-Steve

On 09/18/2012 07:07 AM, David Currie wrote:
> [ALL CAPS]

It does not matter who is the loudest guy in the room. If you have a
point to make, just make it. (Stating the conclusion is not making a
point. Skipping forward and predicting polite refusal does not help.)

Most of the statements in the OP are inaccurate.

The best way to get in touch with the language is by reading the online
documentation and by experimenting with the compiler (prepare for some
bugs and unspecified corner cases). Reading the newsgroup helps too.

Usually it is best to double-check any claims about the language
expressed online, using the reference implementation.

On Tuesday, 18 September 2012 at 18:42:33 UTC, Timon Gehr wrote:
> On 09/18/2012 07:07 AM, David Currie wrote:
>> [ALL CAPS]
>
> It does not matter who is the loudest guy in the room. If you have a
> point to make, just make it. (Stating the conclusion is not making a
> point. Skipping forward and predicting polite refusal does not help.)
>
> Most of the statements in the OP are inaccurate.
>
> The best way to get in touch with the language is by reading the online
> documentation and by experimenting with the compiler (prepare for some
> bugs and unspecified corner cases). Reading the newsgroup helps too.
>
> Usually it is best to double-check any claims about the language
> expressed online, using the reference implementation.

Apologies for SHOUTING. I am unfamiliar with forum syntax and etiquette
I merely wished *stressing* some words.

What is OP and perhaps why are most statements inaccurate?
How does one get to the newsgroups. I only got here because Walter gave
me a link. I would gratefully welcome links.