Jan Claeys wrote:
> Op Thu, 29 Nov 2007 12:34:01 -0800, schreef Walter Bright:
> 
>> 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.

Walter Bright wrote:
> 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);

Aziz K. Wrote:
> C style array decls are easy to parse. C style function pointers were a bit harder to parse though.

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

Aziz K. wrote:
> Walter Bright wrote:
>> 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.

Walter Bright wrote:
> 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.