Hello,

I have encountered the following problems with DMD 0.122:

1. DMD crashes after the error message
"function foo.bar (int) does not match argument types ()".

2. DMD crashes on "int x = 1 % 0;".

3. "debug:" does not work.
"debug {}" does.

4. Should I use "is" or "===" for comparing against null? Are they equivalent?

5. I think that the comparisons "== null" and "!= null" should be compile-time
errors.
Now they are run-time errors.

6. Why "array.length--" does not work?
"array.length = array.length - 1;" does.

1. Already fixed in next release, regression in this release.

2. I think I read a bug report on that or similar... but, that should be in D.bugs.

3. Should it?  I don't see anything here that indicates it should:

http://www.digitalmars.com/d/version.html

And then how do you end the debug block?  Seems to me braces are better.

4. They are equivalent.  Some prefer is because it doesn't look like "==" to blind people or with bad fonts.

5. This has been discussed often, although it's theoretically possible for an initiated class to be equal to null (e.g. a string, if "", might be.)

6. Not sure on that one, although I know it was mentioned at least once.

-[Unknown]


> Hello,
> 
> I have encountered the following problems with DMD 0.122:
> 
> 1. DMD crashes after the error message
> "function foo.bar (int) does not match argument types ()".
> 
> 2. DMD crashes on "int x = 1 % 0;".
> 
> 3. "debug:" does not work.
> "debug {}" does.
> 
> 4. Should I use "is" or "===" for comparing against null? Are they equivalent?
> 
> 5. I think that the comparisons "== null" and "!= null" should be compile-time
> errors.
> Now they are run-time errors.
> 
> 6. Why "array.length--" does not work?
> "array.length = array.length - 1;" does.
> 
> 

>> 3. "debug:" does not work.
>> "debug {}" does.
>> 
>3. Should it?  I don't see anything here that indicates it should:
>
>http://www.digitalmars.com/d/version.html

There's the following example:

class Foo
{
int a, b;
debug:
int flag;
}

On Tue, 17 May 2005 07:49:35 +0000 (UTC), Piotr Fusik wrote:

> Hello,
> 
> I have encountered the following problems with DMD 0.122:
> 
> 1. DMD crashes after the error message
> "function foo.bar (int) does not match argument types ()".

This has been fixed in v0.123

> 2. DMD crashes on "int x = 1 % 0;".

Don't know about this one.

> 3. "debug:" does not work.
> "debug {}" does.

This is a mistake in the documentation. The example should read ...

  class Foo
  {
      int a, b;
      debug int flag;
  }

> 4. Should I use "is" or "===" for comparing against null? Are they equivalent?

They are the same thing. The preferred usage is "is". Don't use "===" as it
is sometimes harder to read.

> 5. I think that the comparisons "== null" and "!= null" should be compile-time
> errors.
> Now they are run-time errors.

How can they be compile-time errors?

  void Func( Foo a)
  {
      if (a == null)
         . . .
  }

This can only be determined at run time, because sometimes it is not an error. There could be an opEqual member defined for the Foo class.


> 6. Why "array.length--" does not work?
> "array.length = array.length - 1;" does.

Because 'length' is not a member variable of an array. It is more like a property function. It is as if you had a class called array and it has a property function called length...

   class array
   {
      uint length() { return ... }
      void length(uint newvalue) { . . . }
   }

so that when you type

   array.length++;

its is like you typed ...

   array.length()++;

and that is not possible as a function call is not an lvalue.

  array.length = array.length + 1;

is like typing ...

   array.length( array.length() + 1);

-- 
Derek Parnell
Melbourne, Australia
17/05/2005 9:17:39 PM

>> 5. I think that the comparisons "== null" and "!= null" should be
>> compile-time
>> errors.
>> Now they are run-time errors.
>
> How can they be compile-time errors?
>
>  void Func( Foo a)
>  {
>      if (a == null)
>         . . .
>  }
>
> This can only be determined at run time, because sometimes it is not an error. There could be an opEqual member defined for the Foo class.

The problem with "a == null" comes when "a is null" since calling opEquals causes a null-pointer dereference (it never even makes it to the opEquals body). A compile-time error is pretty harsh though I sympathize because it is pretty obviously a coder error. I want to add a check for this to dlint but I haven't gotten around to it.

"Piotr Fusik" <Piotr_member@pathlink.com> wrote in message news:d6cfq1$12fe$1@digitaldaemon.com...
> >> 3. "debug:" does not work.
> >> "debug {}" does.
> >>
> >3. Should it?  I don't see anything here that indicates it should:
> >
> >http://www.digitalmars.com/d/version.html
>
> There's the following example:
>
> class Foo
> {
> int a, b;
> debug:
> int flag;
> }
>
>

/* Not sure why you used the colon character after the "debug" keyword.
Try removing it.
The following code compiles... */

void main()
{
int a, b;
debug int flag;
}

// TZ

"Derek Parnell" <derek@psych.ward> wrote in message news:nfamciwrwl02.1vztstuf0ghzv$.dlg@40tude.net...
> On Tue, 17 May 2005 07:49:35 +0000 (UTC), Piotr Fusik wrote:
>
*snip*
> > 3. "debug:" does not work.
> > "debug {}" does.
>
> This is a mistake in the documentation. The example should read ...
>
>   class Foo
>   {
>       int a, b;
>       debug int flag;
>   }
>
*snip*
> -- 
> Derek Parnell
> Melbourne, Australia
> 17/05/2005 9:17:39 PM

Oops... I should have read ahead before saying basically the same thing you had already said.  Hehe.

TZ

"Ben Hinkle" <ben.hinkle@gmail.com> wrote in message news:d6cnp1$195o$1@digitaldaemon.com...
> >> 5. I think that the comparisons "== null" and "!= null" should be
> >> compile-time
> >> errors.
> >> Now they are run-time errors.
> >
> > How can they be compile-time errors?
> >
> >  void Func( Foo a)
> >  {
> >      if (a == null)
> >         . . .
> >  }
> >
> > This can only be determined at run time, because sometimes it is not an error. There could be an opEqual member defined for the Foo class.
>
> The problem with "a == null" comes when "a is null" since calling opEquals causes a null-pointer dereference (it never even makes it to the opEquals body). A compile-time error is pretty harsh though I sympathize because it is pretty obviously a coder error. I want to add a check for this to dlint but I haven't gotten around to it.
>
>
The solution to that would be to treat null.opEquals as a predefined member function of null, when it's requested.
In other words, the compiler could be made to compensate for the problem by attaching a default behavior to the requested action at compile-time.

TZ