Revised RFC on range design for D2

[Michel Fortin]

On 2008-10-02 01:25:34 -0400, "Bill Baxter" <wbaxter at gmail.com> said:

> Interesting post.  My first thought is what is the formal definition
> for what should be a struct and what should be a class.  That's not a
> cut-and-dried clear decision either.  Either one will generally work.
> I may think X should be a struct and my users may think it should have
> been a class.  We can both be right.  Seems a pretty similar
> situation.

Yes, indeed, often both can be right in many situations. That's a very 
interesting observation in this context.

If this were C++, I'd agree that we'd be better with just one of the 
two because in C++ the *only* difference between a struct and a class 
is syntaxic (if not to say cosmetic): it's the default protection 
attribute which you generally override explicity anyway. I sometime 
find myself want to forward-declare a class from some library (to avoid 
extra includes in the header file) only to have the compiler tell me 
it's a struct, or vice-versa, with an error I could live without. In 
C++, I don't think the addition of the "class" keyword was justified: 
it doesn't add anything useful beside perhaps marketing advantages -- 
because "class" sounds more object-oriented than "struct".

But we are talking about D, where the situation is different.

D classes are well suited for inheritance hierarchies, they can only be 
passed by reference and are always allocated on the heap[^1]. They are 
also easy to synchronize with due to their built-in monitor.

D structs don't have implicit hidden members (monitor, classinfo 
pointer) so you can use them to represent any fixed-length memory 
layout. Structs are easily copied and passed by value too, unlike 
classes, thanks to the lack of inheritance.

Basically, what we have here is two different tools each with different 
attributes. Sometime, they're easily interchangeable, sometime not and 
that's why we need both. But each time you have to choose, your choice 
will (or should) go down to the performance, memory, and flexibility 
implications of each. Choosing what's best will probably involve 
evaluating which approach better fits your needs, and this may even be 
measurable.

Compare this with properties which have exactly the same performance, 
memory, and flexibility implications as regular functions. The only 
difference between a property and a function is the meaning the author 
give to it, and that meaning vary between authors and contexts. Which 
means that from the API user point of view, something being a property 
or a function doesn't mean much... except of course that the user has 
to remember if Singleton.Instance is a property or a function before 
using it, or else suffer some useless compiler errors.


 [^1]: Except scope classes which are allocated on the stack. But 
allocating scope classes on the stack is a mere optimisation which 
happen to be possible when you create a scope object, it doesn't affect 
the semantics of the language at all.


-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/