Skip to content

Conversation

@xoxorwr
Copy link

@xoxorwr xoxorwr commented Aug 28, 2025

This feature is common in C, so I was surprised it wasn’t supported in Odin. Without it, I had to write a separate function to copy the string at runtime, even though this could, and should, be done efficiently at compile time.

@Kelimion
Copy link
Member

It's already allowed for [N]u8 where N == len(str), e.g.:

main :: proc() {
	str: [8]u8 = "Hellope!"
	fmt.println(string(str[:]))
}

The question is whether @gingerBill wants to allow a smaller N to initialize using part of the string literal, and larger N to zero-fill the remainder.

@gingerBill
Copy link
Member

I don't particularly like the implementation done here but I'll explain my hesitation for it.

It might be that "This feature is common in C", but you have to understand why it works in the first place and why it is consistent with the rest of C's semantics.

In a way, "Hellope" is a pseudo-shorthand for (char[]){'H', 'e', 'l', 'l', 'o', 'p', 'e', 0} but stored in a specific data section. Now when you take this into consideration that it's an array, the logic starts to make more sense.

In C, you can do the following and it works still:

int x[5] = {1, 4, 9}; // misses the last two elements

In Odin, we consider this a bug, and if you want this specific behaviour, you need to explicit state the fields:

x: [5]i32 = {0 = 1, 1 = 4, 2 = 9}

Odin does allow assigning a string literal to a [N]u8 array if N == len(str). But what you are asking for is to mimic the C behaviour which would make it inconsistent for the rest of Odin.

I know how useful it is to assign a string literal to a byte array which is why Odin's copy is overloaded to support this.

What you're effectively wanting to support is to allow it within a struct compound literal.

So as to what I'll do, that is something I need to mull over because it's a question of being pragmatic and where that leads.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants