.init property for char[] type

[Jeremie Pelletier]

Michel Fortin wrote:
> On 2009-09-22 18:08:24 -0400, Justin Johansson 
> <procode at adam-dott-com.au> said:
> 
>>> You forgot
>>>
>>> char.init 0xFF
>>> wchar.init 0xFFFF
>>> dchar.init 0xFFFFFFFF
>>>
>>> Andrei
>>
>> Shhh; don't tell anybody; I left those out of the quiz to weigh in 
>> favour of zero bit pattern init values.
>> (This trick, i.e. omitting information, is one I learned from the 
>> Ministries of Statistics and (un)Employment.)
>>
>> Seriously though, I imagine the D design choices to be influenced by 
>> the desire to propagate NaN and invalid UTF in their respective cases 
>> so as to detect uninitialized data errors.  Hmm, guess one could argue 
>> the init issue for eons.
> 
> Well, I see this as a problem because I've often relied on default 
> initialization being zero in my algorithms. I was bitten once when my 
> algorithm worked perfectly with char but not with wchar. Turns out that 
> char.init == 0 (contraty to what Andrei wrote) and wchar.init == 0xFFFF.
> 

pragma(msg, char.init.stringof);

outputs '\xff' in D2, wchar and dchar have the same initializer: 
'\U0000FFFF'.

If you rely on char initializer being the null character, use char c = 
0, or else your char gets initialized to an invalid character, just like 
  floats get initialized to nan, other types have the invalid value as 
either null or do not have an invalid value and use 0.