On Sunday, 17 July 2022 at 07:25:18 UTC, Ola Fosheim Grøstad wrote:

Because it is a proposal that has been forgotten for 7 years. The DIP may have been withdrawn, but it was never given a chance to be tried.

SDB@79

On Sunday, 17 July 2022 at 08:58:58 UTC, Salih Dincer wrote:

It hasn't been 7 years. DIP 1039 went through the first round of Community review in January of last year. The author withdrew it because the he got the impression that the feedback was largely negative, and he felt that he couldn't formulate a good case for why the proposed feature was sufficiently of more benefit than staticArray to justify the new syntax.

You can see the review summary and the links to the Discussion and Feedback threads here:

https://github.com/dlang/DIPs/blob/master/DIPs/other/DIP1039.md#reviews

Again, anyone who wants to take this up is totally free to do so.

On a personal note, I like the idea. Having to match static array length with initializer length has annoyed me more than once in my years of D. And having to import another symbol to get around it hardly alleviates the annoyance. int[$] is a sensible syntax for it. So I hope someone does pick this up one day and manages to convince the right people that it's worth the implementation.

On Sunday, 17 July 2022 at 09:23:23 UTC, Mike Parker wrote:

Opps, sorry for my english. When I wrote "offer" I meant past requests. For example:

https://issues.dlang.org/show_bug.cgi?id=8008

Even this is from 10 years ago. I had seen something Kenji Hara shared before this but couldn't find it. In summary, there is a DIP, but the opportunity to use it is not given. Maybe as people use it, we will see how correct this decision is.

Thanks...

SDB@79

On Sunday, 17 July 2022 at 09:23:23 UTC, Mike Parker wrote:

If adding better inference is a point then choose a syntax that is more universal so that you don't end up with many different syntaxes for the same kind of "fill in blank" type deduction.

Btw, C++ achieves the same generically by deduction guides (or improved type inference) so that you can write

    using namespace std;

    array a{1,2,3};

and get the type array<int,3>

On Sunday, 17 July 2022 at 14:21:21 UTC, Ola Fosheim Grøstad wrote:

$ already has an association with array length, though in a = [0 .. $]. I think it's perfect for this case.

On Sunday, 17 July 2022 at 04:21:21 UTC, Ola Fosheim Grøstad wrote:

This is why people think D is a Java++ and is a GC'd language

Let's enforce this sentiment, and cement it so nothing can improve moving forward, never reflect, always double down

That's concerning

I agree with that, some other features are more important, it is not urgent, but still is something that should be handled without suggesting importing modules and without writing template soup

I'm not sure if you are being serious or not

Why 1+1? why not

import std.math;
add(1, 1):

Why do_something(1)? why not

import std.function;
call_function( do_something ).with_arg(1);

why array[1] == 'c'? why not

import std.array;
contains(array, 1, 'c');

User should be suggested to write code to solve the problem he is trying to solve in his program

Not suggesting to write code to fix the deficiencies of the language

That is why people come up with new languages; and that messages is what's pushing people to choose alternatives

On Sunday, 17 July 2022 at 14:21:21 UTC, Ola Fosheim Grøstad wrote:

    using namespace std;

    array a{1,2,3};

That's why i will never use C++, ever, and the reason i went with D instead, coming from C

On Sunday, 17 July 2022 at 09:23:23 UTC, Mike Parker wrote:

staticArray for nested arrays sucks:

auto foo = [[1,2,3,4].staticArray,[5,6,7,8]].staticArray;
int[4][2] foo2 = [[1,2,3,4],[5,6,7,8]];

The second statement is much better, but you need the first to infer the length. Just specifying "infer the length" with a [$] on the type is a perfect fit.

You also have an issue with const conversion that's not as easy to specify. e.g.:

char[74] foo = "this is a long string that I don't want to have to count the characters in";

Can't use staticArray here because the type will be immutable(char)[74].

If I want to specify it should be char, I can't do staticArray!char, because then it doesn't infer anything.

I can't even cast it, because there's no way to cast without knowing the correct size.

This is a simple quality-of-life improvement. I think the original PR was reverted because it allowed too much inference, like:

auto[$] foo = [1,2,3,4];

I think just specifying the length is dependent on the length of the literal is enough benefit to justify the change. We don't need full inference of any static array type.

-Steve

On Sunday, 17 July 2022 at 14:43:01 UTC, ryuukk_ wrote:

No, C and C++ are completely stuck in being overspecific, which makes them time consuming languages to deal with, but a good language will allow you to express intent and let the compiler select the best performing implementation.

This makes much more sense for generic programming. You want to write one implementation and let the compiler adapt the implementation through optimization where it is trivial to do so.

What is concerning is that D has not improved on templates and now C++ is becoming as convenient for library development if not more so...

The idiomatic C++20 way is similar to_array<char>({1,2,3,4}). I don't see the big deal.

D needs to stop trying to drive in individual nails with special casing and figure out the big picture.

On Sunday, 17 July 2022 at 15:23:45 UTC, Steven Schveighoffer wrote:

There may be ambiguity with $ for length inside an index/slice expression when an inferred static array type is part of an expression:
https://forum.dlang.org/post/qsjahatdiyxwojcwyedm@forum.dlang.org

char[74] foo = "this is a long string that I don't want to have to count the characters in";

Presumably length inference would not include the terminating nul byte of the string literal?

Could add an overload for that:
https://forum.dlang.org/post/urzdeerfcvardyztxfab@forum.dlang.org

Threads like these always use basic element types like int or char. In practice the element type can be quite complex. It's a pain to have to write out a complex type - e.g. typeof(x.map!(a => someExpr).front). That could be solved by having specific syntax for static array literals:

auto sa = $[1,2,3,4];

That avoids supporting partial auto declarations (a reason why Walter didn't like that PR). It also allows inference when passing a literal to a template function argument where the parameter is not already a static array. The $[] syntax would literally mean "length array", i.e. fixed length array. (Why do we overload the word 'static' here for arrays?)

And it's prefix syntax, which would read well with your nested static array example:

auto foo = $[$[1,2,3,4],[5,6,7,8]];

It doesn't help your char[$] foo = "immutable data"; case though (which would need the staticArray overload or equivalent).