Hi Walter (and NG).
I've been trying to follow the NG lately (which is fairly time consuming) and I
really only
have one thing to say:
1) Remove the support for C style declaration.
2) Make suffix const the only way to declare a const method.
3) Stop assuming C++ programmers wants D to feel like C++.
4) Please...
This stuff is killing me! For the first time in D2.0 history I'm feeling it's
on the right
track, but things like:
class C {
const const int[] func();
}
class ClassInfo {
void (*classInvariant)(Object);
}
int array[1][2][3];
... just reminds me that actually it's not.
My 2 cents!
- Tomas Lindquist Olsen

Hi Walter (and NG).
I've been trying to follow the NG lately (which is fairly time consuming)
and I really only have one thing to say:
1) Remove the support for C style declaration.

If you are talking about C style declaration for array types I think D 1.0
has this feature as well. I think Walter wants it to be friendlier for C++
folks so there will hopefully be more converts. It does clutter the
language a little but it's not a big deal IMO.

2) Make suffix const the only way to declare a const method.

I don't know why Walter allows prefix const for methods. It is a little
confusing IMO.

If you are talking about C style declaration for array types I think D 1.0
has this feature as well. I think Walter wants it to be friendlier for C++
folks so there will hopefully be more converts. It does clutter the
language a little but it's not a big deal IMO.

Also function pointer declarations. Yes I know this is already in D 1.0, but
that doesn't make
it right IMHO.

2) Make suffix const the only way to declare a const method.

I don't know why Walter allows prefix const for methods. It is a little
confusing IMO.

It was just some code examples of things I really dislike.
IMHO all this stuff just complicate the language (think frontend implementors).
Also it means
that probably someone will use it. Can't help but feel sorry for the D coders
reading that code
who do *not* come from a C/C++ background.

Do I understand this thread correctly? - A frontend implementor is
whining for language specification to be changed because implementing a
frontend for the current language spec. is more difficult?

Considering that Walter often mentions the complexity of implementing
certain C++ constructs correctly as a rationale for certain decisions in
D's design, I suppose that would be a good reason to whine about D2's
proposed design too... ;-)
--
JanC

I've been trying to follow the NG lately (which is fairly time
consuming) and I really only have one thing to say:
1) Remove the support for C style declaration.
2) Make suffix const the only way to declare a const method.
3) Stop assuming C++ programmers wants D to feel like C++.
4) Please...
This stuff is killing me! For the first time in D2.0 history I'm feeling
it's on the right track, but things like:
class C {
const const int[] func();
}
class ClassInfo {
void (*classInvariant)(Object);
}
int array[1][2][3];
... just reminds me that actually it's not.
My 2 cents!

1) The C style array declarations have been in D since day 1 :-), they
aren't a problem to support in the compiler, and are essentially under
the radar. And I know from experience that they really do help in
translating C code to D.
2) I had this implemented for a while. The problem is, it sucks. Take a
look at Object:
class Object
{
void print();
string toString();
hash_t toHash();
int opCmp(Object o);
int opEquals(Object o);
}
All these member functions need to be const. Would you rather write:
class Object
{
void print() const;
string toString() const;
hash_t toHash() const;
int opCmp(Object o) const;
int opEquals(Object o) const;
}
or:
class Object
{
const:
void print();
string toString();
hash_t toHash();
int opCmp(Object o);
int opEquals(Object o);
}
I'm pretty confident the latter style is much easier on the eyes. It
also makes for a very visually appealing way to segregate the const
member functions from the mutating ones. If you've ever looked at a
complex C++ class, all the const's sprinkled liberally through the
declarations just make for an ugly, confusing mish-mash.
3) Half of D programmers come from C++. Similarities between the two
make for much quicker adaption to D.

3) Half of D programmers come from C++. Similarities between the two
make for much quicker adaption to D.

But it also means that more confusion is likely to happen about those
things that are slightly-different-but-almost-the-same...

Which is why I avoid making changes that cause silent crashing
differences in behavior. Changes that result in compile errors if used
in a C++ manner are ok.
For example:
float f = 1/2;
If I did as suggested and make this the same as (float f = 0.5;), I
would silently break code that a C++ programmer may naturally write.

1) The C style array declarations have been in D since day 1 :-), they
aren't a problem to support in the compiler, and are essentially under
the radar. And I know from experience that they really do help in
translating C code to D.

C style array decls are easy to parse. C style function pointers were a
bit harder to parse though. I think the main problem with C style function
pointers is that they make the D grammar ambiguous. For example:
void foo() {
// A pointer to a function taking an integer and returning 'some_type'.
some_type (*p_func)(int);
// In the following case precedence must be given to a CallExpression.
something(*p); // 'something' may be a function/method or an object
having opCall overloaded.
// An actual example from my D Lexer:
isascii(*p) || decodeUTF8();
}
// Things are a bit different outside of the function scope.
// As functions can't be called at module scope we can ignore
CallExpressions:
// A pointer to a function taking no parameters and returning 'something'.
something(*p);

Generally having two different but similar syntaxes to express the same thing
is a quite bad thing for a programming language, because they add complexity to
the language, the parser, make the manuals longer, it's confusing if you read
code written by other people that keeps mixing the two, etc.
Regarding the C-style array declarations, I don't like them, but I think they
don't damage D much.
The C-style function pointers aren't readable enough, and D has already a
better (but probably too much long, "fun" or "func" or "def" or something like
that is shorter than function) syntax, and I think the old syntax may be
dropped...
Bye,
bearophile

1) The C style array declarations have been in D since day 1 :-), they
aren't a problem to support in the compiler, and are essentially under
the radar. And I know from experience that they really do help in
translating C code to D.

C style array decls are easy to parse. C style function pointers were a
bit harder to parse though. I think the main problem with C style
function pointers is that they make the D grammar ambiguous.

The rule to resolve "is it a type or an expression" is that if it parses
as a type, it is a type.

The rule to resolve "is it a type or an expression" is that if it parses
as a type, it is a type.

Yes, I know this is the general rule. Isn't it true that
"Identifier(*Identifier)" could be parsed as a function pointer
declaration? But an exception must be made, and precedence must be given
to an expression instead of a declaration.

Hi Walter (and NG).
I've been trying to follow the NG lately (which is fairly time
consuming) and I really only have one thing to say:
1) Remove the support for C style declaration.
2) Make suffix const the only way to declare a const method.
3) Stop assuming C++ programmers wants D to feel like C++.
4) Please...
This stuff is killing me! For the first time in D2.0 history I'm feeling
it's on the right track, but things like:
class C {
const const int[] func();
}

That one is a syntax error. Should be
class C {
const const(int[]) func();
}
But I don't understand the logic of 3)"don't assume C++ folks want D to
look like C++" and 2)"make suffix const the only way [like C++]". It
seems like a mild contradiction.
--bb