OK, so the current DMD version is 0.141.  As those of you (anybody still?) who follow the PPPRs would know, they normally come on the multiples of .10.  NTS I was going to do this when 0.140 was current, but 0.141 beat me to it.

http://www.wikiservice.at/wiki4d/wiki.cgi?PendingPeeves

With the break that was taken from developing the compiler in order to write Ddoc, there's relatively little to say this time around on top of the long list of issues raised in the last PPPR, nearly all of which are still issues.  Do read it if you haven't already - it goes into some depth of its own.

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/28449


For a change, most of the news (as opposed to olds) this time is positive.  Thomas's new development by the name of Torture is something that we can look forward to helping even more with getting (DM)D up to scratch.

For once, something's happening in the department of things that it isn't clear if are bugs.  Kept rather quiet was the change in the ~ operator so that it now works in line with ~= to concatenate an array with a single element.  I suppose all that remains is for it to be documented.

Whenever I make a contribution, it seems I'm always wondering when/if it's going to be checked in.  Fortunately this one made it in the end:

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/28264

Aside from a few bits of my contribution that haven't been included in what was checked in, I'm wondering how near we are to having "Some essential conversions between character encodings" universally.  The std.windows.charset module is designed to be a "simple operations should be simple" approach to converting strings in order to interface with the Windows API.  The question remains: Do we need something similar for other platforms?  Which other OSs that are modern enough for D to support do and don't natively support Unicode for everything?


That's about it for another issue.  D is certainly the future, and my hopes are still set high for it to be a good future.

Stewart.

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

My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

Stewart Gordon wrote:
> 
> For once, something's happening in the department of things that it isn't clear if are bugs.  Kept rather quiet was the change in the ~ operator so that it now works in line with ~= to concatenate an array with a single element.  I suppose all that remains is for it to be documented.

I think this is intended, since I believe values are considered one-element arrays for function overloading.  ie.

void fn( char[] str ) {}
fn( 'a' ); // doesn't this work?

> Aside from a few bits of my contribution that haven't been included in what was checked in, I'm wondering how near we are to having "Some essential conversions between character encodings" universally.  The std.windows.charset module is designed to be a "simple operations should be simple" approach to converting strings in order to interface with the Windows API.  The question remains: Do we need something similar for other platforms?  Which other OSs that are modern enough for D to support do and don't natively support Unicode for everything?

Good question.  I had thought that Unix platforms mostly supported Unicode in UTF-32 format, but I don't know a lot about internationalization.


Sean

Sean Kelly wrote:
> Stewart Gordon wrote:
> 
>>
>> For once, something's happening in the department of things that it isn't clear if are bugs.  Kept rather quiet was the change in the ~ operator so that it now works in line with ~= to concatenate an array with a single element.  I suppose all that remains is for it to be documented.
> 
> 
> I think this is intended, since I believe values are considered one-element arrays for function overloading.  ie.
> 
> void fn( char[] str ) {}
> fn( 'a' ); // doesn't this work?

"function test.fn (char[]) does not match argument types (char)
cannot implicitly convert expression (97) of type char to char[]
cannot cast char to char[]"

/Oskar

Oskar Linde wrote:
> Sean Kelly wrote:
>> Stewart Gordon wrote:
>>
>>>
>>> For once, something's happening in the department of things that it isn't clear if are bugs.  Kept rather quiet was the change in the ~ operator so that it now works in line with ~= to concatenate an array with a single element.  I suppose all that remains is for it to be documented.
>>
>>
>> I think this is intended, since I believe values are considered one-element arrays for function overloading.  ie.
>>
>> void fn( char[] str ) {}
>> fn( 'a' ); // doesn't this work?
> 
> "function test.fn (char[]) does not match argument types (char)
> cannot implicitly convert expression (97) of type char to char[]
> cannot cast char to char[]"

Darn.  I could have sworn that was legal.  Ah well.


Sean