There are six, seven or more people that wish to do something about
this situation. TDPL is the D2 reference, but few little changes over
its first edition are acceptable if they improve the D language a little.
- Trass3r: asks if the code is ambiguous
- Jonathan M Davis: does't like it and puts const/etc on the right
- Simen kjaeraas thinks it's ambiguous though, and should be
disallowed, or at very least, discouraged.
- Jens Mueller: Preferred style is to write const on the right
- Andrej Mitrovic suggests to use but says it clutters up source code.
- I agree with Jonathan M Davis.
What other people think about this situation? Do you want
const/immutable to be required on the right, or do you prefer the
current situation, or do you prefer some other solution?

I wouldn't say that I *prefer* the current solution, but the current
solution is not so bad that I need it changed.
It works fine, despite being confusing. If it wasn't consistent with
the rest of the attributes, I'd say it was in need of changes, but it
fits within the scheme already outlined.

It's a problem for all of the other attributes as well. I wish it were
disallowed for all of them.
Incidentally, putting it afterward always works. Putting it before
doesn't always work, due to compiler bugs (for example, prefix 'pure'
doesn't work for inner functions).

This "problem" happens because D belongs to the C-family of languages which
puts the return type _before_ the function name.
Languages that don't follow this syntactic convention (some would call it a
mistake) have it very consistent and readable:
attribute funcName inputParams -> outputParams { body }
This is the typical functional language design.
Of course I'm not suggesting to apply such a huge change to D but if I were to
design a brand new language than I would put the return type at the end.
I feel that putting function attributes at the end increases this IMHO bad
design which boils down to a right-to-left programming language.
I'm a native Hebrew speaker and it looks weird to me, so I can't imagine how it
could look right to any left-to-right language native speaker...

This "problem" happens because D belongs to the C-family of languages
which puts the return type _before_ the function name.

It has nothing to do with being a C-family language. C/C++ don't have
this, and the rules are perfectly clear.
It is just unifying two or more unrelated things in one syntax for the
sake of consistency (and compiler complexity?).

This "problem" happens because D belongs to the C-family of languages
which puts the return type _before_ the function name.

It has nothing to do with being a C-family language. C/C++ don't have
this, and the rules are perfectly clear.
It is just unifying two or more unrelated things in one syntax for the
sake of consistency (and compiler complexity?).

Look at this from a "It reads like English" prospective and not from a "I'm an
experienced c++ programmer and therefore already used to this crap"
perspective.
In other words, if you were just starting to learn your first programming
language, what would confuse you less?

Look at this from a "It reads like English" prospective and not from a
"I'm an experienced c++ programmer and therefore already used to this
crap" perspective.
In other words, if you were just starting to learn your first
programming language, what would confuse you less?

If i was starting to learn a language, everything would confuse me.
I know C rules, i learned it with zero hostility to any other language, it
is perfectly natural to me.
Ok you said your natural language is not English, how is that you still
speak it, could be because you just learned its basics?
Which one is the Yoda now? Hebrew or English? Which one is natural? Or i
should ask which one is natural for "you"?

Boy you missed the point by about 2.5 light years..
All I said is that Since D is English based (terminology, etc) it would make
sense to follow a more English like word ordering in order to make the learning
curve less steep. It obviously doesn't apply to someone who's already ahead of
the learning curse such as yourself.
There are Hebrew (and many other languages..) based programming languages out
there and analogously it would make sense to strive for a Hebrew look and feel
for those as well.
Your argument boils down to something like "Who needs cars? I'm riding my horse
Johnny since childhood..Feels natural to me" This has no relevance to an
objective comparison between a car and a horse.

This can go forever as long as one of us resist to simple reasoning and
analogy,
and the other one has the energy to continue.

All I said is that Since D is English based (terminology, etc) it would
make sense to follow a more English like word ordering in order to make
the learning curve less steep.

We are not teaching PL to monkeys, though i am not sure if they would find
this an issue.
Math is another language and it is quite flexible, I don't see people that
left to right oriented use "one add two equal three",
while the others use "three equal one add two" and flaming the others.
After you learn the damn rule (which is in the basics of any language),
both equally natural.

Your argument boils down to something like "Who needs cars? I'm riding
my horse Johnny since childhood..Feels natural to me" This has no
relevance to an objective comparison between a car and a horse.

No.
And i can't get better than that so this discussion for me now pointless.

No one is flaming here, this is just an academic discussion and I'm sorry if
you took offense.
The subject of this discussion is the learning curve and *not* about teaching
monkey to program.
I'm simply stating that each language (programming or otherwise) has a
learning curve which can be statistically measured for an average human being.
Fact is that for the _same_ person it takes more time to learn C++ compared to
other languages. So I'm *not* talking about how smart you need to be in order
to learn C but rather how long will it take you to learn different programming
languages and comparing _the_languages_ based on that metric.
Math is actually a very good example: It takes many years to learn math (from
first class to university) and therefore it has a very steep learning curve.
Here's another perspective:
A professor that teaches introduction to CS in first semester to students that
never programmed before needs to choose a programing language. One of the
criteria for choosing which language to use is of course the learning curve.
I'm sure you know that not all universities choose c/c++ for this. In fact, I
know of several universities that use scheme as that first programming language.

Here's another perspective:
A professor that teaches introduction to CS in first semester to
students that never programmed before needs to choose a programing
language. One of the criteria for choosing which language to use is of
course the learning curve.
I'm sure you know that not all universities choose c/c++ for this. In
fact, I know of several universities that use scheme as that first
programming language.

C++ is complex, it is obvious why it is harder to learn.
Other languages don't have this mostly because they are not as powerful (i
don't think i need to explain this).
And this is what i mean, the reason its complexity, not the building
blocks we are talking about. (again, i don't believe this syntax has
anything to do with C++ being complex).

C++ is indeed complex and one of the reasons is its syntax (believe it or not).
There was even an academic project to re-syntax C++ with the exact same
semantics.
Of course it's not the only cause of complexity in C++ but it is definitely one
of the main ones.
C++'s complexity has nothing to do with it's "power". D is as powerful and is
less complex to use which is why we are here and not on the C++ dev mailing
list. for example, D's classes/structs are way better than equivalent c++ code.

C++ is indeed complex and one of the reasons is its syntax (believe it
or not). There was even an academic project to re-syntax C++ with the
exact same semantics.
Of course it's not the only cause of complexity in C++ but it is
definitely one of the main ones.

If that is the case, you are probably right, but still i can't quite grasp
it.

C++'s complexity has nothing to do with it's "power". D is as powerful
and is less complex to use which is why we are here and not on the C++
dev mailing list. for example, D's classes/structs are way better than
equivalent c++ code.

Well if you think the complexity has nothing to do with power, how can you
use D as a counterexample? :)

"power" is a very subjective and problematic measure. We're discussing Turing
complete languages and nothing prevents me from implementing a
compiler/interpreter from one language to another thus gaining its "power".
What we really want to talk is ease of expressiveness.
C++ is more complex than D which means its harder to express oneself in c++.
The difference is not that you can express something in one language but not in
another (Both are Turing complete) but rather the *difficulty* of expressing
the same thing in both languages.
That difficulty makes for a steeper learning curve.

Look at this from a "It reads like English" prospective and not from a
"I'm an experienced c++ programmer and therefore already used to this
crap" perspective.
In other words, if you were just starting to learn your first
programming language, what would confuse you less?

If i was starting to learn a language, everything would confuse me.
I know C rules, i learned it with zero hostility to any other language, it
is perfectly natural to me.
Ok you said your natural language is not English, how is that you still
speak it, could be because you just learned its basics?
Which one is the Yoda now? Hebrew or English? Which one is natural? Or i
should ask which one is natural for "you"?

This can go forever as long as one of us resist to simple reasoning and
analogy,
and the other one has the energy to continue.

All I said is that Since D is English based (terminology, etc) it would
make sense to follow a more English like word ordering in order to make
the learning curve less steep.

We are not teaching PL to monkeys, though i am not sure if they would find
this an issue.
Math is another language and it is quite flexible, I don't see people that
left to right oriented use "one add two equal three",
while the others use "three equal one add two" and flaming the others.
After you learn the damn rule (which is in the basics of any language),
both equally natural.

Your argument boils down to something like "Who needs cars? I'm riding
my horse Johnny since childhood..Feels natural to me" This has no
relevance to an objective comparison between a car and a horse.

No.
And i can't get better than that so this discussion for me now pointless.

Here's another perspective:
A professor that teaches introduction to CS in first semester to
students that never programmed before needs to choose a programing
language. One of the criteria for choosing which language to use is of
course the learning curve.
I'm sure you know that not all universities choose c/c++ for this. In
fact, I know of several universities that use scheme as that first
programming language.

C++ is complex, it is obvious why it is harder to learn.
Other languages don't have this mostly because they are not as powerful (i
don't think i need to explain this).
And this is what i mean, the reason its complexity, not the building
blocks we are talking about. (again, i don't believe this syntax has
anything to do with C++ being complex).

C++ is indeed complex and one of the reasons is its syntax (believe it
or not). There was even an academic project to re-syntax C++ with the
exact same semantics.
Of course it's not the only cause of complexity in C++ but it is
definitely one of the main ones.

If that is the case, you are probably right, but still i can't quite grasp
it.

C++'s complexity has nothing to do with it's "power". D is as powerful
and is less complex to use which is why we are here and not on the C++
dev mailing list. for example, D's classes/structs are way better than
equivalent c++ code.

Well if you think the complexity has nothing to do with power, how can you
use D as a counterexample? :)

This "problem" happens because D belongs to the C-family of languages which
puts the return type _before_ the function name.
Languages that don't follow this syntactic convention (some would call it a
mistake) have it very consistent and readable:
attribute funcName inputParams -> outputParams { body }
This is the typical functional language design.

It is arguably more consistent to have the return type come first, as
in variable declarations:
int a = 4;
int foo() { return 5; }
Both "foo()" and "a" are now of type int.
Torarin