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
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 reply 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
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.


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);
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.


 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.
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.


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.
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