Hello,

Is it a bug that i can't do like this:
int[string] x = ["11":11, "1":1];
Error: cannot implicitly convert expression ("1") of type invariant(char[1u]) to invariant(char[2u])

dmd-2.0.16

Thanks

"baleog" wrote
> Hello,
>
> Is it a bug that i can't do like this:
> int[string] x = ["11":11, "1":1];
> Error: cannot implicitly convert expression ("1") of type
> invariant(char[1u]) to invariant(char[2u])

It's a foolish issue with D and static arrays. (seriously, I must see about 1 post a week asking why static arrays don't work right, shouldn't this be a priority?)

Try this workaround:

int[string] x = ["11"[]:11, "1":1];

-Steve

baleog wrote:
> Hello,
> 
> Is it a bug that i can't do like this:
> int[string] x = ["11":11, "1":1];
> Error: cannot implicitly convert expression ("1") of type invariant(char[1u]) to invariant(char[2u])
> 
> dmd-2.0.16
> 
> Thanks
No. You need to tell the compiler that you're using dynamic, not static arrays. Just add [] after the first entry.

int[string] x = ["11"[]:11, "1":1];

On Mon, 14 Jul 2008 10:07:15 -0400, baleog wrote:

> Hello,
> 
> Is it a bug that i can't do like this: int[string] x = ["11":11, "1":1];
> Error: cannot implicitly convert expression ("1") of type
> invariant(char[1u]) to invariant(char[2u])
> 
> dmd-2.0.16
> 
> Thanks

DMD deduce the type of the literal from it's first element.
int[string] x = [cast(char[]) "11":11, "1":1];
would work. "11"[] is a shortcut.

Imho, the left side type declaration should be honored by the compiler by adding a cast to the first literal element after initial parsing.

"Don" <nospam@nospam.com.au> wrote in message news:g5fmrg$e7o$1@digitalmars.com...
> baleog wrote:
>> Hello,
>>
>> Is it a bug that i can't do like this:
>> int[string] x = ["11":11, "1":1];
<snip>
> No. You need to tell the compiler that you're using dynamic, not static arrays. Just add [] after the first entry.
>
> int[string] x = ["11"[]:11, "1":1];

If it isn't a bug, it's certainly a design silliness:
- that array literals take their type from the first element, rather than the lowest common denominator
- that there aren't static initialisers for AAs as there are for LAs

Stewart.

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

Stewart Gordon a écrit :
> "Don" <nospam@nospam.com.au> wrote in message news:g5fmrg$e7o$1@digitalmars.com...
>> baleog wrote:
>>> Hello,
>>>
>>> Is it a bug that i can't do like this:
>>> int[string] x = ["11":11, "1":1];
> <snip>
>> No. You need to tell the compiler that you're using dynamic, not static arrays. Just add [] after the first entry.
>>
>> int[string] x = ["11"[]:11, "1":1];
> 
> If it isn't a bug, it's certainly a design silliness:
> - that array literals take their type from the first element, rather than the lowest common denominator
> - that there aren't static initialisers for AAs as there are for LAs
> 
> Stewart.
> 

What use has a static array in comparison to a dynamic array?

Stewart Gordon wrote:
> "Don" <nospam@nospam.com.au> wrote in message news:g5fmrg$e7o$1@digitalmars.com...
>> baleog wrote:
>>> Hello,
>>>
>>> Is it a bug that i can't do like this:
>>> int[string] x = ["11":11, "1":1];
> <snip>
>> No. You need to tell the compiler that you're using dynamic, not static arrays. Just add [] after the first entry.
>>
>> int[string] x = ["11"[]:11, "1":1];
> 
> If it isn't a bug, it's certainly a design silliness:
> - that array literals take their type from the first element, rather than the lowest common denominator

Amen.  [1,2,3.0,4] should be treated as an array of doubles.

> - that there aren't static initialisers for AAs as there are for LAs

Yeh, that sucks too.  Although I can see it might be tricky to get working.

Also sucks that initializers for structs only work for static structs. That one doesn't seem like it should be so hard to fix, but there must be some catch that prevented W. from throwing it in.

--bb

Reply to Stewart,

> "Don" <nospam@nospam.com.au> wrote in message
> news:g5fmrg$e7o$1@digitalmars.com...
> 
>> baleog wrote:
>> 
>>> Hello,
>>> 
>>> Is it a bug that i can't do like this:
>>> int[string] x = ["11":11, "1":1];
> <snip>
> 
>> No. You need to tell the compiler that you're using dynamic, not
>> static arrays. Just add [] after the first entry.
>> 
>> int[string] x = ["11"[]:11, "1":1];
>> 
> If it isn't a bug, it's certainly a design silliness:
> - that array literals take their type from the first element, rather
> than
> the lowest common denominator
> - that there aren't static initialisers for AAs as there are for LAs
> Stewart.
> 

I think much of this might come from the need to be able to eyeball parse the code

auto a = [ .... 16 different function calls ...];// what is the type of a?

I think as long as the type of an array literal isn't from the type of the assigned the current solution is about as good as it will get.

BCS wrote:
> Reply to Stewart,
> 
>> "Don" <nospam@nospam.com.au> wrote in message
>> news:g5fmrg$e7o$1@digitalmars.com...
>>
>>> baleog wrote:
>>>
>>>> Hello,
>>>>
>>>> Is it a bug that i can't do like this:
>>>> int[string] x = ["11":11, "1":1];
>> <snip>
>>
>>> No. You need to tell the compiler that you're using dynamic, not
>>> static arrays. Just add [] after the first entry.
>>>
>>> int[string] x = ["11"[]:11, "1":1];
>>>
>> If it isn't a bug, it's certainly a design silliness:
>> - that array literals take their type from the first element, rather
>> than
>> the lowest common denominator
>> - that there aren't static initialisers for AAs as there are for LAs
>> Stewart.
>>
> 
> I think much of this might come from the need to be able to eyeball parse the code
> 
> auto a = [ .... 16 different function calls ...];// what is the type of a?

Who cares what the type is as long as it's sufficient to hold the results of all those function calls?  If you cared you wouldn't have been using auto there.

> I think as long as the type of an array literal isn't from the type of the assigned the current solution is about as good as it will get.

Polysemous vals may help here if they ever materialize.

Its not a huge issue in the grand scheme of things, but still feels slightly sub-optimal currently.  NumPy arrays use the rule "array type is the minimal type that can hold all elements" and it seems to work out very well in practice.  Seems to be the path of least surprise for this problem.

--bb

"BCS" <ao@pathlink.com> wrote in message news:55391cb32f3218cab3ecfa6cf778@news.digitalmars.com...
<snip>
> I think much of this might come from the need to be able to eyeball parse the code
>
> auto a = [ .... 16 different function calls ...];// what is the type of a?

But we're not dealing with an auto here.  We're dealing with an int[string]. With autotype declarations, it's necessary to treat initialisers as expressions.  When the type is specified, arrays can use static initialisers.

> I think as long as the type of an array literal isn't from the type of the assigned the current solution is about as good as it will get.

No, as long as the compiler treats the original attempt as an array literal rather than as a static initialiser.

Stewart.

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