• Def (21/21) Mar 08 2006 On http://www.digitalmars.com/d/dcompiler.html it reads:
• Kyle Furlong (2/29) Mar 08 2006 I get the feeling that alot of this is old, maybe Walter can give more s...
• Ben Phillips (7/8) Mar 08 2006 This has been discussed numerous times and the consensus is that overloa...
• Georg Wrede (3/15) Mar 09 2006 It would definitely stand out in code better than a .dup swamped
• James Dunne (10/29) Mar 09 2006 But you lose all meaning as to if that dup is a shallow copy or deep cop...
• Fredrik Olsson (9/32) Mar 09 2006 := shallow copy
• =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= (7/23) Mar 09 2006 It's not that simple. There's a good reason to allow the coder to

Def <Def_member pathlink.com> writes:

On http://www.digitalmars.com/d/dcompiler.html it reads:

"The phobos D runtime library is inadequate."

In which way is Phobos "inadequate"? Will it be "fixed"? If so, how?
When? ;-)
And what about the other bugs:
- The compiler sometimes gets the line number wrong on an error.
- The phobos D runtime library is inadequate.
- Need to write a tool to convert C .h files into D imports.
- Array op= operations are not implemented.
- In preconditions and out postconditions for member functions are not
inherited.
- It cannot be run from the IDDE.

And what about the Linux bugs, listed on the same page?
- -g is only implemented for line numbers, not local symbols, because I
haven't figured out how to do it yet. gdb still works, though, at the
global symbol level.
- The code generator output has not been tuned yet, so it can be bloated.
Shared libraries cannot be generated.
- The exception handling is not compatible with the way g++ does it.
I don't know if this is an issue or not.

Def

Kyle Furlong <kylefurlong gmail.com> writes:

Def wrote:
 On http://www.digitalmars.com/d/dcompiler.html it reads:
 
 "The phobos D runtime library is inadequate."
 
 In which way is Phobos "inadequate"? Will it be "fixed"? If so, how?
 When? ;-)
 And what about the other bugs:
 - The compiler sometimes gets the line number wrong on an error.
 - The phobos D runtime library is inadequate.
 - Need to write a tool to convert C .h files into D imports.
 - Array op= operations are not implemented.
 - In preconditions and out postconditions for member functions are not
 inherited.
 - It cannot be run from the IDDE.
 
 And what about the Linux bugs, listed on the same page?
 - -g is only implemented for line numbers, not local symbols, because I
 haven't figured out how to do it yet. gdb still works, though, at the
 global symbol level.
 - The code generator output has not been tuned yet, so it can be bloated.
 Shared libraries cannot be generated.
 - The exception handling is not compatible with the way g++ does it.
 I don't know if this is an issue or not.
 
 Def
 
 

I get the feeling that alot of this is old, maybe Walter can give more
specifics though.

Ben Phillips <Ben_member pathlink.com> writes:

In article <dune2o$cu4$1 digitaldaemon.com>, Def says...
 Array op= operations are not implemented.

This has been discussed numerous times and the consensus is that overloading "="
is a bad idea. You must remember that D uses references so if we have a class
and two instances ("a" and "b") then "a = b;" makes "a" refer to the same object
as "b". The programmer should not be allowed to change this behavior.

On the other hand, another operator such as ":=" has been suggested which would
be a copy operator rather than an assignment operator

Georg Wrede <georg.wrede nospam.org> writes:

Ben Phillips wrote:
 In article <dune2o$cu4$1 digitaldaemon.com>, Def says...
 
 Array op= operations are not implemented.

 
 This has been discussed numerous times and the consensus is that
 overloading "=" is a bad idea. You must remember that D uses
 references so if we have a class and two instances ("a" and "b") then
 "a = b;" makes "a" refer to the same object as "b". The programmer
 should not be allowed to change this behavior.
 
 On the other hand, another operator such as ":=" has been suggested
 which would be a copy operator rather than an assignment operator

It would definitely stand out in code better than a .dup swamped 
somewhere inconspicuous.

James Dunne <james.jdunne gmail.com> writes:

Georg Wrede wrote:
 Ben Phillips wrote:
 
 In article <dune2o$cu4$1 digitaldaemon.com>, Def says...

 Array op= operations are not implemented.


 This has been discussed numerous times and the consensus is that
 overloading "=" is a bad idea. You must remember that D uses
 references so if we have a class and two instances ("a" and "b") then
 "a = b;" makes "a" refer to the same object as "b". The programmer
 should not be allowed to change this behavior.

 On the other hand, another operator such as ":=" has been suggested
 which would be a copy operator rather than an assignment operator

 
 
 It would definitely stand out in code better than a .dup swamped 
 somewhere inconspicuous.

But you lose all meaning as to if that dup is a shallow copy or deep copy.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/MU/S d-pu s:+ a-->? C++++$ UL+++ P--- L+++ !E W-- N++ o? K? w--- O 
M--  V? PS PE Y+ PGP- t+ 5 X+ !R tv-->!tv b- DI++(+) D++ G e++>e 
h>--->++ r+++ y+++
------END GEEK CODE BLOCK------

James Dunne

Fredrik Olsson <peylow treyst.se> writes:

James Dunne skrev:
 Georg Wrede wrote:
 Ben Phillips wrote:

 In article <dune2o$cu4$1 digitaldaemon.com>, Def says...

 Array op= operations are not implemented.


 This has been discussed numerous times and the consensus is that
 overloading "=" is a bad idea. You must remember that D uses
 references so if we have a class and two instances ("a" and "b") then
 "a = b;" makes "a" refer to the same object as "b". The programmer
 should not be allowed to change this behavior.

 On the other hand, another operator such as ":=" has been suggested
 which would be a copy operator rather than an assignment operator


 It would definitely stand out in code better than a .dup swamped 
 somewhere inconspicuous.

 
 But you lose all meaning as to if that dup is a shallow copy or deep copy.
 

:= shallow copy
::= deep copy

:)

But how to solve for example "foo(bar.dup);"? Perhaps not a critical 
flaw, but something could be useful if you know that foo will corupt the 
input. "foo(:bar);", and "foo(::bar);" would be the logical answers but 
not as pretty, or?

// Fredrik

=?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:

Fredrik Olsson wrote:
 On the other hand, another operator such as ":=" has been suggested
 which would be a copy operator rather than an assignment operator

 It would definitely stand out in code better than a .dup swamped
 somewhere inconspicuous.

 But you lose all meaning as to if that dup is a shallow copy or deep
 copy.

 := shallow copy
 ::= deep copy

It's not that simple. There's a good reason to allow the coder to
override default (shallow) cloning with a custom one. Not all classes
require you to clone all contents. A simple opClone-override would be
enough. A := -operator doesn't provide anything amusingly new. You can
do this already with foo.dup(). But it looks quite pretty :)

 
 But how to solve for example "foo(bar.dup);"? Perhaps not a critical
 flaw, but something could be useful if you know that foo will corupt the
 input. "foo(:bar);", and "foo(::bar);" would be the logical answers but
 not as pretty, or?

No. C++ coders might get confused here.