Something for everyone here.


http://www.digitalmars.com/d/1.0/changelog.html
http://ftp.digitalmars.com/dmd.1.046.zip


http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.031.zip

Ooooh... looks very nice.  Thanks again, Walter. :)

Incidentally, the links to Final Switch Statement and Case Range Statement in the changelog for 2.031 are broken.

Daniel Keep wrote:
> Ooooh... looks very nice.  Thanks again, Walter. :)

Actually, a lot of people worked on this release, not just me.

> 
> Incidentally, the links to Final Switch Statement and Case Range
> Statement in the changelog for 2.031 are broken.

Walter Bright wrote:
> Daniel Keep wrote:
>> Ooooh... looks very nice.  Thanks again, Walter. :)
> 
> Actually, a lot of people worked on this release, not just me.

True; but it's getting harder to keep track of.

How about this?  Thanks, mixin(reduce!"a~`, `~b"(D_CONTRIBUTORS)).

On Sun, 05 Jul 2009 22:05:10 -0700, Walter Bright wrote:

> Something for everyone here.
> 
> http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.046.zip
> 
> http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.031.zip

The -deps= switch is helpful, but can we also have a "-nogen" switch so that a compile is done but no object files are created. Kind of like the "-c" switch which does a compile but no linking.

Then we can use "-deps=dep.txt -nogen" to get the dependency data so build tools can then work out what needs to actually be compiled. And in that vein, a hash (eg CRC32, MD5, SHA256) of the file's used by DMD would be nice to see in the 'deps' file. Would help build tools detect which files have been modified.

May I make a small syntax suggestion for the deps format. Instead of enclosing a path in parentheses, and using ':' as a field delimiter, have the first (and last) character of each line be the field delimiter to use in that line. The delimiter would be guaranteed to never be part of any of the fields' characters. That way, we don't need escape characters and parsing the text is greatly simplified.

Also, simplifying the paths by resolving the ".." and "." would be nice.

eg.

!std.stdio!c:\dmd\dmd\src\phobos\std\stdio.d!public!std.format!c:\dmd\dmd\src\phobos\std\format.d!

If this is ok can I submit a patch?

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell

On Sun, 05 Jul 2009 22:05:10 -0700, Walter Bright wrote:

> Something for everyone here.
> 
> http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.046.zip
> 
> http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.031.zip

One of the very much appreciated updates here is "Implicit integral conversions that could result in loss of significant bits are no longer allowed.". An excellent enhancement, thank you.

But I am confused as this below compiles without complaint...
-----------
import std.stdio;
void main()
{
   byte iii;
   ubyte uuu = 250;
   iii = uuu;
   writefln("%s %s", iii, uuu);
}
-----------

Output is ...
-6 250

But I expected the compiler to complain that an unsigned value cannot by implicitly converted to a signed value as that results in loss of *significant* bits.

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell

The deps thing comes from the LDC group. They've been relying on it as-is, so they'd need to agree on any changes.

Derek Parnell wrote:
> One of the very much appreciated updates here is "Implicit integral
> conversions that could result in loss of significant bits are no longer
> allowed.". An excellent enhancement, thank you.

Thank Andrei for that, he was the prime mover behind it.

> 
> But I am confused as this below compiles without complaint...
> -----------
> import std.stdio;
> void main()
> {
>    byte iii;
>    ubyte uuu = 250;
>    iii = uuu;
>    writefln("%s %s", iii, uuu);
> }
> -----------
> 
> Output is ...
> -6 250
> 
> But I expected the compiler to complain that an unsigned value cannot by
> implicitly converted to a signed value as that results in loss of
> *significant* bits.

We tried for a long time to come up with a sensible way to deal with the signed/unsigned dichotomy. We finally gave that up as unworkable. Instead, we opted for a method of significant bits, *not* how those bits are interpreted. -6 and 250 are the same bits in byte and ubyte, the difference is interpretation.

On Sun, 05 Jul 2009 23:35:24 -0700, Walter Bright wrote:

> Derek Parnell wrote:
>> One of the very much appreciated updates here is "Implicit integral conversions that could result in loss of significant bits are no longer allowed.". An excellent enhancement, thank you.
> 
> Thank Andrei for that, he was the prime mover behind it.

Yes, our English language is poor. I should have said "thank yous" ;-)

>> But I am confused as this below compiles without complaint...
>> -----------
>> import std.stdio;
>> void main()
>> {
>>    byte iii;
>>    ubyte uuu = 250;
>>    iii = uuu;
>>    writefln("%s %s", iii, uuu);
>> }
>> -----------
>> 
>> Output is ...
>> -6 250
>> 
>> But I expected the compiler to complain that an unsigned value cannot by implicitly converted to a signed value as that results in loss of *significant* bits.
> 
> We tried for a long time to come up with a sensible way to deal with the signed/unsigned dichotomy. We finally gave that up as unworkable. Instead, we opted for a method of significant bits, *not* how those bits are interpreted. -6 and 250 are the same bits in byte and ubyte, the difference is interpretation.

I am disappointed. I hope that you haven't stopped working on a solution to this though, as allowing D to silently permit bugs it could prevent is not something we are hoping for.

I can see that the argument so far hinges on the meaning of "significant". I was hoping that a 'sign' bit would have been significant.

As for "the same bits in X and Y, the different is interpretation", this is something that can be selective. For example ...

----------
   short iii;
   struct U {align (1) byte a; byte b;}
   U uuu;
   iii = uuu;
----------
The bits in 'uuu' can be accommodated in 'iii' so why not allow implicit conversion? Yes, that is a rhetorical question. Because we know that the struct means something different to the scalar 'short', conversion via bit-mapping is not going to be valid in most cases. However, we also know that a signed value is not the same as an unsigned value even though they have the same number of bits; that is the compiler already knows how to interpret those bits.

I'm struggling to see why the compiler cannot just disallow any signed<->unsigned implicit conversion? Is it a matter of backward compatibility again?


-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell

Walter Bright wrote:
> Daniel Keep wrote:
>> Ooooh... looks very nice.  Thanks again, Walter. :)
> 
> Actually, a lot of people worked on this release, not just me.
> 
>>
>> Incidentally, the links to Final Switch Statement and Case Range
>> Statement in the changelog for 2.031 are broken.

You quoted that but still missed that you've mixxed up your 'a href links with the display name'.

Thanks a lot for this release.