www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Please stop polluting D 2.0 with C/C++ programmer assumptions.

reply Tomas Lindquist Olsen <tomas famolsen.dk> writes:
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
Nov 29 2007
next sibling parent reply "Craig Black" <cblack ara.com> writes:
"Tomas Lindquist Olsen" <tomas famolsen.dk> wrote in message 
news:fimmh9$him$1 digitalmars.com...
 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.
 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);
 }

What is this about anyway? I don't understand it's significance.
 int array[1][2][3];

 ... just reminds me that actually it's not.

 My 2 cents!

 - Tomas Lindquist Olsen 

Nov 29 2007
next sibling parent reply Tomas Lindquist Olsen <tomas famolsen.dk> writes:
Craig Black wrote:
 "Tomas Lindquist Olsen" <tomas famolsen.dk> wrote in message 
 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.

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.

Very confusing IMHO.
 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);
 }

What is this about anyway? I don't understand it's significance.

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.
Nov 29 2007
parent Dejan Lekic <dejan.lekic gmail.com> writes:
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?
Nov 29 2007
prev sibling parent Jan Claeys <digitalmars janc.be> writes:
Op Fri, 30 Nov 2007 02:14:09 +0000, schreef Dejan Lekic:

 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
Nov 29 2007
prev sibling next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Tomas Lindquist Olsen wrote:
 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.
Nov 29 2007
next sibling parent reply Jan Claeys <digitalmars janc.be> writes:
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... -- JanC
Nov 29 2007
parent Walter Bright <newshound1 digitalmars.com> writes:
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.
Nov 30 2007
prev sibling parent reply "Aziz K." <aziz.kerim gmail.com> writes:
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.

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);
Dec 01 2007
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
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
Dec 01 2007
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
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.

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.
Dec 02 2007
parent "Aziz K." <aziz.kerim gmail.com> writes:
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.

"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.
Dec 03 2007
prev sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Tomas Lindquist Olsen wrote:
 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
Nov 29 2007
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Bill Baxter wrote:
 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.

It's not possible to design a language that is free of conflicting goals :-)
Nov 29 2007
parent Dan <murpsoft hotmail.com> writes:
Walter Bright Wrote:

 Bill Baxter wrote:
 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.

It's not possible to design a language that is free of conflicting goals :-)

Read again. It's not a contradiction. No other opinions on this subject. I didn't read it. I'm just passing through.
Nov 29 2007