www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - The VI PPPR (Pending Peeves Progress Review)

reply Stewart Gordon <smjg_1998 yahoo.com> writes:
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.
Dec 05 2005
parent reply Sean Kelly <sean f4.ca> writes:
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
Dec 05 2005
parent reply Oskar Linde <oskar.lindeREM OVEgmail.com> writes:
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
Dec 05 2005
parent Sean Kelly <sean f4.ca> writes:
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
Dec 05 2005