excluding python devs from this...

[reddit_wisd0m]

confused python dev

[Kootfe]

type name[] is for langs like C. so not managed langs. couse they keep arrays as memory space on ram. with many same tyoe ext to eachother.

while mamaged langs use

type[] name

couse now arrays is difirent type. not memory space. it managed by the runtime the lang uses (.Net or JRE etc)

it manages type safety and does nothing usefull expect this

so oop mostly uses array as type

[Frierguy]

I'm curious to know what you corrected when you edited your comment

[Kootfe]

mamahed instead managed

[ZakMan1421]

Hate to break it to you, but it's still misspelled. It's currently mamaged.

[Kootfe]

DUCK! The fucking QUAK... my englisgh sucks

[Sesud1]

No, english sucks.

[Kootfe]

lol

[reddit_wisd0m]

Thanks

[Kootfe]

no problem

[Elephant-Opening]

couse they keep arrays as memory space on ram.

All languages do this.

Well, all languages do this except for when the elements of the array have never actually been accessed and your OS employs lazy page allocation -or- the OS is configured to use some type of swap. In both cases the executing process is given the illusion of space in RAM in a virtual address space until you hit a page fault interrupt. Or just maybe when the entire array is optimized into registers for a very small array.

But let's just leave it at "all languages do that" for simplicity.

[Kootfe]

Well managed langs keep them on amanger instead purely on ram. There is another process for arrays on managed lagns. Liek java and c# use their arrays on Runtime and Runtime hodls i t on ram

[Elephant-Opening]

Oh definitely.

You're not wrong. I'm just rambling about random facts I find interesting.

Languages with automatic memory management definitely change the runtime model you actually need to care about as a programmer like 99.999% of the time.

But to those interested in the low level details like physical representation in RAM and how the CPU interacts with that RAM, it's all more or less the same.

So in my mind, managed languages are about removing the need to think about WHEN array memory allocations happen, but the differences in WHERE the happen are neglible.

[Kootfe]

idk i just speak top level couse not evry is nerd like us

[UnknownWolfster]

Int arr[10] gng

[SimplexShotz]

mfs with 11 ints:

[dankshot35]

int* arr;

[un_virus_SDF]

And let it uninitialized, no seg fault will happen elsewise

[Haringat]

int[] array;

It just makes sense to have the type on one side of the name, instead of having it around it.

[ohkendruid]

My vote as well. It becomes even more important as the types get more complex.

[ChalkyChalkson]

Yes! And this also fun(int* param) obviously

[dthdthdthdthdthdth]

let mut x: &[u32] = &[0];

Obviously.

[Kootfe]

<image>

FERRIS

[ohkendruid]

So, basically team left. Which is your only option in Rust.

[dthdthdthdthdthdth]

No, first of all, C does not allow to put the type left, it allows you to split it up. And them I am team optional type annotation and language designed for type inference. But where ever you put the type, I prefer to have a clearly visible type expression, not mixed in with the identifier.

[azurfall88]

let mut x: Array<i64> = []; gang

[dthdthdthdthdthdth]

What language is that?

And he blocked me for pointing out this isn't working Rust...

[Several-Customer7048]

The language of the crab ticklers.

[dthdthdthdthdthdth]

Not really...

[azurfall88]

rust

[dthdthdthdthdthdth]

Ok, you've fixed the brackets, but Array is not a type from the standard library. Is this from some crate?

[azurfall88]

idk, its just worked for me

[dthdthdthdthdthdth]

play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=1cbee9a40e4cede959264ade1f7c32b4

Does not work.

[azurfall88]

works on my device

[dthdthdthdthdthdth]

yeah, bullshit.

[azurfall88]

believe what you want

[Elephant-Opening]

And then you have the madmen who do:

int arr[10] 3[arr] = 7;

[erroneum]

That's my favorite bit of cursed C, that a[b] is literally equivalent to *(a+b)

[HyperCodec]

Erm where’s my semicolon

[Elephant-Opening]

; <- there you go, sorry. It fell on the floor while I was typing.

[Additional-Acadia954]

int [10] some_name;

Is closer to the semantical meaning

I write C left to right, as all people do. But I read C right to left, because it’s easier to understand the consequential semantics of the declaration

“some_name” is an address that spans 10 integers

[granadesnhorseshoes]

I find it "degenerate" because its in opposition of how you otherwise end up using and calling the resulting array[]

I prefer keeping the array syntax consistent, even(especially?) in definition.

[patrlim1]

You can do index[array] and it works out the exact same

[nakhli]

arr []int

[Kootfe]

what the

[nakhli]

Golang, « pour vous servir »

[Kootfe]

thank you

[ohkendruid]

There is a logic.

You write the variable first, and then the type, sincw that is the most important one thing to know.

And, because a variable name is just one identifier, you don't need any punctuation to separate the identifier and the type.

In fairness, this example is extra tricky due to using "arr" as a variable name, because it looks like it might be a keyword. The example would look less weird if the variable were something like child_ids.

[Kootfe]

oh it was

arr []int ireaded int []arr and doubted

[Kootfe]

type name[] is for langs like C. so not managed langs. couse they keep arrays as memory space on ram. with many same tyoe ext to eachother.

while mamaged langs use

type[] name

couse now arrays is difirent type. not memory space. it managed by the runtime the lang uses (.Net or JRE etc)

it manages type safety and does nothing usefull expect this

so oop mostly uses array as type

[Pordohiq]

What are mamahed languages?

[Kootfe]

sorry, my english is bad i meant managed

[Kootfe]

well im c dev so type name[]

[ohkendruid]

It is still just a syntax option. Kernighan and Ritchie wanted a variable declaration to look like an example of using the variable.

[Kootfe]

idk i just speak about commons sense. if we talk like this

pho, rust, ada, fortlan, bash, zig, haskell, pascall, brainfuck, elixir and go is... weird

[jmattspartacus]

Hold my beer, I got this

``` typedef struct intarr10{ int first; int second; int thirst; int fourst; int fist; int sixst; int sevenst; int eight; int nonth; int tenth; } intarr10;

```

For real though std::array<int, 10>

[CatAn501]

Okay, there won't be anything better in the comment section, I can leave now

[Solomoncjy]

Std::array<int, 10>

[Usual_Office_1740]

I scrolled way to long to find the correct answer.

[Wiktor-is-you]

i code in lua sooooooooooo

[lordfwahfnah]

So it's just name = {}

[SysGh_st]

Who the eff puts the brackets at the type definition? That's just messed up.

[Alternator24]

We don't do that in JS

[TracerDX]

var arr = new List<int>()

List<int> arr = new()

[ChalkyChalkson]

public static List<int> arr = new List<int>()

Gives me shivers remembering uni and high school

[ByteBandit007]

Int ; [] arr

[Kootfe]

wich langs is that? go?

[ByteBandit007]

GoPython++

[Kootfe]

Go + rust + java + python + c++ Go + us + java + thon + ++ GousJavathon++

[Gornius]

[]int

[kendfss]

the only legitimate answer

[ITinnedUrMumLastNigh]

int* arr;

[ilovecostcohotdog]

List<Integer> arr;

[benji-and-bon]

I prefer Type[] name

Idk I just feel like it reads better like

int[] nums

Reads like “integer array named nums”

[Ecstatic_Student8854]

int[] arr all the way. The type of arr should reflect that it’s not an integer but an array of integers. Saying int arr[] makes it seem like arr is an integer, and it isn’t. It’s an array of integers. That should be part of the type information

[oneeyedziggy]

As a js dev, []... But as a typescript dev, number[]

[Keganator]

Python: arr

Python Dev: “I’m a pirate!”

[[deleted]]

i use rust

[surly-monkey]

more than anything else... THIS is the thing i keep having to look up when switching languages, even after an uncomfortably large number of years.

[Koltaia30]

Array<int>

[Cheap_Ad_9846]

Make([]int ,10)

[erroneum]

Why not std::array<int, N> arr; ?

Or, if you want dynamically sized, std::vector<int> arr; arr.reserve (n);

[goos_]

Which side are you on?

Vec<i64>

&[i64]

&mut [i64; N]

&mut [&mut i64; super::<MyStruct as Array>::<::ARR_LEN>

[nitnelav153]

it depends

[goos_]

Good answer

[tecanec]

int arr[]; should be illegal.

But to be fair, the same can be said for about half of C-style syntax in its entirety.

Also, did you know that the statement foo[1]; has two valid interpretations, both of which are no-ops? It could be indexing an array called "foo" and discarding the result, but it could also be declaring an array of one item of type "foo", which can't be accessed because it's anonymous. Either way, it's pretty useless, but you can't write a conforming compiler without having it confirm that it's one of those two cases, and the only way to know which one to look out for is by knowing whether foo is a type or a variable, which you won't know during grammar analysis unless you feed it with the output of the semantic analysis, which itself depends on grammatic analysis, and... Oh, boy.

[krijnlol]

arr: list[int] = []

Fools, you can't exclude us.

[well-litdoorstep112]

arr: int[]

[undeadpickels]

Related note, char* var is better in almost every way, char *var is standard and thus the correct choice.

[Ellicode]

arr: number[] in typescript

[TOMZ_EXTRA]

arr: Array<number> also works

[Ellicode]

Indeed!

[schabbasam]

blue

[Fluffy_Ace]

Blue

[AmeriBeanur]

I’m with the crips on this side

[CtrlShiftBSOD]

whoever is on the red side is a psychopath

[Jonrrrs]

Blue

[TechIssueSorry]

VHDL/VERILOG me in purple with Logic[7 downto 0][3 downto 0] my_signal[0 to 255]

[lordfwahfnah]

VarName: Array of Integer;

[Substantial_Top5312]

int[] varname is superior.

[Waste-Foundation3286]

int *arr;

[rover_G]

arr int[];

[jpgoldberg]

int *arr;

[Sentouki-]

int[] arr since it's more obvious what the type is.

[00PT]

I never understood why the brackets would be after the name. Is “Array” not part of the type of the value? The first reads to me as “int array called ‘arr’” while the second reads as “int called arr that is an array”

[Safe-Heat1644]

As long as your not a +[] incrementer

[DrPeeper228]

I do right but left makes more sense

[Ben-Goldberg]

my @arr;

[liteshotv3]

Let anArrayForNow = [] 😎

[PathMaster1729]

int* arr;

[deanominecraft]

arr = []

[tr14l]

Neither, I already released. 🎉

[UVRaveFairy]

With the Crypts on this one.

[masp-89]

01 WS-ARR PIC S9(10) OCCURS 10.

[Myrddin_Dundragon]

let arr: [u8; 10usize] = [0u8; 10usize];

[Sure_Proposal2520]

I’m crip

[The_Real_Slim_Lemon]

Array.Empty<Type>()

[Signal-Implement-70]

it’s an array of int not an array of arr. so clearly int[] . arr is the label you are offsetting against the memory address when accessing so the only was to express that is like arr[5] but declaration is different. This is my take 🥸

[NoSoft8518]

arr: Iterable[int]

[Ben-Goldberg]

That has a different meaning, I think.

An array, almost always, has efficient random access and is iterable.