• Walter Bright (4/4) Nov 12 2009 Currently, the type is determined by the type of the first element and
• Ellery Newcomer (3/8) Nov 12 2009 second and third arguments are converted to a common type.
• Bill Baxter (9/13) Nov 12 2009 Yay!
• grauzone (4/21) Nov 13 2009 It does. Note that if you cast an array variable (and not an array
• Andrei Alexandrescu (4/9) Nov 12 2009 Well take a number :o). It's been proposed by many and many times over.
• Walter Bright (2/4) Nov 12 2009 I know it has, I just wish to not make the change a surprise.
• bearophile (5/7) Nov 12 2009 A lot of time ago I have proposed that array literals use the type able ...
• Bill Baxter (4/9) Nov 12 2009 Hey! I proposed it too! -- Jan 2007, can you beat that? :-)
• Walter Bright (2/3) Nov 12 2009 Actually, D is improving very rapidly. Just look at the change log.
• Moritz Warning (4/9) Nov 12 2009 vote++
• Walter Bright (2/4) Nov 12 2009 I heard you guys, it's just that there was so much else going on.
• Moritz Warning (5/10) Nov 12 2009 We all feel that you have a lot of work to do.
• Robert Jacques (8/12) Nov 12 2009 Given how numeric literals currently work:
• Bill Baxter (7/20) Nov 12 2009 On the other hand, currently
• Robert Jacques (4/30) Nov 12 2009 Shouldn't that be:
• Bill Baxter (6/26) Nov 12 2009 Doh, strike that...
• Chad J (3/21) Nov 12 2009 Wait... just to be clear, is this because [1.0f, 2.5, 5.6, 0.8] would,
• Robert Jacques (4/26) Nov 12 2009 Yes. This also applies to static array initialization and other types
• Don (3/32) Nov 13 2009 If array literals were immutable , the implicit casting rules could
• bearophile (7/15) Nov 13 2009 Yes, this proposal has some downsides too. You have to be careful regard...
• Steven Schveighoffer (9/22) Nov 13 2009 How about if a cast is sticky? That is, the last detected cast inside a...
• Steven Schveighoffer (6/33) Nov 13 2009 Nevermind... I guess this already works:
• Simen Kjaeraas (8/21) Nov 13 2009 Now, if 2.5 simply is a floating point number of unspecified precision,

Walter Bright <newshound1 digitalmars.com> writes:

Currently, the type is determined by the type of the first element and 
the rest are implicitly cast to it.

I propose changing it to being the type produced by applying the ?: 
logic repeatedly to all the elements.

Ellery Newcomer <ellery-newcomer utulsa.edu> writes:

Walter Bright wrote:
 Currently, the type is determined by the type of the first element and
 the rest are implicitly cast to it.
 
 I propose changing it to being the type produced by applying the ?:
 logic repeatedly to all the elements.

second and third arguments are converted to a common type.

Go for it.

Bill Baxter <wbaxter gmail.com> writes:

On Thu, Nov 12, 2009 at 1:42 PM, Walter Bright
<newshound1 digitalmars.com> wrote:
 Currently, the type is determined by the type of the first element and the
 rest are implicitly cast to it.

 I propose changing it to being the type produced by applying the ?: logic
 repeatedly to all the elements.

Yay!
But if you want to force a type will there be a way to do that too
without casting each item?
like
   cast(int[]) [2.0, 4.5, 6.7]

Maybe that works already?

--bb

grauzone <none example.net> writes:

Bill Baxter wrote:
 On Thu, Nov 12, 2009 at 1:42 PM, Walter Bright
 <newshound1 digitalmars.com> wrote:
 Currently, the type is determined by the type of the first element and the
 rest are implicitly cast to it.

 I propose changing it to being the type produced by applying the ?: logic
 repeatedly to all the elements.

 
 Yay!
 But if you want to force a type will there be a way to do that too
 without casting each item?
 like
    cast(int[]) [2.0, 4.5, 6.7]
 
 Maybe that works already?

It does. Note that if you cast an array variable (and not an array 
literal), it doesn't do what you expect. Instead, it reinterpret casts 
the array bytes. What a strange semantic difference, bug or feature?

 --bb

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

Walter Bright wrote:
 Currently, the type is determined by the type of the first element and 
 the rest are implicitly cast to it.
 
 I propose changing it to being the type produced by applying the ?: 
 logic repeatedly to all the elements.

Well take a number :o). It's been proposed by many and many times over. 
Glad to see you're looking into it.

Andrei

Walter Bright <newshound1 digitalmars.com> writes:

Andrei Alexandrescu wrote:
 Well take a number :o). It's been proposed by many and many times over. 
 Glad to see you're looking into it.

I know it has, I just wish to not make the change a surprise.

bearophile <bearophileHUGS lycos.com> writes:

Walter Bright:
 I propose changing it to being the type produced by applying the ?: 
 logic repeatedly to all the elements.

A lot of time ago I have proposed that array literals use the type able to
contain all their items :-)
D is slowly improving. Lot of travel to do still.

Bye,
bearophile

Bill Baxter <wbaxter gmail.com> writes:

On Thu, Nov 12, 2009 at 2:30 PM, bearophile <bearophileHUGS lycos.com> wrote:
 Walter Bright:
 I propose changing it to being the type produced by applying the ?:
 logic repeatedly to all the elements.

 A lot of time ago I have proposed that array literals use the type able to
contain all their items :-)
 D is slowly improving. Lot of travel to do still.

Hey!  I proposed it too!  -- Jan 2007, can you beat that?  :-)
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=47530

--bb

Walter Bright <newshound1 digitalmars.com> writes:

bearophile wrote:
 D is slowly improving. Lot of travel to do still.

Actually, D is improving very rapidly. Just look at the change log.

Moritz Warning <moritzwarning web.de> writes:

On Thu, 12 Nov 2009 13:42:45 -0800, Walter Bright wrote:

 Currently, the type is determined by the type of the first element and
 the rest are implicitly cast to it.
 
 I propose changing it to being the type produced by applying the ?:
 logic repeatedly to all the elements.

vote++

Would be nice to finally have this (low profile) feature.
I think there was a discussion already but nothing happened.

Walter Bright <newshound1 digitalmars.com> writes:

Moritz Warning wrote:
 Would be nice to finally have this (low profile) feature.
 I think there was a discussion already but nothing happened.

I heard you guys, it's just that there was so much else going on.

Moritz Warning <moritzwarning web.de> writes:

On Thu, 12 Nov 2009 16:44:22 -0800, Walter Bright wrote:

 Moritz Warning wrote:
 Would be nice to finally have this (low profile) feature. I think there
 was a discussion already but nothing happened.

 
 I heard you guys, it's just that there was so much else going on.

We all feel that you have a lot of work to do.
D has grown a lot (also in complexity).

I appreciate those little improvements more than big features actually. :)
It's because I tend to use a subset of the language.

"Robert Jacques" <sandford jhu.edu> writes:

On Thu, 12 Nov 2009 16:42:45 -0500, Walter Bright  
<newshound1 digitalmars.com> wrote:

 Currently, the type is determined by the type of the first element and  
 the rest are implicitly cast to it.

 I propose changing it to being the type produced by applying the ?:  
 logic repeatedly to all the elements.

Given how numeric literals currently work:
vote--

for example currently:
float[] = [1.0f, 2.5, 5.6, 0.8].dup;

under the proposal
float[] = [1.0f, 2.5f, 5.6f, 0.8f].dup;

Bill Baxter <wbaxter gmail.com> writes:

On Thu, Nov 12, 2009 at 5:16 PM, Robert Jacques <sandford jhu.edu> wrote:
 On Thu, 12 Nov 2009 16:42:45 -0500, Walter Bright
 <newshound1 digitalmars.com> wrote:

 Currently, the type is determined by the type of the first element and the
 rest are implicitly cast to it.

 I propose changing it to being the type produced by applying the ?: logic
 repeatedly to all the elements.

 Given how numeric literals currently work:
 vote--

 for example currently:
 float[] = [1.0f, 2.5, 5.6, 0.8].dup;

 under the proposal
 float[] = [1.0f, 2.5f, 5.6f, 0.8f].dup;

On the other hand, currently

float[] = [1.0f, 2.0f, 3.0f, 4.5f].dup;

under the proposal:
float[] = [1, 2, 3, 4.5f].dup;

(I think    (true)?1:4.5f  is a float, anyway).
--bb

"Robert Jacques" <sandford jhu.edu> writes:

On Thu, 12 Nov 2009 20:29:31 -0500, Bill Baxter <wbaxter gmail.com> wrote:

 On Thu, Nov 12, 2009 at 5:16 PM, Robert Jacques <sandford jhu.edu> wrote:
 On Thu, 12 Nov 2009 16:42:45 -0500, Walter Bright
 <newshound1 digitalmars.com> wrote:

 Currently, the type is determined by the type of the first element and  
 the
 rest are implicitly cast to it.

 I propose changing it to being the type produced by applying the ?:  
 logic
 repeatedly to all the elements.

 Given how numeric literals currently work:
 vote--

 for example currently:
 float[] = [1.0f, 2.5, 5.6, 0.8].dup;

 under the proposal
 float[] = [1.0f, 2.5f, 5.6f, 0.8f].dup;

 On the other hand, currently

 float[] = [1.0f, 2.0f, 3.0f, 4.5f].dup;

 under the proposal:
 float[] = [1, 2, 3, 4.5f].dup;

 (I think    (true)?1:4.5f  is a float, anyway).
 --bb

Shouldn't that be:

On the other hand, currently

float[] = [1f, 2, 3, 4.5].dup;

Bill Baxter <wbaxter gmail.com> writes:

On Thu, Nov 12, 2009 at 5:29 PM, Bill Baxter <wbaxter gmail.com> wrote:
 On Thu, Nov 12, 2009 at 5:16 PM, Robert Jacques <sandford jhu.edu> wrote:
 On Thu, 12 Nov 2009 16:42:45 -0500, Walter Bright
 <newshound1 digitalmars.com> wrote:

 Currently, the type is determined by the type of the first element and the
 rest are implicitly cast to it.

 I propose changing it to being the type produced by applying the ?: logic
 repeatedly to all the elements.

 Given how numeric literals currently work:
 vote--

 for example currently:
 float[] = [1.0f, 2.5, 5.6, 0.8].dup;

 under the proposal
 float[] = [1.0f, 2.5f, 5.6f, 0.8f].dup;

 On the other hand, currently

 float[] = [1.0f, 2.0f, 3.0f, 4.5f].dup;

Doh, strike that...

float[] = [1.0f, 2, 3, 4.5].dup;
would work.

Bad example.  Sorry.

--bb

Chad J <chadjoan __spam.is.bad__gmail.com> writes:

Robert Jacques wrote:
 On Thu, 12 Nov 2009 16:42:45 -0500, Walter Bright
 <newshound1 digitalmars.com> wrote:
 
 Currently, the type is determined by the type of the first element and
 the rest are implicitly cast to it.

 I propose changing it to being the type produced by applying the ?:
 logic repeatedly to all the elements.

 
 Given how numeric literals currently work:
 vote--
 
 for example currently:
 float[] = [1.0f, 2.5, 5.6, 0.8].dup;
 
 under the proposal
 float[] = [1.0f, 2.5f, 5.6f, 0.8f].dup;
 

Wait... just to be clear, is this because [1.0f, 2.5, 5.6, 0.8] would,
under the proposed, become a double[4] and thus not be duppable to float[]?

"Robert Jacques" <sandford jhu.edu> writes:

On Thu, 12 Nov 2009 21:03:04 -0500, Chad J  
<chadjoan __spam.is.bad__gmail.com> wrote:

 Robert Jacques wrote:
 On Thu, 12 Nov 2009 16:42:45 -0500, Walter Bright
 <newshound1 digitalmars.com> wrote:

 Currently, the type is determined by the type of the first element and
 the rest are implicitly cast to it.

 I propose changing it to being the type produced by applying the ?:
 logic repeatedly to all the elements.

 Given how numeric literals currently work:
 vote--

 for example currently:
 float[] = [1.0f, 2.5, 5.6, 0.8].dup;

 under the proposal
 float[] = [1.0f, 2.5f, 5.6f, 0.8f].dup;

 Wait... just to be clear, is this because [1.0f, 2.5, 5.6, 0.8] would,
 under the proposed, become a double[4] and thus not be duppable to  
 float[]?

Yes. This also applies to static array initialization and other types  
(byte, short, etc.)

Don <nospam nospam.com> writes:

Robert Jacques wrote:
 On Thu, 12 Nov 2009 21:03:04 -0500, Chad J 
 <chadjoan __spam.is.bad__gmail.com> wrote:
 
 Robert Jacques wrote:
 On Thu, 12 Nov 2009 16:42:45 -0500, Walter Bright
 <newshound1 digitalmars.com> wrote:

 Currently, the type is determined by the type of the first element and
 the rest are implicitly cast to it.

 I propose changing it to being the type produced by applying the ?:
 logic repeatedly to all the elements.

 Given how numeric literals currently work:
 vote--

 for example currently:
 float[] = [1.0f, 2.5, 5.6, 0.8].dup;

 under the proposal
 float[] = [1.0f, 2.5f, 5.6f, 0.8f].dup;

 Wait... just to be clear, is this because [1.0f, 2.5, 5.6, 0.8] would,
 under the proposed, become a double[4] and thus not be duppable to 
 float[]?

 
 Yes. This also applies to static array initialization and other types 
 (byte, short, etc.)

If array literals were immutable <g>, the implicit casting rules could 
apply to them, so that the current code would continue to work.

bearophile <bearophileHUGS lycos.com> writes:

Robert Jacques:

 Given how numeric literals currently work:
 vote--
 
 for example currently:
 float[] = [1.0f, 2.5, 5.6, 0.8].dup;
 
 under the proposal
 float[] = [1.0f, 2.5f, 5.6f, 0.8f].dup;

Yes, this proposal has some downsides too. You have to be careful regarding
what you put inside the array, because a stray value may change the type of
your whole array, and this can lead to problems if you use:
auto a = [1.0f,2.5f,5.6,0.8f];
If you forget a single "f" a becomes an array of doubles...

So no design is perfect here. But I think the new proposed design is the more
handy of the two. If programming experience shows us this leads to problems we
can switch back to the older design. Sometimes you need to use things for some
time to know how good/bad they are.

Bye,
bearophile

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

On Thu, 12 Nov 2009 20:16:40 -0500, Robert Jacques <sandford jhu.edu>  
wrote:

 On Thu, 12 Nov 2009 16:42:45 -0500, Walter Bright  
 <newshound1 digitalmars.com> wrote:

 Currently, the type is determined by the type of the first element and  
 the rest are implicitly cast to it.

 I propose changing it to being the type produced by applying the ?:  
 logic repeatedly to all the elements.

 Given how numeric literals currently work:
 vote--

 for example currently:
 float[] = [1.0f, 2.5, 5.6, 0.8].dup;

 under the proposal
 float[] = [1.0f, 2.5f, 5.6f, 0.8f].dup;

How about if a cast is sticky?  That is, the last detected cast inside an  
array literal is applied to subsequent elements that do not have a cast:

[cast(float)1.0, 2.5, 5.6, 0.8]; // equivalent to [1.0f, 2.5f, 5.6f, 0.8f]  
=> float[]

[cast(float)1.0, 2.5, cast(double)5.6, 0.8]; // equivalent to [1.0f, 2.5f,  
5.6, 0.8] => double[]

-Steve

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

On Fri, 13 Nov 2009 07:34:14 -0500, Steven Schveighoffer  
<schveiguy yahoo.com> wrote:

 On Thu, 12 Nov 2009 20:16:40 -0500, Robert Jacques <sandford jhu.edu>  
 wrote:

 On Thu, 12 Nov 2009 16:42:45 -0500, Walter Bright  
 <newshound1 digitalmars.com> wrote:

 Currently, the type is determined by the type of the first element and  
 the rest are implicitly cast to it.

 I propose changing it to being the type produced by applying the ?:  
 logic repeatedly to all the elements.

 Given how numeric literals currently work:
 vote--

 for example currently:
 float[] = [1.0f, 2.5, 5.6, 0.8].dup;

 under the proposal
 float[] = [1.0f, 2.5f, 5.6f, 0.8f].dup;

 How about if a cast is sticky?  That is, the last detected cast inside  
 an array literal is applied to subsequent elements that do not have a  
 cast:

 [cast(float)1.0, 2.5, 5.6, 0.8]; // equivalent to [1.0f, 2.5f, 5.6f,  
 0.8f] => float[]

 [cast(float)1.0, 2.5, cast(double)5.6, 0.8]; // equivalent to [1.0f,  
 2.5f, 5.6, 0.8] => double[]

Nevermind...  I guess this already works:

cast(float[])[1.0, 2.5, 5.6, 0.8]

I don't see the OP's point as being an issue in light of this.

-Steve

"Simen Kjaeraas" <simen.kjaras gmail.com> writes:

Robert Jacques <sandford jhu.edu> wrote:

 On Thu, 12 Nov 2009 16:42:45 -0500, Walter Bright  
 <newshound1 digitalmars.com> wrote:

 Currently, the type is determined by the type of the first element and  
 the rest are implicitly cast to it.

 I propose changing it to being the type produced by applying the ?:  
 logic repeatedly to all the elements.

 Given how numeric literals currently work:
 vote--

 for example currently:
 float[] = [1.0f, 2.5, 5.6, 0.8].dup;

 under the proposal
 float[] = [1.0f, 2.5f, 5.6f, 0.8f].dup;

Now, if 2.5 simply is a floating point number of unspecified precision,
leaning towards double, and we introduce a suffix to force it to be double:

auto foo = [ 2.5, 3.5 ]; // double[]
auto bar = [ 2.5f, 3.5 ]; // float[]
auto baz = [ 2.5f, 3.5d ]; // double[]

-- 
Simen