On Thursday, 5 January 2023 at 20:58:52 UTC, areYouSureAboutThat wrote:
>

This would the absolute best approach:

int[] myDynamicArray = [0, 1]; // your typical dynamic D array.

int[] myStaticArray = [0, 1].staticArray;
static assert(is(typeof(myStaticArray) == int[2]));


Is there any reason the compiler cannot be made to do this?

On Thursday, 5 January 2023 at 21:08:28 UTC, areYouSureAboutThat wrote:
>
> int[] myStaticArray = [0, 1].staticArray;
> static assert(is(typeof(myStaticArray) == int[2]));
>
>
> Is there any reason the compiler cannot be made to do this?

In your example, wouldn't myStaticArray be a slice?

On Thu, Jan 05, 2023 at 08:58:52PM +0000, areYouSureAboutThat via Digitalmars-d wrote: [...]
> But in that case, what are people fussing about. Just use that.
> 
> Why introduce nonsense such as this: [$] [..]  ???

As you said yourself later, syntax. ;-)


> Mmm .. maybe [?]   ??

`?` is the ternary operator, it's weird to use it in this context with a totally unrelated meaning.


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

Syntax certainly has its place (I wouldn't ever want to use C++ template syntax again unless I'm forced to, for example), but semantics is far more important in a programming language than syntax.  The prettiest syntax in the world is worthless if it cannot express what I want to express in my code, or if it has weird semantics with strange corner cases that make my code hard to understand.


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

This does work:

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

Though it does also defeat the purpose of .staticArray. :-D


> I don't like using auto here.

It's already obvious from the initializer what the type of myArray is, why would you want to repeat it?  I prefer my code to be DRY.  I almost never write:

	int[] x = [1, 2, 3];
	MyStruct s = MyStruct(1, 2, 3);
	MyClass obj = new MyClass;

Too much redundant information.  This is better:

	auto x = [1, 2, 3];
	auto s = MyStruct(1, 2, 3);
	auto obj = new MyClass;

The compiler can already figure out the types for me; let the machine do its job while I focus on more important things. Like actually solving the programming problem I set out to solve, for example.


T

-- 
LINUX = Lousy Interface for Nefarious Unix Xenophobes.

On Thu, Jan 05, 2023 at 08:53:55PM +0000, Dibyendu Majumdar via Digitalmars-d wrote:
> Dennis Ritchie proposed fat pointers for C in 1990.
> 
> https://github.com/kenmartin-unix/UnixDocs/blob/master/VaribleSized_Arrays_in_C.pdf

Wow. So it took 30 years (and who knows how many buffer overflow security holes) for people to realize that this might have been a good idea?


T

-- 
What did the alien say to Schubert? "Take me to your lieder."

On Thursday, 5 January 2023 at 21:18:00 UTC, IGotD- wrote:
> On Thursday, 5 January 2023 at 21:08:28 UTC, areYouSureAboutThat wrote:
>>
>> int[] myStaticArray = [0, 1].staticArray;
>> static assert(is(typeof(myStaticArray) == int[2]));
>>
>>
>> Is there any reason the compiler cannot be made to do this?
>
> In your example, wouldn't myStaticArray be a slice?

how can this possibly be misinterpreted??

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

the '.staticArray' provides all the context needed to understand what type is being created.

On Thu, Jan 05, 2023 at 10:03:10PM +0000, areYouSureAboutThat via Digitalmars-d wrote:
> On Thursday, 5 January 2023 at 21:18:00 UTC, IGotD- wrote:
> > On Thursday, 5 January 2023 at 21:08:28 UTC, areYouSureAboutThat wrote:
> > > 
> > > int[] myStaticArray = [0, 1].staticArray;
> > > static assert(is(typeof(myStaticArray) == int[2]));
> > > 
> > > 
> > > Is there any reason the compiler cannot be made to do this?
> > 
> > In your example, wouldn't myStaticArray be a slice?
> 
> how can this possibly be misinterpreted??
> 
> int[] myStaticArray = [0, 1].staticArray;
> 
> the '.staticArray' provides all the context needed to understand what type is being created.

`int[]` is a slice. The static array is written as `int[2]`.

This is valid (though not exactly a good idea):

	// Take a slice of a static array
	int[] myStaticArray = [0, 1].staticArray[];


T

-- 
Lottery: tax on the stupid. -- Slashdotter

On Thursday, 5 January 2023 at 22:09:15 UTC, H. S. Teoh wrote:
>
> `int[]` is a slice. The static array is written as `int[2]`.
>
> This is valid (though not exactly a good idea):
>
> 	// Take a slice of a static array
> 	int[] myStaticArray = [0, 1].staticArray[];
>
>
> T

to be honest, I've never needed a static array in D.

I just let the gc take care of everything with []

so I'll leave the 'controversy' over this to those that do ;-)

in the meantime.. this is hardly .. hard:

auto myStaticArray = [0, 1].staticArray;

int[2] myStaticArray = [0, 1].staticArray;

people can still count.. can't they?

On Thu, Jan 05, 2023 at 10:35:37PM +0000, areYouSureAboutThat via Digitalmars-d wrote: [...]
> to be honest, I've never needed a static array in D.

:-D  I haven't really used static arrays very much myself, but occasionally they're useful.  E.g. in one project where I use a lot of 4-element int arrays, using static arrays for them reduces a lot of GC pressure, and also gives me nice by-value semantics (useful in certain contexts).


[...]
> in the meantime.. this is hardly .. hard:
> 
> auto myStaticArray = [0, 1].staticArray;
> 
> int[2] myStaticArray = [0, 1].staticArray;
> 
> people can still count.. can't they?

It's not so much about counting, it's about maintainability / mutability of the code.  For example, if you had a long static array like this:

	int[100] x = [ 2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41,
		43, 47, 53, 59, 61, 67, 71, 73, 79, 83, 89, 97, 101,
		103, 107, 109, 113, 127, 131, 137, 139, 149, 151, 157,
		163, 167, 173, 179, 181, 191, 193, 197, 199, 211, 223,
		227, 229, 233, 239, 241, 251, 257, 263, 269, 271, 277,
		281, 283, 293, 307, 311, 313, 317, 331, 337, 347, 349,
		353, 359, 367, 373, 379, 383, 389, 397, 401, 409, 419,
		421, 431, 433, 439, 443, 449, 457, 461, 463, 467, 479,
		487, 491, 499, 503, 509, 521, 523, 541 ];

if one day you decide that some elements have to be added/removed from this array (based on some arbitrary criteria), then you have to recount and update the length, which, for a long array, isn't a trivial effort. It's also not very DRY; the compiler can already figure this out for you, so why make the programmer repeat the same work?

Note that static arrays isn't just arrays of numbers, it could potentially be an array of some aggregate type with complex initializers that makes it annoying to have to recount every time you update it.


T

-- 
Жил-был король когда-то, при нём блоха жила.

On 1/5/2023 12:53 PM, Dibyendu Majumdar wrote:
> Dennis Ritchie proposed fat pointers for C in 1990.
> 
> https://github.com/kenmartin-unix/UnixDocs/blob/master/VaribleSized_Arrays_in_C.pdf

Wow, didn't know about that. Thanks!

The way D does it is better, though!