On Mon, 14 Jun 2004 15:32:29 +1000, Matthew <admin@stlsoft.dot.dot.dot.dot.org> wrote:
> "Regan Heath" <regan@netwin.co.nz> wrote in message
> news:opr9kj4wsq5a2sq9@digitalmars.com...
>> On Sun, 13 Jun 2004 21:41:01 -0700, Walter <newshound@digitalmars.com>
>> wrote:
>> > "Regan Heath" <regan@netwin.co.nz> wrote in message
>> > news:opr9kb88nu5a2sq9@digitalmars.com...
>> >> On Sun, 13 Jun 2004 18:43:37 -0700, Walter 
>> <newshound@digitalmars.com>
>> >> wrote:
>> >> > "Vathix" <vathixSpamFix@dprogramming.com> wrote in message
>> >> > news:cain1m$1eit$1@digitaldaemon.com...
>> >> >> >     func(int[0, 1, 2, 3]);
>> >> >>
>> >> >> This one looks pretty cool.
>> >> >
>> >> > 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]?
>> >>
>> >>
>> >> True, ok, how bout:
>> >>
>> >> func( cast(int[]) [0,1,2,3] );
>> >>
>> >> ?
>> >
>> > Ugly <g>.
>>
>> True, but is it ambiguous?
>
> Of course.

? if it's ambiguous then Walter cannot use this syntax for array literals. Didn't you just say:

"Not that ugly. And if it gives us array literals, it'd be well worth it."

> It's an array of ints. In fact, you could specify other things in
> there, and rely on the implicit conversions, just as with any other variables.

Regan

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

"Regan Heath" <regan@netwin.co.nz> wrote in message news:opr9kkrudn5a2sq9@digitalmars.com...
> On Mon, 14 Jun 2004 15:32:29 +1000, Matthew <admin@stlsoft.dot.dot.dot.dot.org> wrote:
> > "Regan Heath" <regan@netwin.co.nz> wrote in message news:opr9kj4wsq5a2sq9@digitalmars.com...
> >> On Sun, 13 Jun 2004 21:41:01 -0700, Walter <newshound@digitalmars.com> wrote:
> >> > "Regan Heath" <regan@netwin.co.nz> wrote in message news:opr9kb88nu5a2sq9@digitalmars.com...
> >> >> On Sun, 13 Jun 2004 18:43:37 -0700, Walter
> >> <newshound@digitalmars.com>
> >> >> wrote:
> >> >> > "Vathix" <vathixSpamFix@dprogramming.com> wrote in message news:cain1m$1eit$1@digitaldaemon.com...
> >> >> >> >     func(int[0, 1, 2, 3]);
> >> >> >>
> >> >> >> This one looks pretty cool.
> >> >> >
> >> >> > 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]?
> >> >>
> >> >>
> >> >> True, ok, how bout:
> >> >>
> >> >> func( cast(int[]) [0,1,2,3] );
> >> >>
> >> >> ?
> >> >
> >> > Ugly <g>.
> >>
> >> True, but is it ambiguous?
> >
> > Of course.
>
> ? if it's ambiguous then Walter cannot use this syntax for array literals. Didn't you just say:
>
> "Not that ugly. And if it gives us array literals, it'd be well worth it."
>
> > It's an array of ints. In fact, you could specify other things in there, and rely on the implicit conversions, just as with any other variables.

Sorry, I read your "True, but is it ambiguous?" as "True, but is it unambiguous?"

Doh!

On Mon, 14 Jun 2004 15:45:39 +1000, Matthew <admin@stlsoft.dot.dot.dot.dot.org> wrote:

> "Regan Heath" <regan@netwin.co.nz> wrote in message
> news:opr9kkrudn5a2sq9@digitalmars.com...
>> On Mon, 14 Jun 2004 15:32:29 +1000, Matthew
>> <admin@stlsoft.dot.dot.dot.dot.org> wrote:
>> > "Regan Heath" <regan@netwin.co.nz> wrote in message
>> > news:opr9kj4wsq5a2sq9@digitalmars.com...
>> >> On Sun, 13 Jun 2004 21:41:01 -0700, Walter 
>> <newshound@digitalmars.com>
>> >> wrote:
>> >> > "Regan Heath" <regan@netwin.co.nz> wrote in message
>> >> > news:opr9kb88nu5a2sq9@digitalmars.com...
>> >> >> On Sun, 13 Jun 2004 18:43:37 -0700, Walter
>> >> <newshound@digitalmars.com>
>> >> >> wrote:
>> >> >> > "Vathix" <vathixSpamFix@dprogramming.com> wrote in message
>> >> >> > news:cain1m$1eit$1@digitaldaemon.com...
>> >> >> >> >     func(int[0, 1, 2, 3]);
>> >> >> >>
>> >> >> >> This one looks pretty cool.
>> >> >> >
>> >> >> > 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]?
>> >> >>
>> >> >>
>> >> >> True, ok, how bout:
>> >> >>
>> >> >> func( cast(int[]) [0,1,2,3] );
>> >> >>
>> >> >> ?
>> >> >
>> >> > Ugly <g>.
>> >>
>> >> True, but is it ambiguous?
>> >
>> > Of course.
>>
>> ? if it's ambiguous then Walter cannot use this syntax for array literals.
>> Didn't you just say:
>>
>> "Not that ugly. And if it gives us array literals, it'd be well worth it."
>>
>> > It's an array of ints. In fact, you could specify other things in
>> > there, and rely on the implicit conversions, just as with any other
>> > variables.
>
> Sorry, I read your "True, but is it ambiguous?" as "True, but is it unambiguous?"
>
> Doh!

I figured that is what happened.

Regan


-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

Walter wrote:
>>  void anotherfunc(float a);
>>  . . .
>>
>>  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.

How about these rules:

1) Initially, all values in the array are assigned their types using the same rules as ordinary constants.  So the array literal
	[1,1.0,1]
starts with the types
	[int,float,int]

2) The various values are implicitly converted to the least complex common type.  In the example above, the values are converted to
	[float,float,float]

3) Once all of the values have the same type, the type of the array is known:
	float[3]

4) If the array constant is assigned to some other array, then array types are automatically converted up, just like the values would have individually:
	double[] var = [1,1.0,1];
The float[3] array constant is converted up to double[3].

5) The process proceeds recursively for multidimensional arrays:
	[[1,1.0,1],[2,3,4],[5,6,7]]
	[[int,float,int],[int,int,int],[int,int,int]]
	[[float,float,float],int[3],int[3]]
	[float[3],int[3],int[3]]
	[float[3],float[3],float[3]]
	float[3][3]

Sounds clever, to be sure, but I fear it'd be a source of huge hidden bugs. Imagine the horror that could spawn from a simple typo involving "." rather than ","

I agree with later posters that we need the type in there somewhere, and I don't doubt that one of you erudite folks, or big-W himself, can concoct an elegant and unambiguous syntax.



-- 
The Dr.

da-da-da-dum, da-da-da-dum, da-da-da-dum, daaah
da-da-da-dum, da-da-da-dum, da-da-da-dum, daaah
woo-ooooo




"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:cajf6k$2mg9$1@digitaldaemon.com...
> Walter wrote:
> >>  void anotherfunc(float a);
> >>  . . .
> >>
> >>  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.
>
> How about these rules:
>
> 1) Initially, all values in the array are assigned their types using the
> same rules as ordinary constants.  So the array literal
> [1,1.0,1]
> starts with the types
> [int,float,int]
>
> 2) The various values are implicitly converted to the least complex common type.  In the example above, the values are converted to [float,float,float]
>
> 3) Once all of the values have the same type, the type of the array is
> known:
> float[3]
>
> 4) If the array constant is assigned to some other array, then array
> types are automatically converted up, just like the values would have
> individually:
> double[] var = [1,1.0,1];
> The float[3] array constant is converted up to double[3].
>
> 5) The process proceeds recursively for multidimensional arrays:
> [[1,1.0,1],[2,3,4],[5,6,7]]
> [[int,float,int],[int,int,int],[int,int,int]]
> [[float,float,float],int[3],int[3]]
> [float[3],int[3],int[3]]
> [float[3],float[3],float[3]]
> float[3][3]
>

"Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message news:cajb6v$2f9b$1@digitaldaemon.com...
> 1. Do you have an interest in getting array literals in for 1.0, if a
simple and
> unambiguous syntax can be determined?

I recognize the need for them, but I also want to button up the feature set for 1.0 first, because I want to turn my attention to fixing all the outstanding compiler bugs and fixing some long standing deficiencies in Phobos.

> 2. Do you have your own ideas for such a syntax?

Nothing definite. There's also the related problem of struct literals.

"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.

"Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message news:cajh6n$2pdn$1@digitaldaemon.com...
> Sounds clever, to be sure, but I fear it'd be a source of huge hidden
bugs.
> Imagine the horror that could spawn from a simple typo involving "."
rather than
> ","

I agree. I'd rather have a simple and easy to understand rule that is perhaps a bit klunky rather than a complex, powerful rule that few understand (like C++ overloading rules <g>).

It's also important, in language design, to have a bit of redundancy in the syntax. Redundancy is what makes it possible for a compiler to detect errors and issue a semi-comprehensible error message. If a language had no redundancy, then every random string of bytes is a valid program.

(One of the reasons for the legendary obtuseness of the error messages generated by misusing C++ templates is the lack of redundancy in the syntax.)

The D cast syntax is an example of improved redundancy over C's cast.

"Walter" <newshound@digitalmars.com> wrote in message news:cajj1s$2sqp$2@digitaldaemon.com...
>
> "Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message news:cajb6v$2f9b$1@digitaldaemon.com...
> > 1. Do you have an interest in getting array literals in for 1.0, if a
> simple and
> > unambiguous syntax can be determined?
>
> I recognize the need for them, but I also want to button up the feature set for 1.0 first, because I want to turn my attention to fixing all the outstanding compiler bugs and fixing some long standing deficiencies in Phobos.

That's fine by me. We need to agree on the set of features that will go into the book, and that's closely related to 1.0's language features, so I can wait.


-- 
Matthew Wilson

Author: "Imperfect C++", Addison-Wesley, 2004
    (http://www.imperfectcplusplus.com)
Contributing editor, C/C++ Users Journal
    (http://www.synesis.com.au/articles.html#columns)
STLSoft moderator
    (http://www.stlsoft.org)

" I fold like a cheap hooker who got hit in the stomach by a fat guy with sores on his face" -- Joey

-------------------------------------------------------------------------------

> The D cast syntax is an example of improved redundancy over C's cast.

Indeed. :)