http://d.puremagic.com/issues/show_bug.cgi?id=1486

           Summary: Can't implicitly convert char[][] to const(char)[][]
           Product: D
           Version: 2.004
          Platform: PC
        OS/Version: Windows
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: bugzilla@digitalmars.com
        ReportedBy: reiner.pope@gmail.com


The following code fails to compile, with error "cannot implicitly convert
expression (a) of type char[][] to const(char)[][]". However, it appears to be
a valid operation.

void main() {
    char[][] a;
    string[] b = a;
}


-- 

d-bugmail@puremagic.com wrote:
> http://d.puremagic.com/issues/show_bug.cgi?id=1486
> 
>            Summary: Can't implicitly convert char[][] to const(char)[][]
>            Product: D
>            Version: 2.004
>           Platform: PC
>         OS/Version: Windows
>             Status: NEW
>           Severity: normal
>           Priority: P2
>          Component: DMD
>         AssignedTo: bugzilla@digitalmars.com
>         ReportedBy: reiner.pope@gmail.com
> 
> 
> The following code fails to compile, with error "cannot implicitly convert
> expression (a) of type char[][] to const(char)[][]". However, it appears to be
> a valid operation.
> 
> void main() {
>     char[][] a;
>     string[] b = a;
> }
> 
> 

Finally! I actually knew about this bug some time ago (2-4 months), when I updated some of my D shell scripts to D 2.0. I purposefully didn't report since I wanted to see how long it would take until someone else did. It seemed such a common problem (I have very little D code written, yet I stumbled upon it quickly), that I'm somewhat surprised it took this long for someone to report it. Isn't there that many people using D2.0 features or what?

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Bruno Medeiros wrote:
> d-bugmail@puremagic.com wrote:
>> http://d.puremagic.com/issues/show_bug.cgi?id=1486
>>
>>            Summary: Can't implicitly convert char[][] to const(char)[][]
>>            Product: D
>>            Version: 2.004
>>           Platform: PC
>>         OS/Version: Windows
>>             Status: NEW
>>           Severity: normal
>>           Priority: P2
>>          Component: DMD
>>         AssignedTo: bugzilla@digitalmars.com
>>         ReportedBy: reiner.pope@gmail.com
>>
>>
>> The following code fails to compile, with error "cannot implicitly convert
>> expression (a) of type char[][] to const(char)[][]". However, it appears to be
>> a valid operation.
>>
>> void main() {
>>     char[][] a;
>>     string[] b = a;
>> }
>>
>>
> 
> Finally! I actually knew about this bug some time ago (2-4 months), when I updated some of my D shell scripts to D 2.0. I purposefully didn't report since I wanted to see how long it would take until someone else did. It seemed such a common problem (I have very little D code written, yet I stumbled upon it quickly), that I'm somewhat surprised it took this long for someone to report it. Isn't there that many people using D2.0 features or what?
> 

I'd like to do more in D 2.0, but if the libraries I need aren't ported, it's either spend a lot of time porting them myself, or stick with D 1.  Right now D1 seems the better option.  But since D1 isn't getting new features I suspect there will come a point when D2 gets something so utterly cool that it's worth doing whatever it takes to use it, including maintaining private 2.0 forks of other people's libraries.  Of course by then they might have already ported... so I might as well wait.

--bb

Bill Baxter wrote:
> Bruno Medeiros wrote:
>> d-bugmail@puremagic.com wrote:
>>> http://d.puremagic.com/issues/show_bug.cgi?id=1486
>>>
>>>            Summary: Can't implicitly convert char[][] to const(char)[][]
>>>            Product: D
>>>            Version: 2.004
>>>           Platform: PC
>>>         OS/Version: Windows
>>>             Status: NEW
>>>           Severity: normal
>>>           Priority: P2
>>>          Component: DMD
>>>         AssignedTo: bugzilla@digitalmars.com
>>>         ReportedBy: reiner.pope@gmail.com
>>>
>>>
>>> The following code fails to compile, with error "cannot implicitly convert
>>> expression (a) of type char[][] to const(char)[][]". However, it appears to be
>>> a valid operation.
>>>
>>> void main() {
>>>     char[][] a;
>>>     string[] b = a;
>>> }
>>>
>>>
>>
>> Finally! I actually knew about this bug some time ago (2-4 months), when I updated some of my D shell scripts to D 2.0. I purposefully didn't report since I wanted to see how long it would take until someone else did. It seemed such a common problem (I have very little D code written, yet I stumbled upon it quickly), that I'm somewhat surprised it took this long for someone to report it. Isn't there that many people using D2.0 features or what?
>>
> 
> I'd like to do more in D 2.0, but if the libraries I need aren't ported, it's either spend a lot of time porting them myself, or stick with D 1.  Right now D1 seems the better option.  But since D1 isn't getting new features I suspect there will come a point when D2 gets something so utterly cool that it's worth doing whatever it takes to use it, including maintaining private 2.0 forks of other people's libraries.  Of course by then they might have already ported... so I might as well wait.

Oh, and I should also mention that the one thing I really wanted const for originally (passing structs as const ref), still crashes the compiler in 2.004.

It was demonstrated pretty clearly in the ray-tracer someone ported from C++ to D that passing structs by value has a significantly detrimental impact on performance.  Passing them by plain ref improves the performance but it sends the wrong message to the user and also prevents use with non-l-values such as struct literals.

--bb

Bill Baxter wrote:
[snip]
> I'd like to do more in D 2.0, but if the libraries I need aren't ported, it's either spend a lot of time porting them myself, or stick with D 1.  Right now D1 seems the better option.  But since D1 isn't getting new features I suspect there will come a point when D2 gets something so utterly cool that it's worth doing whatever it takes to use it, including maintaining private 2.0 forks of other people's libraries.  Of course by then they might have already ported... so I might as well wait.

Bill,

If there were a clean way to alias or typedef or macro the D2 const features (within D1) then Tango and other libraries would quickly become available for D2. In other words, the const features of D2 would have to be effectively ignored by the D1 compiler (through whatever means), and the use of those features in D2 would have to be 'adjustable' in a quick and easy manner (to adhere to syntactic changes). Macros might be ideal for such a notion?

Without the ability to retain a single body of source across both D versions, and with the syntax of D2 const evolving over time, there's little impetus to migrate a library right now

Oops, I didn't meant for my comment to go into the bugzilla.


-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Bruno Medeiros wrote:
> Oops, I didn't meant for my comment to go into the bugzilla.

It looks like someone else decided to be 'helpful' and added it to bugzilla for you, sans your sig.  Or are you and Jari-Matti one and the same?

--bb

Bill Baxter wrote:

> Bruno Medeiros wrote:
>> Oops, I didn't meant for my comment to go into the bugzilla.
> 
> It looks like someone else decided to be 'helpful' and added it to bugzilla for you, sans your sig.  Or are you and Jari-Matti one and the same?
> 
> --bb

I believe stuff are hooked up such that bugzilla picks it up as a reply if it contains the bugzilla part of the subject.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango

kris wrote:
> Bill Baxter wrote:
> [snip]
>> I'd like to do more in D 2.0, but if the libraries I need aren't ported, it's either spend a lot of time porting them myself, or stick with D 1.  Right now D1 seems the better option.  But since D1 isn't getting new features I suspect there will come a point when D2 gets something so utterly cool that it's worth doing whatever it takes to use it, including maintaining private 2.0 forks of other people's libraries.  Of course by then they might have already ported... so I might as well wait.
> 
> Bill,
> 
> If there were a clean way to alias or typedef or macro the D2 const features (within D1) then Tango and other libraries would quickly become available for D2. In other words, the const features of D2 would have to be effectively ignored by the D1 compiler (through whatever means), and the use of those features in D2 would have to be 'adjustable' in a quick and easy manner (to adhere to syntactic changes). Macros might be ideal for such a notion?

Macros probably won't be a solution because D1 won't have them.

I think we're stuck with version(D_Version2) + string mixin as the primary tools.

> Without the ability to retain a single body of source across both D versions, and with the syntax of D2 const evolving over time, there's little impetus to migrate a library right now

As long as you're willing to at least accept patches that provide backwards-compatible D2 support, nobody has any business complaining about that.

But that doesn't change the fact that "lack of libraries" is still the main reason I haven't moved myself over to D2.0 yet. :-)

--bb

Bill Baxter wrote:
> kris wrote:
>> Bill Baxter wrote:
>> [snip]
>>> I'd like to do more in D 2.0, but if the libraries I need aren't ported, it's either spend a lot of time porting them myself, or stick with D 1.  Right now D1 seems the better option.  But since D1 isn't getting new features I suspect there will come a point when D2 gets something so utterly cool that it's worth doing whatever it takes to use it, including maintaining private 2.0 forks of other people's libraries.  Of course by then they might have already ported... so I might as well wait.
>>
>> Bill,
>>
>> If there were a clean way to alias or typedef or macro the D2 const features (within D1) then Tango and other libraries would quickly become available for D2. In other words, the const features of D2 would have to be effectively ignored by the D1 compiler (through whatever means), and the use of those features in D2 would have to be 'adjustable' in a quick and easy manner (to adhere to syntactic changes). Macros might be ideal for such a notion?
> 
> Macros probably won't be a solution because D1 won't have them.

I'm (quietly) suggesting that D1 gain macro support in order to effectively migrate libs over to D2, stimulating adoption of D2 itself ;)