In article <caj05a$1r29$1@digitaldaemon.com>, Walter wrote:
> Consider:
>     void foo(int[]);
>     void foo(uint[]);
>     void bar(int, ...);
> and:
>     foo([1,2,3]);
> which foo is called?
>     bar(i, [1,3,4]);
> what type of array is passed?

The same issue exists with:

    void foo(int);
    void foo(uint);
    void var(int, ...);

    foo(1);
    foo(i, 1);

I'd really have arrays behave the same way as other basic types do.

>>   anotherfunc(4);  // '4' is a float, no?
> 
> No, '4' is an int. It gets implicitly converted to a float by matching it against the argument of anotherfunc. Importantly, the types are determined *before* overload function matching is done, otherwise it could never figure out which function to call.

So, similar rules are needed for arrays as now exist for arithmetic types.

There probably needs to be a rule or two if there are multiple types inside an array literal:

    [1, 2, 3]; // array of int
    [1u, 2, 3]; // array of uint
    [1, 2, 3.0]; // array of double
    [1, 2.0f, 3.0]; // array of double

There's just the issue of deciding a proper type that all members can be promoted to.

Array literals and arrays should be castable:

    float[] fs;
    int[] is;
    fs[] = is; // cast each member - at least you should be able to do this
               // because you can do:
    static float[] f2 = [1,2,3];

So, any issues in this line of thought? (I'd guess plenty, but
currently none comes to mind)

-Antti


-- 
I will not be using Plan 9 in the creation of weapons of mass destruction to be used by nations other than the US.

Russ Lewis wrote:
<snip>
> Good point.  I'm sort of liking the suggestions that are something like
>     float[] [ 1, 2.3, 4 ]
> both because
> a) They are non-ambiguous
<snip>

Which particular suggestions that are something like that are you referring to here?

As said before, that one would certainly see confusion with an array of length [1, 2.3, 4] of arrays of floats.

The DMD 0.92 change from [ Expression ] to [ AssignExpression ] is no solution, since one-element arrays are perfectly valid.  Also, the comma-delimited list here'll mean something new when/if Norbert's MDAs are implemented.

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment.  Please keep replies on the 'group where everyone may benefit.

In article <cajj1s$2sqp$3@digitaldaemon.com>, Walter says...
>
>
>"Regan Heath" <regan@netwin.co.nz> wrote in message news:opr9kj4wsq5a2sq9@digitalmars.com...
>> >> True, ok, how bout:
>> >>
>> >> func( cast(int[]) [0,1,2,3] );
>> >>
>> >> ?
>> >
>> > Ugly <g>.
>>
>> True, but is it ambiguous?
>
>No, syntactically it would work. It's just too many (), too many [], etc.,
>for the old eyes.

How about:

int[ int: 0, 1, 2, 3, 5, byte: 0xFF, 0x33 ]

.. Which would convert to int[].


Then, for classes:

Interface I { ... }
class A : I { A(int x); ... }
class B : A { B(int x, int y); ... }


I[ A:(1), 2, 3, B:(4,0), (5,2), (6,101) ]

In other words, the elements seperated by "," are initializer lists; if they are not in parens, they are single-argument versions.  The "A:" indicates we are switching to type A.  Concise, flexible, and scalable (it scales from primitive to complex types).

And only a little ugly.

Kevin

In article <cak7co$r3h$1@digitaldaemon.com>, Roberto Mariottini wrote:
> In article <cajaj5$2e27$1@digitaldaemon.com>, Walter says...
>>"Regan Heath" <regan@netwin.co.nz> wrote in message news:opr9kb88nu5a2sq9@digitalmars.com...
> [...]
>>> True, ok, how bout:
>>>
>>> func( cast(int[]) [0,1,2,3] );
> 
> func ( int[] : [0, 1 , 2, 3] );

func( [int: 0, 1, 2, 3] );


-Antti

-- 
I will not be using Plan 9 in the creation of weapons of mass destruction to be used by nations other than the US.

>> The fundamental problem with array literals is the bottom-up nature of the typing of expressions in the semantic phase of compilation. Is [0,1,2,3] an array of chars, bytes, ints, longs, floats, ... ?
>> 
>> This is not an easy problem to solve, which is why it'll be deferred to a 2.0 feature.
>
>char[4] A = [0,1,2,3]; // chars
>byte[4] A = [0,1,2,3]; // bytes
>int[4] A = [0,1,2,3]; // ints
>long[4] A = [0,1,2,3]; // longs
>float[4] A = [0,1,2,3]; // floats
>
>What don't I understand about this 'difficult problem'?

typeof([0,1,2,3]) foo = [0,1,2,3];

foo is of type ...????

>It's also ambiguous:
>
>    foo[0,1,2,3]
>
>is this an array of foo's, or is foo an array indexed by [0,1,2,3]?


To me [foo: 0,1,2,3] looks cooler anyway :)

>"Regan Heath" <regan@netwin.co.nz> wrote in message news:opr9kj4wsq5a2sq9@digitalmars.com...
>> >> True, ok, how bout:
>> >>
>> >> func( cast(int[]) [0,1,2,3] );
>> >>
>> >> ?
>> >
>> > Ugly <g>.
>>
>> True, but is it ambiguous?
>
>No, syntactically it would work. It's just too many (), too many [], etc.,
>for the old eyes.

The [type: 0,1,2,3] variant looks cool to me. We could use something similar for struct-literals: {type: 0,1,2,3}

"Matthias Becker" <Matthias_member@pathlink.com> wrote in message news:ccu2q1$1p9f$1@digitaldaemon.com...
> >"Regan Heath" <regan@netwin.co.nz> wrote in message news:opr9kj4wsq5a2sq9@digitalmars.com...
> >> >> True, ok, how bout:
> >> >>
> >> >> func( cast(int[]) [0,1,2,3] );
> >> >>
> >> >> ?
> >> >
> >> > Ugly <g>.
> >>
> >> True, but is it ambiguous?
> >
> >No, syntactically it would work. It's just too many (), too many [],
etc.,
> >for the old eyes.
>
> The [type: 0,1,2,3] variant looks cool to me. We could use something
similar for
> struct-literals: {type: 0,1,2,3}
>

struct already has {field_name: 3} which would be ambiguous if a type could
be there. Actually, using the template syntax doesn't look like it'd be a
problem because of the different brackets:
   int![1, 2, 3]
   my_struct!{3}
You might get all confused with something like this, though:
   my_template!(int,int[1])(ints[1],int![1]);
I don't know ;)

Matthias Becker wrote:
> typeof([0,1,2,3]) foo = [0,1,2,3];
> 
> foo is of type ...????

In my little world, foo in that case would be of type byte, as that's the largest type neccessary to store all the values and to which all the values are compatable.  If, say, 2 were 2.15, then it would be an array of floats, for the same reasons.  Or maybe it could be an array of ints, with int simply being default unless uint, long, or ulong is required. Ah heck, I think I prefer the [type: x,y,z...] format.

-Chris S.
-Invironz

Matthias Becker wrote:
> typeof([0,1,2,3]) foo = [0,1,2,3];
> 
> foo is of type ...????

This is a sticky problem, but one that I assume is already more or less solved.  What happens when you do this, very similar code: ?

	typeof(0) bar = 0;