On Monday, 11 June 2012 at 00:16:48 UTC, Jonathan M Davis wrote:

> auto found = find(arr, [1, 2]);
>
> wouldn't compile, because [1, 2] would be considered a static array, which
> isn't a range.
>
> - Jonathan M Davis

Uh... that's pretty much just saying, "code that explicitly depends on the current behavior would now break".


Which is true, except that IMHO it's the code's fault.


The problem is there right now /anyway/:
int[2] items = [1, 2];
int[] arr = ...;
find(arr, items);   // "broken"... but, really, it _should_ work


So if that's a problem, then it's obviously a problem with find() -- it should slice the input -- not with this proposal.


Any other examples?

On Monday, June 11, 2012 02:45:00 Mehrdad wrote:
> On Monday, 11 June 2012 at 00:16:48 UTC, Jonathan M Davis wrote:
> > auto found = find(arr, [1, 2]);
> > 
> > wouldn't compile, because [1, 2] would be considered a static
> > array, which
> > isn't a range.
> > 
> > - Jonathan M Davis
> 
> Uh... that's pretty much just saying, "code that explicitly depends on the current behavior would now break".
> 
> 
> Which is true, except that IMHO it's the code's fault.
> 
> 
> The problem is there right now /anyway/:
> int[2] items = [1, 2];
> int[] arr = ...;
> find(arr, items);   // "broken"... but, really, it _should_ work
> 
> 
> So if that's a problem, then it's obviously a problem with find() -- it should slice the input -- not with this proposal.

Actually, having it slice the input is arguably a _bad_ idea. You risk stuff like

int[] foo(int[] a)
{
    return a;
}

int[] bar()
{
    int[5] a = [1, 2, 3, 4, 5];
    return foo(a);
}

b now refers to garbage. Honestly, I think that the fact that static arrays _ever_ slice implicitly was a _bad_ design decision and is just asking for trouble. If the programmer has to state it explicitly, then they always know that they're slicing it rather than copying it, and you reduce the risk of having slices to static arrays which don't exist anymore. IMHO, the fact that range-based functions don't work with static arrays without slicing them automatically is  _good_ thing.

And if all range-based functions were altered to work with static arrays, and we made array literals static, then this example would _still_ be broken

auto found = find(arr, [1, 2]);

But instead of giving a compilation error like it would if we just made array literal state, instead you're operating on garbage, and you get undefined behavior.

If the compiler is changed so that it elides the heap allocation when assigning an array literal to a dynamic array, then that solves the problem quite cleanl. I don't see how changing array literals to be static would help anything. Instead of getting unnecessary heap allocations, you get functions that don't work with array literals and/or you end up operating on garbage.

- Jonathan M Davis

On Monday, 11 June 2012 at 00:57:45 UTC, Jonathan M Davis wrote:
> And if all range-based functions were altered to work with static arrays, and we made array literals static, then this example would _still_ be broken
> auto found = find(arr, [1, 2]);


Sorry, I don't quite seem to follow. :\
Would you mind explaining why it's broken?

On Monday, June 11, 2012 04:13:42 Mehrdad wrote:
> On Monday, 11 June 2012 at 00:57:45 UTC, Jonathan M Davis wrote:
> > And if all range-based functions were altered to work with
> > static arrays, and we made array literals static, then this
> > example would _still_ be broken
> > auto found = find(arr, [1, 2]);
> 
> Sorry, I don't quite seem to follow. :\
> Would you mind explaining why it's broken?

Because then find would have to slice a static array, and that means that it risks returning a slice to a static array, which since the static array was a temporary guarantees that you would be returning a slice which pointed to garbage. The result is undefined behavior.

Now, since in this particular case, what find returns won't ever include anything from any arguments other than the first, it'll be fine. But for any templated function which returns a portion of its argument, having it take a static array for that argument would be horribly broken. For instance,

auto found = find([1, 2, 3, 4, 5], 3);

_would_ definitely return a slice which referred to garbage were array literals static and find accepted them.

- Jonathan M Davis

On Monday, 11 June 2012 at 02:25:54 UTC, Jonathan M Davis wrote:
> Now, since in this particular case, what find returns won't ever include anything from any arguments other than the first, it'll be fine.


Yes, that's precisely why your statement didn't make sense to me. :)



> But for any templated function which returns a portion of its argument, having it take a static array for that argument would be horribly broken. For instance,
>
> auto found = find([1, 2, 3, 4, 5], 3);
>
> _would_ definitely return a slice which referred to garbage were array literals
static and find accepted them.


Ah, that's a different example. :)


Hm... could you automatically convert the static arrays to dynamic if the argument isn't 'scope'?

On Monday, June 11, 2012 04:47:36 Mehrdad wrote:
> On Monday, 11 June 2012 at 02:25:54 UTC, Jonathan M Davis wrote:
> > Now, since in this particular case, what find returns won't ever include anything from any arguments other than the first, it'll be fine.
> 
> Yes, that's precisely why your statement didn't make sense to me.
> 
> :)
> :
> > But for any templated function which returns a portion of its argument, having it take a static array for that argument would be horribly broken. For instance,
> > 
> > auto found = find([1, 2, 3, 4, 5], 3);
> > 
> > _would_ definitely return a slice which referred to garbage were array literals
> 
> static and find accepted them.
> 
> 
> Ah, that's a different example. :)
> 
> 
> Hm... could you automatically convert the static arrays to dynamic if the argument isn't 'scope'?

That would be at odds with how passing static arrays to functions works normally. Normally, they get sliced.

But I don't get why you're so hung up on making array literals static. Having them be dynamic works great in every single case except when you specifically want to be assigning them to a static array. In that case, you get an unnecessary array allocation, which we definitely don't want. However, all it takes is for the compiler to see that you're assigning an array literal to a static array and skip the allocation. That particular use case is then fixed, and all of the rest of them continue to work just fine.

What are you trying to fix beyond assignments to static arrays with array literals?

- Jonathan M Davis

On Monday, 11 June 2012 at 03:05:36 UTC, Jonathan M Davis wrote:
> What are you trying to fix beyond assignments to static arrays with array literals?

Just the fact that it would reduce unnecessary heap allocations.
I'm not trying to 'fix' it though, as it's not broken. (Then again, neither is it right now.)

On Monday, June 11, 2012 05:09:49 Mehrdad wrote:
> On Monday, 11 June 2012 at 03:05:36 UTC, Jonathan M Davis wrote:
> > What are you trying to fix beyond assignments to static arrays with array literals?
> 
> Just the fact that it would reduce unnecessary heap allocations. I'm not trying to 'fix' it though, as it's not broken. (Then again, neither is it right now.)

Well, the unnecessary allocations are eleminated if the compiler starts eliding them like it should when assigning an array literal to a static array.

- Jonathan M Davis

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

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