Lars Ivar Igesund wrote:
> 
> Tango 0.99.7 doesn't support DMD 1.037 - either use DMD 1.033 or check out Tango trunk.
> 

Say what you will, I got it to work :)

I also experienced the crash on 1.030, 1.033, and 1.035 variously on linux and windows, so 1.037 was just to see if it had been fixed by then. Just to be thorough.

On Tue, Dec 9, 2008 at 12:00 PM, Ellery Newcomer <ellery-newcomer@utulsa.edu> wrote:
> Derek Parnell wrote:
>  > It is not a bug. A string literal such as "true" is a char[] type (UTF8),
>>
>> and the compiler will not implicitly convert UTF8 to UTF16 (wchar[]).
>
> Which would then beg the obvious
>
> wchar[] w = "true";

It's a sort of special case.  String literals are, by default, UTF-8. But if you use a string literal in a situation where it can only be UTF-16 or UTF-32, it's automatically converted.

However if a string literal is used in a context where it can be multiple encodings, an error results:

void foo(char[] s) {}
void foo(wchar[] s) {}

foo("hello") fails because string literals are implicitly convertible to both char[] and wchar[], so you have to append either a c or a w to the literal.

As for why 'wchar[] s = true ? "true" : "false"' doesn't work, it's because the initializer expression is semantically analyzed before looking at the destination type.  The type of the initializer is determined to be char[], which is not implicitly convertible to wchar[].

It can obviously be argued that since the operands of ?: are constant, the compiler _could_ figure out that they should be of type wchar[], but that would make the semantic analysis more complicated, and since appending 'w' to the strings is far easier, it probably won't change any time soon.

Jarrett Billingsley wrote:
> On Tue, Dec 9, 2008 at 12:00 PM, Ellery Newcomer
> <ellery-newcomer@utulsa.edu> wrote:
>> Derek Parnell wrote:
>>  > It is not a bug. A string literal such as "true" is a char[] type (UTF8),
>>> and the compiler will not implicitly convert UTF8 to UTF16 (wchar[]).
>> Which would then beg the obvious
>>
>> wchar[] w = "true";
> 
> It's a sort of special case.  String literals are, by default, UTF-8.
> But if you use a string literal in a situation where it can only be
> UTF-16 or UTF-32, it's automatically converted.
> 
> However if a string literal is used in a context where it can be
> multiple encodings, an error results:
> 
> void foo(char[] s) {}
> void foo(wchar[] s) {}
> 
> foo("hello") fails because string literals are implicitly convertible
> to both char[] and wchar[], so you have to append either a c or a w to
> the literal.
> 
> As for why 'wchar[] s = true ? "true" : "false"' doesn't work, it's
> because the initializer expression is semantically analyzed before
> looking at the destination type.  The type of the initializer is
> determined to be char[], which is not implicitly convertible to
> wchar[].
> 
> It can obviously be argued that since the operands of ?: are constant,
> the compiler _could_ figure out that they should be of type wchar[],
> but that would make the semantic analysis more complicated, and since
> appending 'w' to the strings is far easier, it probably won't change
> any time soon.

I think the compiler should be smarter. I understand that the compiler should be simple to allow other implementations to be done easily. But... I don't think that's true. A D compiler must already instantiate templates and do compile-time evaluation. Now tell me that's easy! :-P

After all, how many compiler implementors could there be? And how many users of the language? The language should focus on making it very easy to program and to avoid this kinds of pitfalls.

"Jarrett Billingsley" wrote
> It can obviously be argued that since the operands of ?: are constant, the compiler _could_ figure out that they should be of type wchar[], but that would make the semantic analysis more complicated, and since appending 'w' to the strings is far easier, it probably won't change any time soon.

Looks like another job for Captain Polysemy!

Ellery Newcomer wrote:
> Hello all,
> 
> I began learning D a few months ago, and now I have a question about cyclic dependencies (and some random whining).
> 
> I come from a java background and have had no serious exposure to C++. In java, cyclic dependencies are legit to the best of my knowledge. I don't know about C++, thus I don't know about D.
> 
> When I first started learning D I decided that a good way to learn it would be by porting a popular java api (mind, I didn't say intelligent), which came complete with a few cyclic dependencies. At the moment, I'm using GDC, and it refuses to swallow cyclic dependencies. The compiler doesn't complain, but it throws a runtime exception. I can break the dependency loops and GDC will work just fine, but what I'm wondering is whether it is standard that the dependency hierarchy be acyclic, or is this some quirk of GDC, or is it more likely that there is something weird going on in my java-to-D translation.
> 
> Also, I would be trying to compile with DMD, but I have evidently managed to crash the compiler, and I don't know if it's DMD's fault or mine. It reports an Internal Error in e2ir.c at line 3904. (not being a C++ guru, the line "assert(n2->Enumbytes);" doesn't mean much to me)
> That was with DMD 1.037, Tango 0.997, and using dsss to build.
> 
> On an unrelated note, is this code supposed to be incorrect?
> 
> wchar[] w = (true)? "true":"false";
> 
> --> Error: cannot implicitly convert expression ("true") of type char[] to wchar[]
> 
> or should it be reported as a bug?

Today I completed a simple code analysis tool for D. There be 91 cyclic dependencies spread among 36 files in my project. Not as bad as I thought it would be.