There is a little documentation about const invariant on the web site. I read
it. And also I read ACCU-functional. Is there more documentation? Like
conference paper or manual. Does Tango book document const? Thank you, Dee Girl

There is a little documentation about const invariant on the web site. I read
it. And also I read ACCU-functional. Is there more documentation? Like
conference paper or manual. Does Tango book document const? Thank you, Dee Girl

At the time of writing, the design of const/invariant didn't seem
finalized so we left it alone. And as far as I know, there are no
papers or manuals on the subject. Nor documentation of the thought
process behind the design.
Sean

There is a little documentation about const invariant on the web site.
I read it. And also I read ACCU-functional. Is there more
documentation? Like conference paper or manual. Does Tango book
document const? Thank you, Dee Girl

At the time of writing, the design of const/invariant didn't seem
finalized so we left it alone. And as far as I know, there are no
papers or manuals on the subject. Nor documentation of the thought
process behind the design.

There is a little documentation about const invariant on the web
site. I read it. And also I read ACCU-functional. Is there more
documentation? Like conference paper or manual. Does Tango book
document const? Thank you, Dee Girl

At the time of writing, the design of const/invariant didn't seem
finalized so we left it alone. And as far as I know, there are no
papers or manuals on the subject. Nor documentation of the thought
process behind the design.

There is a little documentation about const invariant on the web
site. I read it. And also I read ACCU-functional. Is there more
documentation? Like conference paper or manual. Does Tango book
document const? Thank you, Dee Girl

At the time of writing, the design of const/invariant didn't seem
finalized so we left it alone. And as far as I know, there are no
papers or manuals on the subject. Nor documentation of the thought
process behind the design.

Thank you both. Yes I was asking for something more.
I think I understand how const/invariant works by doing test and reading Andrei
ACCU slides and news group. The way const and invariant works is amazing. The
most powerful I seen (better than javari!). But I hope I do not offend anyone
if I say this. The article Here A Const, There A Const
(http://www.digitalmars.com/d/2.0/const.html) I think is very very badly
written. It is even better if the article is removed! It seems to me it has < 0
value.
I now explain why I think is really bad article. Again please not be offended.
It is only opinion.
First it starts by 9 requirements from const. But the requirements are wrong!
They do not explain why both invariant and const are good. Only explain (badly)
how invariant is good. ACCU slides explain clear how const unifies invariant
and mutable data. Const is super type of both. Slides explain also how const
makes possible for imperative world to talk with functional world. It is genius!
But the 9 requirements do not explain well. To me it looked like written by
somebody who does not understand much. A beginner. But Walter wrote compiler so
he understands everything! Maybe he did not have the time to think. I am sorry
I say this. I clearly have bad English. But I can read. And to me it is clear
the article does not present const/invariant well.
Next part is even worse. How Does C++ Const Stack Up? is the title. Makes me
mad! I read about C++ const. Things I knew. Fine. But then when the part ends
what do I see? Scroll bar is at 80%. Most article discuss C++! I can not
believe this. This is article written with attitude bitter and sad about C++.
Does article want to explain D const or bash C++ const? Why fight C++? If you
have nice new suit do you wear old suit under new suit to show how much nice
new suit is??? Only wear new suit and let people appreciate.
The only thing the section say is Walter hates C++ and wants to prove how C++
is bad. He is like 17 years old boy angry on ex girlfriend ^_^ What is good is
only to show that D is good. Because it is good! It is work of genius.
const/invariant are very powerful and will help threads and big programs.
Next part Constness In D is a bit better. But I can not believe. Again an
example from C++!!! Shows how C++ is "bad" again. I feel I want to say Walter
please relax. And the article ends to early because all energy is gone on bash
C++.
I am very sorry I had to say. I think it is best if article is thrown away. It
has hate and bitter. And explains little and also incomplete and incorrect. One
article that only explains how D works is perfect. Maybe Andrei writes from
ACCU slides a article. He writes happy not bitter. Sorry, Dee Girl

Next part is even worse. How Does C++ Const Stack Up? is the title. Makes me
mad! I read about C++ const. Things I knew. Fine. But then when the part ends
what do I see? Scroll bar is at 80%. Most article discuss C++! I can not
believe this. This is article written with attitude bitter and sad about C++.
Does article want to explain D const or bash C++ const? Why fight C++?

I must agree here. Not only about const, but the page always seems to
explain D by comparing it to C by saying "In C you used to do this, but
in D you can do it better like this".
I know D is mostly targeted at people with C++ knowledge. *mostly*. It
would be nice if D was presented as a new, clean language, with complete
explanations and some minor sections comparing it to other languages
(and not always C++). It would say, after some good explanation, "If you
are familiar with C++, this concept maps to...". That way, people that
don't know C++ won't get scared if they see D, or feel the need to learn
C++ before D.
Imagine you enter the Java page and you read "Well... in C++ you have
pointers, in Java you don't. Java only keeps the classes, but with this
syntax. etc." No! Java is a completely new language, with another
perspective in mind. And I think the same about D.
People might also think "Bah, a new effort to write an improved C++".
Instead, they should think "This language is great, I can do a lot of
things, even all of those I could do with C++, and much more easly!".
Same as Dee Girl, no offense intended.

Next part is even worse. How Does C++ Const Stack Up? is the title. Makes me
mad! I read about C++

C++! I can not believe this. This is article written with attitude bitter and
sad about C++. Does article want to
explain D const or bash C++ const? Why fight C++?

I must agree here. Not only about const, but the page always seems to
explain D by comparing it to C by saying "In C you used to do this, but
in D you can do it better like this".

There are a few pages like this. The wordcount/performance page, for
example. I've never really liked them. It's one thing to explain how D
features are different from the features in other languages to avoid
confusion, but another to talk about the problems in other languages
and how D improves on them. It makes D seem like the Democratic
Party of the programming world.

I know D is mostly targeted at people with C++ knowledge. *mostly*. It
would be nice if D was presented as a new, clean language, with complete
explanations and some minor sections comparing it to other languages
(and not always C++). It would say, after some good explanation, "If you
are familiar with C++, this concept maps to...". That way, people that
don't know C++ won't get scared if they see D, or feel the need to learn
C++ before D.

This is why I don't like some of the decisions in D 2.0. Choosing 'enum',
for example, to represent manifest constants. It takes a necessary hack
from C (declaring constants as enum values because it's either that or
#define and #define stinks) and formalizes it as the Right Way to declare
manifest constants. Personally, I think that anonymous enums shouldn't
be allowed at all--formalizing the approach is a disaster. I guess what
I'm saying is that I simply don't accept the argument that D should
support C syntax, even bad C syntax, simply in hopes that it will help
gain acceptance from the C community. Support for C-style function
pointer declarations is another one that should go.

Imagine you enter the Java page and you read "Well... in C++ you have
pointers, in Java you don't. Java only keeps the classes, but with this
syntax. etc." No! Java is a completely new language, with another
perspective in mind. And I think the same about D.
People might also think "Bah, a new effort to write an improved C++".
Instead, they should think "This language is great, I can do a lot of
things, even all of those I could do with C++, and much more easly!".
Same as Dee Girl, no offense intended.

I know D is mostly targeted at people with C++ knowledge. *mostly*. It
would be nice if D was presented as a new, clean language, with complete
explanations and some minor sections comparing it to other languages
(and not always C++). It would say, after some good explanation, "If you
are familiar with C++, this concept maps to...". That way, people that
don't know C++ won't get scared if they see D, or feel the need to learn
C++ before D.

This is why I don't like some of the decisions in D 2.0. Choosing 'enum',
for example, to represent manifest constants. It takes a necessary hack
from C (declaring constants as enum values because it's either that or
#define and #define stinks) and formalizes it as the Right Way to declare
manifest constants. Personally, I think that anonymous enums shouldn't
be allowed at all--formalizing the approach is a disaster. I guess what
I'm saying is that I simply don't accept the argument that D should
support C syntax, even bad C syntax, simply in hopes that it will help
gain acceptance from the C community. Support for C-style function
pointer declarations is another one that should go.

Exactly. Walter's reason is that makes it easier for porting C/C++
applications to D. Isn't it much easier to make a bridge to those
languages instead of expecting the user to port a whole application from
C/C++ to D? Also, even if syntax is kept the same, D's semantics are
already different (so keep the semantic, then keep C/C++?), so I don't
see the benefit of conserving old, obscure syntax.
For example Java allows you to write "int foo[];" instead of "int[]
foo;", just to make C/C++ programmers feel a little more comfortable.
And still, I haven't known a Java programmer that declares arrays that
way, and probably when you teach Java to someone that knows C/C++ you'd
say "See? The type is in one place, the name is in the other, much
clearer!" :-)

For example Java allows you to write "int foo[];" instead of "int[]
foo;", just to make C/C++ programmers feel a little more comfortable.
And still, I haven't known a Java programmer that declares arrays that
way, and probably when you teach Java to someone that knows C/C++ you'd
say "See? The type is in one place, the name is in the other, much
clearer!" :-)

D supports that declaration style too. But the only D code I've ever seen
that uses it is Walter's.
Sean

This is why I don't like some of the decisions in D 2.0. Choosing 'enum',
for example, to represent manifest constants. It takes a necessary hack
from C (declaring constants as enum values because it's either that or
#define and #define stinks) and formalizes it as the Right Way to declare
manifest constants. Personally, I think that anonymous enums shouldn't
be allowed at all--formalizing the approach is a disaster. I guess what
I'm saying is that I simply don't accept the argument that D should
support C syntax, even bad C syntax, simply in hopes that it will help
gain acceptance from the C community.

Step 7 of the 12 step program for converting C++ to D is "global replace
'typedef' with 'alias'". It would not be hard to add a step 13: "global
replace 'enum' with 'manifest'" or 'constant' or some other word that
makes more sense than enum. So I really don't buy any argument that
says "enum" has to stay "enum" for the benefit of C++ folks.
For whatever reason, back in the day Walter realized that it was no
longer appropriate to call D's expanded typedef a typedef and so he gave
it a sensible name that matched its expanded role much better. I'm not
sure what's changed, but for some reason today he seems to have the
attitude of "eh, a word is a word. What's it matter what we call it?".
I have to agree with the pigs in Orwell's Animal farm on this one: "all
words are equal, but some words are more equal than others."
--bb

This is why I don't like some of the decisions in D 2.0. Choosing 'enum',
for example, to represent manifest constants. It takes a necessary hack
from C (declaring constants as enum values because it's either that or
#define and #define stinks) and formalizes it as the Right Way to declare
manifest constants. Personally, I think that anonymous enums shouldn't
be allowed at all--formalizing the approach is a disaster. I guess what
I'm saying is that I simply don't accept the argument that D should
support C syntax, even bad C syntax, simply in hopes that it will help
gain acceptance from the C community.

Step 7 of the 12 step program for converting C++ to D is "global replace
'typedef' with 'alias'". It would not be hard to add a step 13: "global
replace 'enum' with 'manifest'" or 'constant' or some other word that
makes more sense than enum. So I really don't buy any argument that
says "enum" has to stay "enum" for the benefit of C++ folks.
For whatever reason, back in the day Walter realized that it was no
longer appropriate to call D's expanded typedef a typedef and so he gave
it a sensible name that matched its expanded role much better. I'm not
sure what's changed, but for some reason today he seems to have the
attitude of "eh, a word is a word. What's it matter what we call it?".
I have to agree with the pigs in Orwell's Animal farm on this one: "all
words are equal, but some words are more equal than others."

Indeed words are important. Especially when language (English) understanding is
poor ^_^ But I think enum is fine for new comer. Enumerate some constants in a
file, just say enum a = 1, b = "hello", c = 3.14. To me it was always like enum
was limited. Why did all have to be integers and why did all have to be a new
type? Often you care for the value not type. Why did all enum value be part of
a distinct type? I like it there is less restriction.
About documentation. Maybe somebody here could write article about D
const/invariant and put online. People here know very many things. Thank you,
Dee Girl

Walter has said several times that he sucks at explaining things, his
best method is to compare it with another language.

There's a rule in advertising where comparisons may only be made to
the top product in any particular category. I suppose the idea is that
doing so improves competition by preventing the top product from
saying how bad all the others are. However, notice how such
advertisements rarely mention the competing product by name, but
instead generally say "the leading brand." This is because comparisons
with another product implicitly establish that other product as better
than the one being advertised. Otherwise, why bother with a
comparison? When talking about something like a programming
language, any mention of other languages should be limited to
drawing similarities as a way to leverage the reader's knowledge
when discussing difficult concepts. This is a fairly simple rule to
follow, and in my experience it helps to retain the focus of an
explanation.
Sean

There is a little documentation about const invariant on the web
site. I read it. And also I read ACCU-functional. Is there more
documentation? Like conference paper or manual. Does Tango book
document const? Thank you, Dee Girl

finalized so we left it alone. And as far as I know, there are no
papers or manuals on the subject. Nor documentation of the thought
process behind the design.

Thank you both. Yes I was asking for something more.
I think I understand how const/invariant works by doing test and reading
Andrei ACCU slides and news group. The way const and invariant works is
amazing. The most powerful I seen (better than javari!). But I hope I do not
offend anyone if I say this. The article Here A Const, There A Const
(http://www.digitalmars.com/d/2.0/const.html) I think is very very badly
written. It is even better if the article is removed! It seems to me it has < 0
value.

Next part is even worse. How Does C++ Const Stack Up? is the title.
Makes me mad! I read about C++ const. Things I knew. Fine. But then
when the part ends what do I see? Scroll bar is at 80%. Most article
discuss C++! I can not believe this. This is article written with
attitude bitter and sad about C++. Does article want to explain D const
or bash C++ const? Why fight C++?

I must agree here. Not only about const, but the page always seems to
explain D by comparing it to C by saying "In C you used to do this, but
in D you can do it better like this".
I know D is mostly targeted at people with C++ knowledge. *mostly*. It
would be nice if D was presented as a new, clean language, with complete
explanations and some minor sections comparing it to other languages
(and not always C++). It would say, after some good explanation, "If you
are familiar with C++, this concept maps to...". That way, people that
don't know C++ won't get scared if they see D, or feel the need to learn
C++ before D.
Imagine you enter the Java page and you read "Well... in C++ you have
pointers, in Java you don't. Java only keeps the classes, but with this
syntax. etc." No! Java is a completely new language, with another
perspective in mind. And I think the same about D.
People might also think "Bah, a new effort to write an improved C++".
Instead, they should think "This language is great, I can do a lot of
things, even all of those I could do with C++, and much more easly!".
Same as Dee Girl, no offense intended.

Walter has said several times that he sucks at explaining things, his
best method is to compare it with another language. I'm sure he would not
be opposed to having someone write up replacement articles for things.
And even if he was they could go onto the wiki4d.