On Wednesday, 18 June 2014 at 03:36:54 UTC, Jesse Phillips wrote:
On Wednesday, 18 June 2014 at 02:26:25 UTC, Sebastian Unger
wrote:
If so, what was the rationale to not include a feature in D
that has been used with great success in other languages?
D had 3 other const systems prior to its current state. This
system provided the needed guarantees with the least
complexity. Head-const would have added too much complexity for
the benefit (almost nothing).
Well, I think there is definitely benefit if you can tell the
compiler that you don't mean to modify something and then the
compiler will check this for you.
Just think bugs like
if (a = 3) ...
instead of
if (a == 3) ...
Not sure if this particular bug is possible in D, but that's
beside the point.
I'd stronly argue for D getting that feature. If I can't
express some of the most basic constructs in OOD in D
Well, I always thought C++'s const was as described in this SO
response http://stackoverflow.com/a/2736231/34435
That link has one problem: It states that const means different
things to different people. That's not quite correct. There are
different things I want to be const in different situations and I
need my language to be able to express ALL of these with ease.
Sometimes I want an object in flash memory and immutable is
needed. Sometimes I want to pass it around between threads and
transitive const is really useful. And sometimes I want a
relationship to be const and D can't express that. People are
just used to expressing these different conccepts using different
mechanisms depending on the language they're using. But for D to
be truly superior to other languages it needs to be able to
express at least the same as these other languages.
Basically what D is saying is, that every reference to an object
from another object is a 'contains' relationship where transitive
const makes sense. But that's simply not the real world of OOSD.
In the real world there are many different types of relationships.
And yes, sometimes I want an object to be located in ROM but have
a reference to another object in RAM that I can modify. No way to
express this in D.
"means this reference cannot be used to modify the instance"
The problem being C++ did not enforce this rule and people
started abusing it. And now they can't live without it.
Hang on, that's not entirely true. True, you could cast away
const (if that is what you are referring to), but you can do the
same in D. Other than that C++ (and in fact even C) enforced
constness perfectly well: Without a cast it is not possible to
modify that which is declared const. True, C(++) could not
express the concept of immutable to the point where the compiler
can assume an object is not changing as D can. But C(++) could
easily enough express const relationships which D cannot express.
Now, in the 19 years as a software developer, I have yet to come
across a case where the (admittedly weaker) guarantees of C and
C++ constness are simply not enough to express what I want to
achieve. On the other hand, after beginning a small project as a
test to see how D holds up, I came across the fact that D simply
cannot express constant object relationships in a matter of hours.
So from my experience it is clear which concept is the more
important (to the projects I've been working on at least). But
both are valid!
So again, I believe, if D wants to play any role in major OO
software design and development, it will need to step up its
game. Especially in view of C++11 having addressed a number of
the issues in C++ that I would have chosen D over C++ for.
Cheers,
Seb
