On Sun, 10 Jun 2012 20:08:53 -0400, Mehrdad <wfunction@hotmail.com> wrote:

>>> Type deduction.
>>
>> Exactly. And if they need to be assigned to a static array, then the compiler
>> can automatically do what it needs to do to avoid the extra heap allocation.
>>
>> - Jonathan M Davis
>
>
> "Type deduction"?  o.O
> I don't understand... could someone give me an example of what would break if we used the rule I suggested?

Anything that uses type deduction?  Most of the time, you do *not* want a static array, especially for template functions that use IFTI.

Note that D1 was like this, [1,2,3] was auto-typed to int[3u].  It was a constant source of pain that I would not like to revisit.  Especially since static arrays are now passed by value.

-Steve

Artur Skawina , dans le message (digitalmars.D:169717), a écrit :
> On 06/11/12 12:06, Christophe Travert wrote:
>> Jonathan M Davis , dans le message (digitalmars.D:169705), a écrit :
>>> auto found = find([1, 2, 3, 4, 5], 3);
>> 
>> No problem if the rule could be the following:
>>  - array literals are static by default
>>  - array literals are copied to the heap when assigned to a dynamic
>> array.
>>  - the former rule applies even if the array literal is assigned to a
>> dynamic array via a function call, like it is the case in this example.
>>  - if a function can take both static and dynamic array as parameter,
>> the static version takes precedence (it is always possible to call the
>> dynamic version via slicing, at your own risk since the array is no
>> longer valid at the end of the function call, or, much more wisely, by
>> explicitely using the .dup property).
> 
> T f(T)(T a) {}
> 
> artur

I don't see the problem. If T compiles with a static array, it returns a static array, there is no invalid pointer issue, since the returned value is not a slice, but a static array.

-- 
Christophe

"Steven Schveighoffer" , dans le message (digitalmars.D:169718), a
 écrit :
> Note that D1 was like this, [1,2,3] was auto-typed to int[3u].  It was a constant source of pain that I would not like to revisit.  Especially since static arrays are now passed by value.
> 
> -Steve

Since static are passed by value, static arrays are now safe to use. This should decrease the pain a lot.

On 10/06/12 23:43, Jonathan M Davis wrote:
> On Sunday, June 10, 2012 23:23:57 Mehrdad wrote:
>> I honestly don't see the POINT of having a "dynamic array
>> literal".
>>
>> What's the point of making the literals dynamic?
>>
>> They should all be static, and only converted to dynamic if
>> necessary from the context.
>>
>> But I really don't see the benefit of allocating them on the heap
>> just because we can... perhaps someone can enlighten me?
>
> In the vast majority of cases where an array literal is used, it's assigned to
> a dynamic array.

I doubt that very much. I know it's not true in my code, I use array literals almost exclusively for immutable values.
Usually if you are initializing an array, where you will modify the elements later, you want all values to be the same.

I argued that array literals should be immutable, just as string literals are. But I lost.

On Friday, June 15, 2012 09:09:48 Don Clugston wrote:
> On 10/06/12 23:43, Jonathan M Davis wrote:
> > On Sunday, June 10, 2012 23:23:57 Mehrdad wrote:
> >> I honestly don't see the POINT of having a "dynamic array literal".
> >> 
> >> What's the point of making the literals dynamic?
> >> 
> >> They should all be static, and only converted to dynamic if necessary from the context.
> >> 
> >> But I really don't see the benefit of allocating them on the heap just because we can... perhaps someone can enlighten me?
> > 
> > In the vast majority of cases where an array literal is used, it's assigned to a dynamic array.
> 
> I doubt that very much. I know it's not true in my code, I use array
> literals almost exclusively for immutable values.
> Usually if you are initializing an array, where you will modify the
> elements later, you want all values to be the same.
> 
> I argued that array literals should be immutable, just as string literals are. But I lost.

What does immutability have to do with static vs dynamic?

immutable a = [0, 1, 2, 3];

results in an immutable(int[]), not immutable(int[4]).

- Jonathan M Davis

On Friday, 15 June 2012 at 07:15:50 UTC, Jonathan M Davis wrote:
> On Friday, June 15, 2012 09:09:48 Don Clugston wrote:
>> On 10/06/12 23:43, Jonathan M Davis wrote:
>> > On Sunday, June 10, 2012 23:23:57 Mehrdad wrote:
>> >> I honestly don't see the POINT of having a "dynamic array
>> >> literal".
>> >> 
>> >> What's the point of making the literals dynamic?
>> >> 
>> >> They should all be static, and only converted to dynamic if
>> >> necessary from the context.
>> >> 
>> >> But I really don't see the benefit of allocating them on the heap
>> >> just because we can... perhaps someone can enlighten me?
>> > 
>> > In the vast majority of cases where an array literal is used, it's
>> > assigned to a dynamic array.
>> 
>> I doubt that very much. I know it's not true in my code, I use array
>> literals almost exclusively for immutable values.
>> Usually if you are initializing an array, where you will modify the
>> elements later, you want all values to be the same.
>> 
>> I argued that array literals should be immutable, just as string
>> literals are. But I lost.
>
> What does immutability have to do with static vs dynamic?
>
> immutable a = [0, 1, 2, 3];
>
> results in an immutable(int[]), not immutable(int[4]).
>
> - Jonathan M Davis


Just a guess here, but I think what Don meant was this:

An immutable _literal_ is quite often "static __gshared" (it's pretty pointless to make it an instance member...), which means it's always in memory, which means it should be static (as opposed to dynamic), since slicing it wouldn't cause problems.