On Tuesday, 30 April 2024 at 02:20:39 UTC, electricface wrote:
> On Sunday, 28 April 2024 at 16:08:11 UTC, Richard (Rikki) Andrew Cattermole wrote:
>> On 28/04/2024 10:17 PM, ryuukk_ wrote:
>>> |_| should be enough
>>
>> ``_`` is a valid identifier that may point to a length.
>>
>> So that isn't usable.
>
> I think it's better to represent the automatically calculated length using `..` .
>
> ```
> int[..] a = [1,2,3,4,5]
> ```

Yes, I like this more.

Someone please submit a DIP.

On Friday, 3 May 2024 at 07:48:01 UTC, rkompass wrote:
>
> I actually find this counterintuitive. Because [..] in my intuition looks like a dynamic array. But it's about creating a static array.
> ...

[..] is a slice thing - it's not related to how the array came into existence.

i.e it can work on a static array, and a dynamic array (see code example below).

Perhaps for that reason, [..] might not be suitable after all.

perhaps [$] is still the best, since $ *always* simply refers to the length of the array.

so:

int[4] // 4 is the length
int[$] // $ is still the length, you just don't know what it is yet.

module m;
@safe:
private:
import std;

void main()
{
    auto a = [1, 2, 3, 4, 5].staticArray;
    //auto a[$] = [1, 2, 3, 4, 5]; // the compiler can infer the 'length'

    writeln(fold!((a, b) => a + b)(a[0..2])); // 3  (see: [..] used on a static array.
}

On Friday, 3 May 2024 at 10:04:57 UTC, Nick Treleaven wrote:
> On Friday, 3 May 2024 at 09:15:02 UTC, rkompass wrote:
>> I read through the discusion there and found it quite digressing and not productive.
>> There was no real weighing the pros against the cons.
>>
>> Of course we have staticArray, but in programming it's much about conciseness which at the same time allows for effortlessy (intuitively) transporting the meaning of a construct.
>> And this criterion here is fulfilled.
>> No new symbol is introduced, just a meaning extended, which is immediatly clear.
>>
>> Could DIP 1039 be restarted?
>
> I think the sticking point is making an implementation that does not complicate the compiler code much.

Yes, i was thinking to post the exact same comment actually ;-)

As it is, CTFE using .staticArray is a useful alternative... unless you're trying to do something like this:

module m;
@safe:
private:

import std;

private enum numItems = 10;

class myClass {}

void main()
{
    // Object[numItems] objectArr = generate!(() => new myClass())().take(numItems).array;

    import std.array : staticArray;
    auto arr = generate!(() => new myClass())().take(numItems).staticArray; // nope
}

On Friday, 3 May 2024 at 11:45:27 UTC, NotYouAgain wrote:
> ...

and this won't work either:

int i = 2;
//int[10] powersOfTwo = generate!(() => i *= 2)().take(10).array; // fine
auto powersOfTwo = staticArray!(generate!(() => i *= 2)().take(10).array); // nope