www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - C++

reply David Medlock <noone nowhere.com> writes:
Its adherents rarely surprise me anymore.

Read my post on LTU and snk_kid's response:
http://lambda-the-ultimate.org/node/1583#comment-19266

I am not trying to single him out, but the responses are pretty common 
in my (arguably anectdotal) experience.

C++ is getting X in next version...
Using boost/somelib we can do X...
GC/Feature N will be great for C++ but for language Y its slow...

Sigh.

Its funny when people bring up libraries to make their points.
Templates in C++ are slow to compile and bloated in my exposure to them.
And even with all those libraries can you finally type:
string s = "Hello" + " World";

After using D for a while now, i almost _despise_ C++.
I think I would rather just use (python & C) instead of going back.

Walter you have your work cut out for you.
Like most things in IT, the human/political issues outweigh the 
technical ones.

Sorry for the rant.
-DavidM
Jun 29 2006
next sibling parent reply Sean Kelly <sean f4.ca> writes:
David Medlock wrote:

 Its adherents rarely surprise me anymore.
 
 Read my post on LTU and snk_kid's response:
 http://lambda-the-ultimate.org/node/1583#comment-19266
 
 I am not trying to single him out, but the responses are pretty common 
 in my (arguably anectdotal) experience.
 
 C++ is getting X in next version...
 Using boost/somelib we can do X...
 GC/Feature N will be great for C++ but for language Y its slow...
 
 Sigh.
 
 Its funny when people bring up libraries to make their points.



Not for C++.  For better or worse, a primary design goal of C++ was keep 
as much as possible out of the language definition by supporting user 
defined types that are indistinguishable from built-in types.  So a 
valid comparison to C++ must necessarily include what can be done in 
library code.

That said, I don't agree with many of snk_kid's observations.  D *does* 
support implicit template instantiation, for example.  The compiler 
implementation is just incomplete.  As for concepts, I do think they 
would be useful in D but I think they're less necessary than in C++ 
because D has static if and static assert.  Also, you can inherit from 
template type parameters as far as I know.

As for boost::function--it's a horrible bit of code and is far more 
awkward to use than delegates (particularly anonymous delegates) but it 
works pretty well aside from all that.  However, snk_kid doesn't address 
the idea that inner functions (ie. delegates) have access to local stack 
data, or that actually defining a new boost::function is nothing at all 
like defining a plain old function--it's obviously a class-based hack.

Meta logic is much the same... it's possible in C++ but is far more 
awkward.  And C++ obviously doesn't support strings or decimal numbers 
as template value parameters.  Not to mention aliases.

I think one problem is that some people just look at the spec to learn 
about the language, and the spec is quite sparse in places.  I don't 
think it mentions implicit template instantiation, and mention of some 
other features is hard to find.


 Walter you have your work cut out for you.
 Like most things in IT, the human/political issues outweigh the 
 technical ones.



Always.  But as long as D remains in development and isn't supplanted by 
some magic new language with all of D's features *and* a My Little Pony 
(tm) then it will have users.  Particularly with GDC available for the 
non-Windows folks.


Sean
Jun 29 2006
next sibling parent reply Don Clugston <dac nospam.com.au> writes:
Sean Kelly wrote:

 David Medlock wrote:

 Its adherents rarely surprise me anymore.

 Read my post on LTU and snk_kid's response:
 http://lambda-the-ultimate.org/node/1583#comment-19266

 I am not trying to single him out, but the responses are pretty common 
 in my (arguably anectdotal) experience.







 I think one problem is that some people just look at the spec to learn 
 about the language, and the spec is quite sparse in places.  I don't 
 think it mentions implicit template instantiation, and mention of some 
 other features is hard to find.



On the "Comparison with other languages" page, it explicitly says that D 
doesn't have implicit function template instantiation. AND it's been 
removed from the 'future directions' page.
When I first looked at D, the absence of IFTI was the #1 turn-off. It's 
only because I saw it in the 'future directions' page that I gave the 
language a chance.


 Walter you have your work cut out for you.
 Like most things in IT, the human/political issues outweigh the 
 technical ones.






True, but I'm going to stick up for snk_kid. Based on the spec, he's 
quite justified in thinking D doesn't have IFTI and probably never will; 
and the implications for library design are huge. He's justified in 
thinking that D template libraries will never be as powerful as C++.
When you read the spec, you should get the impression that D templates 
are far more powerful than C++ templates.
Jun 29 2006
next sibling parent David Medlock <noone nowhere.com> writes:
Don Clugston wrote:

 Sean Kelly wrote:
 




 True, but I'm going to stick up for snk_kid. Based on the spec, he's 
 quite justified in thinking D doesn't have IFTI and probably never will; 
 and the implications for library design are huge. He's justified in 
 thinking that D template libraries will never be as powerful as C++.
 When you read the spec, you should get the impression that D templates 
 are far more powerful than C++ templates.




I would agree with you, but look at the first sentence of my post(above 
his).
Jun 30 2006
prev sibling parent Walter Bright <newshound digitalmars.com> writes:
Don Clugston wrote:

 On the "Comparison with other languages" page, it explicitly says that D 
 doesn't have implicit function template instantiation.



Fixed (How did I miss that!)
Jun 30 2006
prev sibling parent Walter Bright <newshound digitalmars.com> writes:
Sean Kelly wrote:

 For better or worse, a primary design goal of C++ was keep 
 as much as possible out of the language definition by supporting user 
 defined types that are indistinguishable from built-in types.  So a 
 valid comparison to C++ must necessarily include what can be done in 
 library code.



For a language with minimal features as a primary design goal, C++ 
turned out to be, by far, the most complex core language ever to implement!
Jun 30 2006
prev sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"David Medlock" <noone nowhere.com> wrote in message 
news:e819r5$h8i$1 digitaldaemon.com...


 Read my post on LTU and snk_kid's response:



snk_kid is just another C++ fanboy.  I'm dealing with him on gamedev.net 
too.
Jun 29 2006
parent reply clayasaurus <clayasaurus gmail.com> writes:
Jarrett Billingsley wrote:

 "David Medlock" <noone nowhere.com> wrote in message 
 news:e819r5$h8i$1 digitaldaemon.com...
 

 Read my post on LTU and snk_kid's response:



 snk_kid is just another C++ fanboy.  I'm dealing with him on gamedev.net 
 too. 
 
 



link?
Jun 29 2006
parent reply Mike Parker <aldacron71 yahoo.com> writes:
clayasaurus wrote:

 Jarrett Billingsley wrote:

 "David Medlock" <noone nowhere.com> wrote in message 
 news:e819r5$h8i$1 digitaldaemon.com...


 Read my post on LTU and snk_kid's response:



 snk_kid is just another C++ fanboy.  I'm dealing with him on 
 gamedev.net too.



 link?



Shame on you, Clay, for not keeping up with my blog!

http://www.gamedev.net/community/forums/topic.asp?topic_id=400729
Jun 30 2006
next sibling parent reply BCS <BCS pathlink.com> writes:
Mike Parker wrote:

 clayasaurus wrote:
 

 Jarrett Billingsley wrote:


 "David Medlock" <noone nowhere.com> wrote in message 
 news:e819r5$h8i$1 digitaldaemon.com...


 Read my post on LTU and snk_kid's response:




 snk_kid is just another C++ fanboy.  I'm dealing with him on 
 gamedev.net too.



 link?



 
 Shame on you, Clay, for not keeping up with my blog!
 
 http://www.gamedev.net/community/forums/topic.asp?topic_id=400729



Interesting, in both places snk_kid keeps harping on his claim that "D 
is a failed attempt to be truely better than C++ in *all aspects* which 
it isn't."

Where did he get that impression????

I have never seen anyone else make the claim that D is trying to be 
better than anything in *all* respects. Walter doesn't claim this. And 
considering it is provable that it can't be done, It would be stupid for 
anyone to claim that.

Also, in places he argues that D will not take over because it can't do 
something that C++ programmers do. This is only a problem if you try to 
wright C++ programs in D. The question shouldn't be: "Can the language 
generate this construct?", it should be: "How easy is it to solve this 
problem in this language?".

D isn't a better C++. No programming language can be a better C++. D is 
trying to be a better *Programming Language*.
Jun 30 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
BCS wrote:

 Interesting, in both places snk_kid keeps harping on his claim that "D 
 is a failed attempt to be truely better than C++ in *all aspects* which 
 it isn't."



I've seen similar claims, and what they are are excuses to not use D 
regardless. It doesn't matter to these people what D can do that is 
utterly impractical in C++.

Another problem happens when people try to transliterate C++ code into 
D. That doesn't work very well - you have to rethink things a bit.

Nevertheless, I still regard D as a better C++. Not in terms of being a 
true superset, but in terms of being a better solution to the same types 
of problems that C++ is targetted at. Note that C++ isn't a true 
superset of C, either, although it is billed as a "better C".
Jun 30 2006
parent reply Sean Kelly <sean f4.ca> writes:
Walter Bright wrote:

 
 Another problem happens when people try to transliterate C++ code into 
 D. That doesn't work very well - you have to rethink things a bit.



In my experience, transliterating C++ to D allows for a lot of code to 
simply be tossed out.  It's issues like this that aren't obvious from 
simply reading a spec.


 Nevertheless, I still regard D as a better C++. Not in terms of being a 
 true superset, but in terms of being a better solution to the same types 
 of problems that C++ is targetted at. Note that C++ isn't a true 
 superset of C, either, although it is billed as a "better C".



I've yet to do the same level of work in D that I do in C++, but so far 
I'd have to agree.  And I'm looking forward to some more ambitious 
projects once the framework is sorted out sufficiently.

That said, I do think D's lack of any sort of const checking may be an 
issue for large projects (I haven't done this level of development in 
Java so I don't have a good non-C++ basis for comparison here).  I know 
the issue has been beaten to death in the past, but perhaps we could do 
with a constructive discussion before 1.0 appears on the horizon?  I've 
become convinced that the "default everything to const" method seems 
ideal, but this seems like something that should really be done before 
1.0 if it's going to happen?


Sean
Jun 30 2006
next sibling parent reply Deewiant <deewiant.doesnotlike.spam gmail.com> writes:
Sean Kelly wrote:

 I've become convinced that the "default everything to const" method seems 
 ideal, but this seems like something that should really be done before 1.0 if
 it's going to happen?
 
 
 Sean



I agree. Walter posted somewhere in comp.lang.c++.moderated (I think it was
there) that he thinks he should have made D like this from the start, but that
it's too late now. With that, I disagree. We're not at 1.0 yet: it's not too
late to break even every single line of D code out there.
Jun 30 2006
next sibling parent Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
Deewiant wrote:

 I agree. Walter posted somewhere in comp.lang.c++.moderated (I think it was
 there) that he thinks he should have made D like this from the start, but that
 it's too late now. With that, I disagree. We're not at 1.0 yet: it's not too
 late to break even every single line of D code out there.



And if it's going to be added post 1.0, there will be even more code 
that will have to be modified to use all the new cool features that D 
2.0 will provide :>

Walter, if you think that it's too late because it might break a lot of 
code, why not let the community decide whether it would be very bad or not ?


-- 
Tomasz Stachowiak  /+ a.k.a. h3r3tic +/
Jun 30 2006
prev sibling next sibling parent Sean Kelly <sean f4.ca> writes:
Deewiant wrote:

 Sean Kelly wrote:

 I've become convinced that the "default everything to const" method seems 
 ideal, but this seems like something that should really be done before 1.0 if
 it's going to happen?



 I agree. Walter posted somewhere in comp.lang.c++.moderated (I think it was
 there) that he thinks he should have made D like this from the start, but that
 it's too late now. With that, I disagree. We're not at 1.0 yet: it's not too
 late to break even every single line of D code out there.



And there's nothing wrong with making it a warning for N releases, or 
allocating a new flag for experimental features, assuming it really is 
the correct approach.  Also, with discussion, we may even be able to 
prepare for upcoming changes or put off creating code-level hacks to 
mimic the same behavior.


Sean
Jun 30 2006
prev sibling next sibling parent reply Deewiant <deewiant.doesnotlike.spam gmail.com> writes:
Deewiant wrote:

 Sean Kelly wrote:

 I've become convinced that the "default everything to const" method seems 
 ideal, but this seems like something that should really be done before 1.0 
 if it's going to happen?
 
 Sean



 I agree. Walter posted somewhere in comp.lang.c++.moderated (I think it was 
 there) that he thinks he should have made D like this from the start, but 
 that it's too late now. With that, I disagree. We're not at 1.0 yet: it's not
  too late to break even every single line of D code out there.



I found the post in question, BTW. Here's the Google Groups link:

http://groups.google.com/group/comp.lang.c++.moderated/tree/browse_frm/thread/d6695737a74e1853/18dc841928a6eee3?rnum=131&_done=%2Fgroup%2Fcomp.lang.c%2B%2B.moderated%2Fbrowse_frm%2Fthread%2Fd6695737a74e1853%2F840b0deea2987ee5%3Flnk%3Dst%26rnum%3D1%26#doc_3ff8dedacef55e17

In summary:

Andrei Alexandrescu says "Why, then, didn't D make const the default? C++ had a
good reason - C compatibility."

Walter responds: "I should have. Too much water under the bridge for that now."

In the same post Walter also acknowledges that "There has been some talk in the
D newsgroups of doing that, but it has the potential to be extremely
disruptive."
Jun 30 2006
next sibling parent reply John Reimer <terminal.node gmail.com> writes:
Deewiant wrote:

 Deewiant wrote:

 Sean Kelly wrote:

 I've become convinced that the "default everything to const" method seems 
 ideal, but this seems like something that should really be done before 1.0 
 if it's going to happen?

 Sean



 there) that he thinks he should have made D like this from the start, but 
 that it's too late now. With that, I disagree. We're not at 1.0 yet: it's not
  too late to break even every single line of D code out there.



 I found the post in question, BTW. Here's the Google Groups link:
 
 http://groups.google.com/group/comp.lang.c++.moderated/tree/browse_frm/thread/d6695737a74e1853/18dc841928a6eee3?rnum=131&_done=%2Fgroup%2Fcomp.lang.c%2B%2B.moderated%2Fbrowse_frm%2Fthread%2Fd6695737a74e1853%2F840b0deea2987ee5%3Flnk%3Dst%26rnum%3D1%26#doc_3ff8dedacef55e17
 
 In summary:
 
 Andrei Alexandrescu says "Why, then, didn't D make const the default? C++ had a
 good reason - C compatibility."
 
 Walter responds: "I should have. Too much water under the bridge for that now."
 
 In the same post Walter also acknowledges that "There has been some talk in the
 D newsgroups of doing that, but it has the potential to be extremely
disruptive."




Absolutely. we definitely need it.  Walter, I hope you will reconsider. 
  Many of us are more than willing to accept any of those potential 
disruptions.  Success often comes only with risk. :)

You've got this far with such an incredible language, why not take it 
all the way?

-JJR
Jun 30 2006
next sibling parent "Ameer Armaly" <ameer_armaly hotmail.com> writes:
"John Reimer" <terminal.node gmail.com> wrote in message 
news:e841ch$169g$1 digitaldaemon.com...

 Deewiant wrote:

 Deewiant wrote:

 Sean Kelly wrote:

 I've become convinced that the "default everything to const" method 
 seems ideal, but this seems like something that should really be done 
 before 1.0 if it's going to happen?

 Sean



 was there) that he thinks he should have made D like this from the 
 start, but that it's too late now. With that, I disagree. We're not at 
 1.0 yet: it's not
  too late to break even every single line of D code out there.



 I found the post in question, BTW. Here's the Google Groups link:

 http://groups.google.com/group/comp.lang.c++.moderated/tree/browse_frm/thread/d6695737a74e1853/18dc841928a6eee3?rnum=131&_done=%2Fgroup%2Fcomp.lang.c%2B%2B.moderated%2Fbrowse_frm%2Fthread%2Fd6695737a74e1853%2F840b0deea2987ee5%3Flnk%3Dst%26rnum%3D1%26#doc_3ff8dedacef55e17

 In summary:

 Andrei Alexandrescu says "Why, then, didn't D make const the default? C++ 
 had a
 good reason - C compatibility."

 Walter responds: "I should have. Too much water under the bridge for that 
 now."

 In the same post Walter also acknowledges that "There has been some talk 
 in the
 D newsgroups of doing that, but it has the potential to be extremely 
 disruptive."




 Absolutely. we definitely need it.  Walter, I hope you will reconsider. 
 Many of us are more than willing to accept any of those potential 
 disruptions.  Success often comes only with risk. :)

 You've got this far with such an incredible language, why not take it all 
 the way?



you shouldn't be surprised if a change breaks your code; I'm sure most if 
not all of us here know that, and if you don't by this time, well...

 -JJR
Jun 30 2006
prev sibling parent clayasaurus <clayasaurus gmail.com> writes:
John Reimer wrote:

 Deewiant wrote:

 Deewiant wrote:

 Sean Kelly wrote:

 I've become convinced that the "default everything to const" method 
 seems ideal, but this seems like something that should really be 
 done before 1.0 if it's going to happen?

 Sean



 it was there) that he thinks he should have made D like this from the 
 start, but that it's too late now. With that, I disagree. We're not 
 at 1.0 yet: it's not
  too late to break even every single line of D code out there.



 I found the post in question, BTW. Here's the Google Groups link:

 http://groups.google.com/group/comp.lang.c++.moderated/tree/browse_frm/thread/d6695737a74e1853/18dc841928a6eee3?rnum=131&_done=%2Fgroup%2Fcomp.lang.c%2B%2B.moderated%2Fbrowse_frm%2Fthread%2Fd6695737a74e1853%2F840b0deea2987ee5%3Flnk%3Dst%26rnum%3D1%26#
oc_3ff8dedacef55e17 


 In summary:

 Andrei Alexandrescu says "Why, then, didn't D make const the default? 
 C++ had a
 good reason - C compatibility."

 Walter responds: "I should have. Too much water under the bridge for 
 that now."

 In the same post Walter also acknowledges that "There has been some 
 talk in the
 D newsgroups of doing that, but it has the potential to be extremely 
 disruptive."



 
 Absolutely. we definitely need it.  Walter, I hope you will reconsider. 
  Many of us are more than willing to accept any of those potential 
 disruptions.  Success often comes only with risk. :)
 
 You've got this far with such an incredible language, why not take it 
 all the way?
 
 -JJR



If it makes D better then add it. This goes for any feature. Of course 
discuss disrupting features on the NG first.
Jun 30 2006
prev sibling next sibling parent reply "Derek Parnell" <derek psych.ward> writes:
On Sat, 01 Jul 2006 05:47:51 +1000, Deewiant  
<deewiant.doesnotlike.spam gmail.com> wrote:


 Deewiant wrote:




 I found the post in question, BTW. Here's the Google Groups link:
 In summary:

 Andrei Alexandrescu says "Why, then, didn't D make const the default?  
 C++ had a
 good reason - C compatibility."

 Walter responds: "I should have. Too much water under the bridge for  
 that now."

 In the same post Walter also acknowledges that "There has been some talk  
 in the
 D newsgroups of doing that, but it has the potential to be extremely  
 disruptive."



This would be a welcomed disruption as it makes D a much better product. I  
have no problems about retrofitting this sort of change in all my D code.

-- 
Derek Parnell
Melbourne, Australia
Jun 30 2006
parent Dave <Dave_member pathlink.com> writes:
Derek Parnell wrote:

 On Sat, 01 Jul 2006 05:47:51 +1000, Deewiant 
 <deewiant.doesnotlike.spam gmail.com> wrote:
 

 Deewiant wrote:




 I found the post in question, BTW. Here's the Google Groups link:
 In summary:

 Andrei Alexandrescu says "Why, then, didn't D make const the default? 
 C++ had a
 good reason - C compatibility."

 Walter responds: "I should have. Too much water under the bridge for 
 that now."

 In the same post Walter also acknowledges that "There has been some 
 talk in the
 D newsgroups of doing that, but it has the potential to be extremely 
 disruptive."



 This would be a welcomed disruption as it makes D a much better product. 
 I have no problems about retrofitting this sort of change in all my D code.
 



I agree.

People can always use the current version if they need to support code 
that this breaks.


 --Derek Parnell
 Melbourne, Australia
Jul 01 2006
prev sibling next sibling parent Juan Jose Comellas <jcomellas gmail.com> writes:
Well, I hope D gets const support somewhere in the near future, because it
is also needed to be able to pass parameters to threads efficiently (i.e.
without duplicating everything). There needs to be a way to specify that a
certain object is immutable when you pass it to a thread to avoid
unnecessary locking.

The lack of this feature is not much of a problem for small projects or when
you're only dealing with your own code, but once D takes off (as I believe
everybody here hopes it will) and we start using a lot of different D
libraries it will become an essential feature.


Deewiant wrote:


 Deewiant wrote:

 Sean Kelly wrote:

 I've become convinced that the "default everything to const" method
 seems ideal, but this seems like something that should really be done
 before 1.0 if it's going to happen?
 
 Sean



 I agree. Walter posted somewhere in comp.lang.c++.moderated (I think it
 was there) that he thinks he should have made D like this from the start,
 but that it's too late now. With that, I disagree. We're not at 1.0 yet:
 it's not
  too late to break even every single line of D code out there.



 I found the post in question, BTW. Here's the Google Groups link:
 




 
 In summary:
 
 Andrei Alexandrescu says "Why, then, didn't D make const the default? C++
 had a good reason - C compatibility."
 
 Walter responds: "I should have. Too much water under the bridge for that
 now."
 
 In the same post Walter also acknowledges that "There has been some talk
 in the D newsgroups of doing that, but it has the potential to be
 extremely disruptive."
Jul 01 2006
prev sibling next sibling parent Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
Deewiant wrote:

 Deewiant wrote:

 Sean Kelly wrote:

 I've become convinced that the "default everything to const" method seems 
 ideal, but this seems like something that should really be done before 1.0 
 if it's going to happen?

 Sean



 there) that he thinks he should have made D like this from the start, but 
 that it's too late now. With that, I disagree. We're not at 1.0 yet: it's not
  too late to break even every single line of D code out there.



 I found the post in question, BTW. Here's the Google Groups link:
 
 http://groups.google.com/group/comp.lang.c++.moderated/tree/browse_frm/thread/d6695737a74e1853/18dc841928a6eee3?rnum=131&_done=%2Fgroup%2Fcomp.lang.c%2B%2B.moderated%2Fbrowse_frm%2Fthread%2Fd6695737a74e1853%2F840b0deea2987ee5%3Flnk%3Dst%26rnum%3D1%26#doc_3ff8dedacef55e17
 
 In summary:
 
 Andrei Alexandrescu says "Why, then, didn't D make const the default? C++ had a
 good reason - C compatibility."
 
 Walter responds: "I should have. Too much water under the bridge for that now."
 
 In the same post Walter also acknowledges that "There has been some talk in the
 D newsgroups of doing that, but it has the potential to be extremely
disruptive."



Good thread, I highly agree with what Andrei said in that segment. In 
summary, that a language supported read-only view of data is 
significantly beneficial.

As for the backwards compatibility issue, I've said it before: D, as a 
language in development, should not be blocked by backwards 
compatibility issues in detriment of beneficial changes. Of course, such 
changes must be extensively thought about and discussed beforehand.

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Jul 03 2006
prev sibling parent Serg Kovrov <user domain.invalid> writes:
Deewiant wrote:

 
 I found the post in question, BTW. Here's the Google Groups link:
 
 http://groups.google.com/group/comp.lang.c++.moderated/tree/browse_frm/thread/d6695737a74e1853/18dc841928a6eee3?rnum=131&_done=%2Fgroup%2Fcomp.lang.c%2B%2B.moderated%2Fbrowse_frm%2Fthread%2Fd6695737a74e1853%2F840b0deea2987ee5%3Flnk%3Dst%26rnum%3D1%26#doc_3ff8dedacef55e17
 
 In summary:
 
 Andrei Alexandrescu says "Why, then, didn't D make const the default? C++ had a
 good reason - C compatibility."
 
 Walter responds: "I should have. Too much water under the bridge for that now."
 
 In the same post Walter also acknowledges that "There has been some talk in the
 D newsgroups of doing that, but it has the potential to be extremely
disruptive."



Subj.

ps. Sorry for flood, but i just can't help it =)
--
serg.
Jul 03 2006
prev sibling next sibling parent reply "Tony" <ignorethis nowhere.com> writes:
"Deewiant" <deewiant.doesnotlike.spam gmail.com> wrote in message 
news:e83rmr$vi5$1 digitaldaemon.com...

 Sean Kelly wrote:

 I've become convinced that the "default everything to const" method seems
 ideal, but this seems like something that should really be done before 
 1.0 if
 it's going to happen?


 Sean



 I agree. Walter posted somewhere in comp.lang.c++.moderated (I think it 
 was
 there) that he thinks he should have made D like this from the start, but 
 that
 it's too late now. With that, I disagree. We're not at 1.0 yet: it's not 
 too
 late to break even every single line of D code out there.



I too agree.  Making const the default and adding a mutable keyword would be 
wonderful.  This would more than address what seems to be one of the primary 
(and I think quite justified) criticisms of D by the C++ community.

This might also assist a future compiler in determining what operations 
could be done in parallel.

I assumed that the version numbering scheme (i.e. not yet at 1.0) was an 
indication that the language was still in development and might change in 
fairly fundamental ways.

Tony
Melbourne, Australia
Jun 30 2006
parent BCS <BCS pathlink.com> writes:
Tony wrote:

 
 
 I too agree.  Making const the default and adding a mutable keyword would be 
 wonderful.  This would more than address what seems to be one of the primary 
 (and I think quite justified) criticisms of D by the C++ community.
 




This would only apply to reference types I assume. So, when giving away 
a reference, would one have to grant mutability privilege any time the 
recipient doesn't ensure non-mutation?

If this is the case, I would advocate the use of an operator for this, 
something with a syntax like the address of (&) operator, maybe the " ".



void func(mute char[] arg)
{
	foreach(inout a;arg) a='\0';
}

...
char[] foo;

func( foo);	// valid
func(foo);	// error: argument 1 of "func" is mutable
...
Jun 30 2006
prev sibling next sibling parent "Boris Wang" <nano.kago hotmail.com> writes:
Yes,before 1.0, any change is not too late, always.

"Deewiant" <deewiant.doesnotlike.spam gmail.com> 
??????:e83rmr$vi5$1 digitaldaemon.com...

 Sean Kelly wrote:

 I've become convinced that the "default everything to const" method seems
 ideal, but this seems like something that should really be done before 
 1.0 if
 it's going to happen?


 Sean



 I agree. Walter posted somewhere in comp.lang.c++.moderated (I think it 
 was
 there) that he thinks he should have made D like this from the start, but 
 that
 it's too late now. With that, I disagree. We're not at 1.0 yet: it's not 
 too
 late to break even every single line of D code out there.
Jul 01 2006
prev sibling parent reply Lucas Goss <lgoss007 gmail.com> writes:
Deewiant wrote:

 Sean Kelly wrote:

 I've become convinced that the "default everything to const" method seems 
 ideal, but this seems like something that should really be done before 1.0 if
 it's going to happen?

 Sean



 I agree. Walter posted somewhere in comp.lang.c++.moderated (I think it was
 there) that he thinks he should have made D like this from the start, but that
 it's too late now. With that, I disagree. We're not at 1.0 yet: it's not too
 late to break even every single line of D code out there.



I thought I've seen in this newsgroup a while back that Walter would 
make changes to the language that would break previous versions, because 
he didn't want it to end up like c++ (ugly patches instead of fixing 
things correctly and breaking compatibility)? To me that is a big plus 
in a language, that the author is willing to break things for the good 
of the language. And D hasn't even hit version 1.0 yet, so I don't see a 
problem at all.

Also I did sort of agree with snk_kid on one point... I don't understand 
why D uses "~" for adding words together instead of "+". It seems like 
all the other languages I use all use + for adding words. Adding makes 
sense for words...

I added on to what he said.
I added some words to his sentence.
If you add these two phrases together...

Is there any benefit to having a separate symbol for adding (ok, 
concatenating)? If not feel free to break the language here too.

Lucas
Jul 01 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Lucas Goss wrote:

 Also I did sort of agree with snk_kid on one point... I don't understand 
 why D uses "~" for adding words together instead of "+". It seems like 
 all the other languages I use all use + for adding words. Adding makes 
 sense for words...
 
 I added on to what he said.
 I added some words to his sentence.
 If you add these two phrases together...
 
 Is there any benefit to having a separate symbol for adding (ok, 
 concatenating)? If not feel free to break the language here too.



Concatenation is quite different from addition:

int[3] a = [1,2,3];
int[3] b = [4,5,6];

int[] c = a + b;	// c[] = [5,7,9]
int[] d = a ~ b;	// d[] = [1,2,3,4,5,6]

Two distinct operators are necessary.
Jul 01 2006
next sibling parent reply Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Walter Bright wrote:

 Lucas Goss wrote:
 

 Also I did sort of agree with snk_kid on one point... I don't 
 understand why D uses "~" for adding words together instead of "+". It 
 seems like all the other languages I use all use + for adding words. 
 Adding makes sense for words...

 I added on to what he said.
 I added some words to his sentence.
 If you add these two phrases together...

 Is there any benefit to having a separate symbol for adding (ok, 
 concatenating)? If not feel free to break the language here too.



 
 Concatenation is quite different from addition:
 
 int[3] a = [1,2,3];
 int[3] b = [4,5,6];
 
 int[] c = a + b;    // c[] = [5,7,9]
 int[] d = a ~ b;    // d[] = [1,2,3,4,5,6]
 
 Two distinct operators are necessary.



Amen.  Disambiguation is a Good Thing(tm).

Except for "Array operations not implemented" as yet.  Any idea when this
much-coveted, 
much-anticipated feature will come to life?  I don't mean to push, but I've
dreamt of 
array-ops nearly since I first got involved with D back in 2003.

-- Chris Nicholson-Sauls
Jul 01 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Chris Nicholson-Sauls wrote:

 Except for "Array operations not implemented" as yet.  Any idea when 
 this much-coveted, much-anticipated feature will come to life?  I don't 
 mean to push, but I've dreamt of array-ops nearly since I first got 
 involved with D back in 2003.



It'll have to be a 2.0 thing.
Jul 02 2006
parent reply Fredrik Olsson <peylow gmail.com> writes:
Walter Bright skrev:

 Chris Nicholson-Sauls wrote:
 

 Except for "Array operations not implemented" as yet.  Any idea when 
 this much-coveted, much-anticipated feature will come to life?  I 
 don't mean to push, but I've dreamt of array-ops nearly since I first 
 got involved with D back in 2003.



 
 It'll have to be a 2.0 thing.



guess there are a million reasons as to why not have them, but if I 
could choose this would be a nice syntax for both introducing operator 
overloads and properties to existing types:

type int[] {

     int[] opAdd(int[] a) {
         assert(this.length == a.length);
         int[] r; r.length = this.length;
         foreach (i, v; this) {
             r[i] = v + a[i];
         }
         return r;
     }

     int sum() {
         int r = 0;
         foreach(v; this) {
             r += v;
         }
         return v;
     }

}

// Making these work;
int[] a = [1, 2, 3];
int[] b = [4, 5, 6];
int[] c = a + b; // [5, 7, 9];
int d = c.sum(); // 15


// Fredrik
Jul 07 2006
parent Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Fredrik Olsson wrote:

 Walter Bright skrev:
 

 Chris Nicholson-Sauls wrote:


 Except for "Array operations not implemented" as yet.  Any idea when 
 this much-coveted, much-anticipated feature will come to life?  I 
 don't mean to push, but I've dreamt of array-ops nearly since I first 
 got involved with D back in 2003.





 It'll have to be a 2.0 thing.



 Perhaps not part of core language, put thought operator overloads. I 
 guess there are a million reasons as to why not have them, but if I 
 could choose this would be a nice syntax for both introducing operator 
 overloads and properties to existing types:
 
 type int[] {
 
     int[] opAdd(int[] a) {
         assert(this.length == a.length);
         int[] r; r.length = this.length;
         foreach (i, v; this) {
             r[i] = v + a[i];
         }
         return r;
     }
 
     int sum() {
         int r = 0;
         foreach(v; this) {
             r += v;
         }
         return v;
     }
 
 }
 
 // Making these work;
 int[] a = [1, 2, 3];
 int[] b = [4, 5, 6];
 int[] c = a + b; // [5, 7, 9];
 int d = c.sum(); // 15
 
 
 // Fredrik



This gives me a thought.  Currently we have the pseudo-member effect, which
causes the 
following to be possible:

# int sum (int[] arr) {
#   int result = 0 ;
#
#   foreach (i; arr)
#     result += arr;
#
#   return result;
# }
#
# int[] foo = [1, 2, 3, 4] ;
# int   bar = foo.sum      ; // bar == 1 + 2 + 3 + 4 == 10

Also, in D (theoretically at least) it seems all operators are rewritten as
function 
calls.  Such that the expression (a + b) becomes (a.opAdd(b)).  So, perhaps we
could do 
something like this:

# int[] opAdd (int[] a, int[] b)
# in {
#   assert( a.length == b.length, "Array-Ops only applicable to arrays of equal
length" );
# }
# body {
#   int[] result = new int[a.length] ;
#
#   foreach (i, x; a) {
#     result[i] = x + b[i];
#   }
#   return result.dup;
# }
#
# int[] foo = [1, 2, 3] ,
#       bar = [4, 5, 6] ;
#
# int[] xyz = foo + bar ; // (foo.opAdd(bar)) -> (.opAdd(foo, bar)) == [5, 7, 9]

Just a crazy thought.

-- Chris Nicholson-Sauls
Jul 08 2006
prev sibling parent Lucas Goss <lgoss007 gmail.com> writes:
Walter Bright wrote:

 Lucas Goss wrote:

 Is there any benefit to having a separate symbol for adding (ok, 
 concatenating)? If not feel free to break the language here too.



 Concatenation is quite different from addition:
 
 int[3] a = [1,2,3];
 int[3] b = [4,5,6];
 
 int[] c = a + b;    // c[] = [5,7,9]
 int[] d = a ~ b;    // d[] = [1,2,3,4,5,6]
 
 Two distinct operators are necessary.



Ah, thanks! That makes sense.

Lucas
Jul 01 2006
prev sibling parent reply kris <foo bar.com> writes:
Sean Kelly wrote:

 Walter Bright wrote:
 

 Another problem happens when people try to transliterate C++ code into 
 D. That doesn't work very well - you have to rethink things a bit.



 
 In my experience, transliterating C++ to D allows for a lot of code to 
 simply be tossed out.  It's issues like this that aren't obvious from 
 simply reading a spec.
 

 Nevertheless, I still regard D as a better C++. Not in terms of being 
 a true superset, but in terms of being a better solution to the same 
 types of problems that C++ is targetted at. Note that C++ isn't a true 
 superset of C, either, although it is billed as a "better C".



 
 I've yet to do the same level of work in D that I do in C++, but so far 
 I'd have to agree.  And I'm looking forward to some more ambitious 
 projects once the framework is sorted out sufficiently.
 
 That said, I do think D's lack of any sort of const checking may be an 
 issue for large projects (I haven't done this level of development in 
 Java so I don't have a good non-C++ basis for comparison here).  I know 
 the issue has been beaten to death in the past, but perhaps we could do 
 with a constructive discussion before 1.0 appears on the horizon?  I've 
 become convinced that the "default everything to const" method seems 
 ideal, but this seems like something that should really be done before 
 1.0 if it's going to happen?
 
 
 Sean



As someone with a substantial body of D code, I'd be happy to retrofit 
the whole darned thing to get const. I'd say "go for it" (as long as it 
supports returning an array as a const, without .dup being involved)
Jun 30 2006
parent Lars Ivar Igesund <larsivar igesund.net> writes:
kris wrote:


 Sean Kelly wrote:

 Walter Bright wrote:
 

 Another problem happens when people try to transliterate C++ code into
 D. That doesn't work very well - you have to rethink things a bit.



 
 In my experience, transliterating C++ to D allows for a lot of code to
 simply be tossed out.  It's issues like this that aren't obvious from
 simply reading a spec.
 

 Nevertheless, I still regard D as a better C++. Not in terms of being
 a true superset, but in terms of being a better solution to the same
 types of problems that C++ is targetted at. Note that C++ isn't a true
 superset of C, either, although it is billed as a "better C".



 
 I've yet to do the same level of work in D that I do in C++, but so far
 I'd have to agree.  And I'm looking forward to some more ambitious
 projects once the framework is sorted out sufficiently.
 
 That said, I do think D's lack of any sort of const checking may be an
 issue for large projects (I haven't done this level of development in
 Java so I don't have a good non-C++ basis for comparison here).  I know
 the issue has been beaten to death in the past, but perhaps we could do
 with a constructive discussion before 1.0 appears on the horizon?  I've
 become convinced that the "default everything to const" method seems
 ideal, but this seems like something that should really be done before
 1.0 if it's going to happen?
 
 
 Sean



 As someone with a substantial body of D code, I'd be happy to retrofit
 the whole darned thing to get const. I'd say "go for it" (as long as it
 supports returning an array as a const, without .dup being involved)



As someone without a substantial body of D code, I'd be happy to retrofit
other's code if necessary. In all other respects (on this particular
matter), I just agree with Kris :)

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi
Jun 30 2006
prev sibling parent clayasaurus <clayasaurus gmail.com> writes:
Mike Parker wrote:

 clayasaurus wrote:

 Jarrett Billingsley wrote:

 "David Medlock" <noone nowhere.com> wrote in message 
 news:e819r5$h8i$1 digitaldaemon.com...


 Read my post on LTU and snk_kid's response:



 snk_kid is just another C++ fanboy.  I'm dealing with him on 
 gamedev.net too.



 link?



 Shame on you, Clay, for not keeping up with my blog!
 
 http://www.gamedev.net/community/forums/topic.asp?topic_id=400729



aye, I've been busy lately :-P
Jun 30 2006