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

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.

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

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.

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

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

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.