On Thursday, 5 January 2023 at 09:07:57 UTC, Dom DiSc wrote:
> On Wednesday, 21 December 2022 at 19:31:22 UTC, Walter Bright wrote:
>> My proposal for C:
>>
>>     int a[5] = { 0, 1, 2, 3, 4};
>>     int p[..] = a;  // p points to 5 elements.
>
> I would wish you first implement this for D:
>
> ```d
> uint[] x = [1,2,3]; // create a dynamic array with initial size 3
> uint[..] y = [1,2,3]; // create a static array with automatic size (not possible now)
> ```

Neither proposal will get into C.

One of the design goals of C, is actually to resist change (no, I'm no kidding).

I think that is a good thing.

As for D, yes, it sure is surprising the compiler cannot automatically size a static array by the number of arguments being provided to it.

But I'm not a fan of this syntax [..]

Everytime I see it, I think, wtf is that!

It's also confusing as it uses syntax from slices [1..$]

maybe I'd settle on int[T] array = [1,2,3];

now, as a programmer, I already know that T is a token that will get automatically replaced with something meaningful.

On Thursday, 5 January 2023 at 09:37:18 UTC, areYouSureAboutThat wrote:
> On Thursday, 5 January 2023 at 09:07:57 UTC, Dom DiSc wrote:
>> On Wednesday, 21 December 2022 at 19:31:22 UTC, Walter Bright wrote:
>>> My proposal for C:
>>>
>>>     int a[5] = { 0, 1, 2, 3, 4};
>>>     int p[..] = a;  // p points to 5 elements.
>>
>> I would wish you first implement this for D:
>>
>> ```d
>> uint[] x = [1,2,3]; // create a dynamic array with initial size 3
>> uint[..] y = [1,2,3]; // create a static array with automatic size (not possible now)
>> ```
>
> Neither proposal will get into C.
>
> One of the design goals of C, is actually to resist change (no, I'm no kidding).
>
> I think that is a good thing.
>
> As for D, yes, it sure is surprising the compiler cannot automatically size a static array by the number of arguments being provided to it.
>
> But I'm not a fan of this syntax [..]
>
> Everytime I see it, I think, wtf is that!
>
> It's also confusing as it uses syntax from slices [1..$]
>
> maybe I'd settle on int[T] array = [1,2,3];
>
> now, as a programmer, I already know that T is a token that will get automatically replaced with something meaningful.


You can't use [T] because it is reserved as user symbol and could break D code. For instance, T can be used as a number:
```d
struct IntStaticArray(uint T)
{
    int[T] data;
    alias data this;
}
IntStaticArray!(5) arr;
```

The most accepted syntax for inferred length static array was `int[$] a = [1,2,3]`. But people insists that `import std.array:staticArray; int[] a = [1,2,3].staticArray;` is better. So I don't know what to say.

Anyway this thread has gone quite far and is really unproductive. So just go and fix the C biggest mistake so people can back to be productive again.

On Thu, Jan 05, 2023 at 09:37:18AM +0000, areYouSureAboutThat via Digitalmars-d wrote: [...]
> As for D, yes, it sure is surprising the compiler cannot automatically size a static array by the number of arguments being provided to it.

Of course it can. See std.array.staticArray.

Yes, yes, people hate the standard library for some weird reason. D must be the only language where people actively hate its standard library. It's like writing C without using stdlib or stdio, or writing C++ without using STL.  Makes no sense.

Built-in syntax has been proposed multiple times in the past, the main blocker being:


> But I'm not a fan of this syntax [..]

Everybody says that about every proposal that has come up.

	// All this has been proposed before:
	int[_] staticArray;	// "but _ is a valid identifier!"
	int[$] staticArray;	// "but $ looks ugly!"
	int[auto] staticArray;	// "but auto is too verbose!"
	... // the list goes on
	// And now this:
	int[..] staticArray;	// "but i'm not a fan of this syntax!"

If we would stop bikeshedding over trivialities such as syntax, we'd have implemented this years ago.


T

-- 
Notwithstanding the eloquent discontent that you have just respectfully expressed at length against my verbal capabilities, I am afraid that I must unfortunately bring it to your attention that I am, in fact, NOT verbose.

On Thursday, 5 January 2023 at 17:30:59 UTC, H. S. Teoh wrote:

> 	int[$] staticArray;	// "but $ looks ugly!"

We need to stop listening to people who hate dollars. Seriously, $ is already in the language and means "length of the array". Let's use it.

On Thu, Jan 05, 2023 at 06:19:12PM +0000, Max Samukha via Digitalmars-d wrote:
> On Thursday, 5 January 2023 at 17:30:59 UTC, H. S. Teoh wrote:
> 
> > 	int[$] staticArray;	// "but $ looks ugly!"
> 
> We need to stop listening to people who hate dollars. Seriously, $ is already in the language and means "length of the array". Let's use it.

+1.  Anyone up for pushing this DIP through?  I'd support it.


T

-- 
Береги платье снову, а здоровье смолоду.

On Thursday, 5 January 2023 at 18:19:12 UTC, Max Samukha wrote:
> On Thursday, 5 January 2023 at 17:30:59 UTC, H. S. Teoh wrote:
>
>> 	int[$] staticArray;	// "but $ looks ugly!"
>
> We need to stop listening to people who hate dollars. Seriously, $ is already in the language and means "length of the array". Let's use it.

I didn't like the dollars in the DIP with the enum inference (https://forum.dlang.org/thread/wpqmuysuxadcwnzypnxk@forum.dlang.org). However, here it makes sense and already mean something (arrays length).

uint[$] y = [1,2,3];

Looks ok to me. I would support a DIP suggesting this.

uint[..] y = [1,2,3];

is also ok. Static array length based on initializer is long overdue.

On Thu, Jan 05, 2023 at 07:10:47PM +0000, IGotD- via Digitalmars-d wrote: [...]
> Static array length based on initializer is long overdue.

Let's do it!!  Time to resurrect that DIP and push it through.


T

-- 
First Rule of History: History doesn't repeat itself -- historians merely repeat each other.

Dennis Ritchie proposed fat pointers for C in 1990.

https://github.com/kenmartin-unix/UnixDocs/blob/master/VaribleSized_Arrays_in_C.pdf

On Thursday, 5 January 2023 at 17:30:59 UTC, H. S. Teoh wrote:
>
> Of course it can. See std.array.staticArray.
>

I didn't know that. Thanks. I'll use it.

But in that case, what are people fussing about. Just use that.

Why introduce nonsense such as this: [$] [..]  ???

Mmm .. maybe [?]   ??

btw. I don't consider syntax as bikeshedding. As a programmer, nothing is more important to me than sensible (and predictable) syntax.

However, instead of having to do this:

auto myArray = [0, 1].staticArray;

I would like the compiler to infer that I'm creating a staticArray using this:

int[] myArray = [0, 1].staticArray;

I don't see why it requires my to only ever use auto. I don't like using auto here.