February 22, 2008
Janice Caron wrote:
> On 22/02/2008, Derek Parnell <derek@nomail.afraid.org> wrote:
>> Compile with the "-w" switch. It checks for 'missing' return paths.
> 
> Ah great! Thanks. That will help a lot.
> 
> I thought D didn't have warnings, but obviously I was wrong.
> 
> It's a shame you can't /selectively/ enable warnings, because I don't
> actually want to be warned about "length" shadowing. Still - it's
> better than it's being an error. In general, I'd prefer that /all/
> shadowing should be allowed. But that's another debate.
> 
> Anyway, thanks for the info. Will definitely be using -w from now on.

Really, 'missing return value' should be an error, not a warning. Unfortunately -w is horribly broken. It generates some nasty spurious errors. For example, it won't let you perform a bitwise operation on anything other than an int.

short a;
short b = a | a; // won't compile with -w !!!!


February 22, 2008
On Fri, 22 Feb 2008 22:27:34 +0100, Don Clugston wrote:

> Janice Caron wrote:
>> On 22/02/2008, Derek Parnell <derek@nomail.afraid.org> wrote:
>>> Compile with the "-w" switch. It checks for 'missing' return paths.
>> 
>> Ah great! Thanks. That will help a lot.
>> 
>> I thought D didn't have warnings, but obviously I was wrong.
>> 
>> It's a shame you can't /selectively/ enable warnings, because I don't actually want to be warned about "length" shadowing. Still - it's better than it's being an error. In general, I'd prefer that /all/ shadowing should be allowed. But that's another debate.
>> 
>> Anyway, thanks for the info. Will definitely be using -w from now on.
> 
> Really, 'missing return value' should be an error, not a warning. Unfortunately -w is horribly broken.

The "-w" does not mean "warning" in D. Walter does not believe in warnings. In D, it means an optional error check, that is to say, one can optionally choose to check for certain types of errors that are not checked for without the "-w" switch. I think these are optional because there is some debate over whether these things are actually errors or not.

The message text says 'warning' but the compiler treats them as errors anyway.

> It generates some nasty spurious errors. For example, it won't let you perform a bitwise operation on anything other than an int.
> 
> short a;
> short b = a | a; // won't compile with -w !!!!

Actually that turns out not to be the case. The 'warning/error' message in this situatation informs the coder that there is a potential loss of information when assigning a larger datatype to a smaller one.

"warning - test.d(4): Error: implicit conversion of expression
 (cast(int)a | cast (int)a) of type int to short can cause
 loss of data"

The real problem with this is that D decides to convert your 'short' values to 'int' before doing the bitwise operation, leaving you with an 'int' value to squeeze back into a 'short'. Now you and I know that this is a redundant operation (converting to 'int') and that the high-end bits will be zeroes anyway so that there is no loss of information. But DMD is not that smart yet.

The 'warning' message is a valid one, in the general sense. For example this code here gives a similar message ...

void main(string[] args)
{
  short argc = args.length;
}

Even though we all know that we are not going to have 2^32 command line arguments to the program.

The proper coding style to get the results you want is to tell the compiler, and other readers of your code, that you "know what you are doing so don't get upset"...

 short a;
 short b = cast(short)(a | a);

 short argc = cast(short)args.length;

These do not give 'warning' messages now.

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
February 22, 2008
Moritz Warning wrote:
> On Thu, 21 Feb 2008 16:24:11 -0800, Robert Fraser wrote:
> 
>> Moritz Warning wrote:
>>> On Thu, 21 Feb 2008 09:53:00 -0700, Darryl Bleau wrote:
>>>
>>>> bearophile wrote:
>>>>> Another solution is to think "in" as an operator, and "!in" as two
>>>>> operators, where ! negates the result of the precedent "in", where
>>>>> "in" returns a pointer. I don't see this as silly :-)
>>>> I should have read this first. Yes, that's exactly what I would like.
>>> Fwiw:
>>> "is" may be no boolean operator, but "!" is a boolean operator. Hence,
>>> "!is" can be boolean operator the same way as "=" is not a boolean
>>> operator, but "!=" is.
>> Did you man "in"? "is" is a boolean operator.
> 
> Yes, I meant "in", not "is". - memory corruption. ;)
> 
> "=" is no boolean operator, but "!=" is.
> The reason for not having "!in" is weak, imho.

!= is not the opposite of =, it's the opposite of ==.

 - Gregor Richards
February 23, 2008
Gregor Richards wrote:
> != is not the opposite of =, it's the opposite of ==.
> 
>  - Gregor Richards

In the interest of supreme correctness, shouldn't that be !== then?

/cheers :)
February 23, 2008
Leandro Lucarella wrote:
> Christopher Wright, el 21 de febrero a las 22:33 me escribiste:
>> Leandro Lucarella wrote:
>>> I think D1.0 is good enough and deserves a little love to finally polish
>>> all the rough corners and make it move forward in small and backward
>>> compatible steps to be a nice, maintained and usable language.
>> The frontend is open source; care to volunteer?
> 
> Yes, but the only problem here is not the source code. If I decide to
> change the frontend to admit, for example, !in, but Walter don't want to
> include it on DMD (which will mean that GDC probably will not follow),
> nothing will change. Other posibility will be to fork the language
> specification, but I don't know if that's even possible because of the
> licensing issues. Or one could just implemente that stuff in GDC
> documenting just the extra features.

It comes down to a popularity contest, and DMD is way ahead.

But let's say the fork just started as a testbed for bug fixes and the like. That'd probably garner more attention than one going for new features. And maybe porting some minor changes in D2 to D1.
February 23, 2008
Gregor Richards wrote:
> Moritz Warning wrote:
>> "=" is no boolean operator, but "!=" is.
>> The reason for not having "!in" is weak, imho.
> 
> != is not the opposite of =, it's the opposite of ==.

Yay, lets introduce !n instead!
February 24, 2008
"Alexander Panek" <alexander.panek@brainsware.org> wrote in message news:fppo5s$11v6$1@digitalmars.com...
> Gregor Richards wrote:
>> Moritz Warning wrote:
>>> "=" is no boolean operator, but "!=" is.
>>> The reason for not having "!in" is weak, imho.
>>
>> != is not the opposite of =, it's the opposite of ==.
>
> Yay, lets introduce !n instead!

VOTE PLUS EQUALS A MILLION


February 24, 2008
Derek Parnell wrote:
> On Fri, 22 Feb 2008 22:27:34 +0100, Don Clugston wrote:
> 
>> Janice Caron wrote:
>>> On 22/02/2008, Derek Parnell <derek@nomail.afraid.org> wrote:
>>>> Compile with the "-w" switch. It checks for 'missing' return paths.
>>> Ah great! Thanks. That will help a lot.
>>>
>>> I thought D didn't have warnings, but obviously I was wrong.
>>>
>>> It's a shame you can't /selectively/ enable warnings, because I don't
>>> actually want to be warned about "length" shadowing. Still - it's
>>> better than it's being an error. In general, I'd prefer that /all/
>>> shadowing should be allowed. But that's another debate.
>>>
>>> Anyway, thanks for the info. Will definitely be using -w from now on.
>> Really, 'missing return value' should be an error, not a warning. Unfortunately -w is horribly broken. 
> 
> The "-w" does not mean "warning" in D. Walter does not believe in warnings.

Nor do I.

> In D, it means an optional error check, that is to say, one can optionally
> choose to check for certain types of errors that are not checked for
> without the "-w" switch. I think these are optional because there is some
> debate over whether these things are actually errors or not.

The problem is that some of them have a >90% chance of being a bug, whereas others (such as the one I mentioned) have a ZERO % chance of being a bug.
> 
> The message text says 'warning' but the compiler treats them as errors
> anyway.
> 
>> It generates some nasty spurious errors. For example, it won't let you perform a bitwise operation on anything other than an int.
>>
>> short a;
>> short b = a | a; // won't compile with -w !!!!
> 
> Actually that turns out not to be the case. The 'warning/error' message in
> this situatation informs the coder that there is a potential loss of
> information when assigning a larger datatype to a smaller one. 
> 
> "warning - test.d(4): Error: implicit conversion of expression
>  (cast(int)a | cast (int)a) of type int to short can cause
>  loss of data"
> 
> The real problem with this is that D decides to convert your 'short' values
> to 'int' before doing the bitwise operation, leaving you with an 'int'
> value to squeeze back into a 'short'. Now you and I know that this is a
> redundant operation (converting to 'int') and that the high-end bits will
> be zeroes anyway so that there is no loss of information. But DMD is not
> that smart yet.
> 
> The 'warning' message is a valid one, in the general sense. For example
> this code here gives a similar message ...

Not really. A usually incorrect error message is much, much worse than useless.
VC6 had one which was basically "warning: you're using templates". But at least you could selectively turn that off. Unfortunately with this one the only option is to not use -w.
> 
> void main(string[] args)
> {
>   short argc = args.length;
> }
> 
> Even though we all know that we are not going to have 2^32 command line
> arguments to the program. 
> 
> The proper coding style to get the results you want is to tell the
> compiler, and other readers of your code, that you "know what you are doing
> so don't get upset"...

>  short a;
>  short b = cast(short)(a | a);
> 
>  short argc = cast(short)args.length;
> 
> These do not give 'warning' messages now.

No, but now you've introduced a latent bug! If someone changes 'a' to be (say) int a, it will now be accepted even though in that case it DOES involve loss of data! Inserting a cast is not an acceptable workaround.
Would be better in the interim to not issue 'narrowing conversion' warnings at all, when they are so hopelessly incorrect.
February 24, 2008
On 24/02/2008, Don Clugston <dac@nospam.com.au> wrote:
>  Would be better in the interim to not issue 'narrowing conversion' warnings at
>  all, when they are so hopelessly incorrect.

I think it would be better if widening type promotions were not done where not necessary. That is, in general

    static assert(typeof(x op y) == CommonType!(typeof(x),typeof(y)));

That way, typeof(a | a) would be typeof(a), and if a was short, then
(a | a) would also be short.
February 24, 2008
On 24/02/2008, Janice Caron <caron800@googlemail.com> wrote:
> I think it would be better if widening type promotions were not done
>  where not necessary.

"where not necessary" now becomes the problem. When is it necessary?

    ubyte n = 255;
    auto m = n + 2;

what type is m?

    uint x = 0xFFFFFFFF;
    auto y = x + 2;

what type is y?

These things obviously need clearly defined rules. Currently the rules seem to be, if in doubt, use int. I don't know if that's necessarily correct in all cases.