It sounds like 0.16 might be close by, and I recalled some discussion around packed structs that would have a big impact on my code-base. I seem to always trigger the anti-bot protection on codeberg, so I only found one topic so far. A possible rename to ‘bitpacked’, although last I saw this topic ‘bitpack’ was preferred, and I seem to recall possible errors for unused struct fields? yikes.
Regardless of whether such a rename/change at this late stage makes sense, what I was most concerned with was mention of using zig fmt for forcing this migration. I wanted to understand if this is going to be a general policy / approach?
I remember the nightmare early days of Swift, that also started out close to C in syntax, and then the developers got carried away with change for changes sake because “the tools can just fix it” i.e. changes were incorrectly seen to have zero cost. Basically ignoring the cognitive cost of what was already learned, and thus had to be relearned. It got very annoying very quickly, such that point versions were almost new languages, and I switched back to Objective-C.
Anyway, Just that I’d hate to see Zig fall down that path. Stability (and platform support?) is why people still turn to C. If Zig is going to continue being ABC Simple ‘A Better C’, then stability of syntax (and a language specification) seem to be top priorities.
Yes I know the response, “It isn’t 1.0 yet!” but when you’ve been using the language since 0.7, you kinda already got used the stability it has thus far benefited from. As I’ve said before, in my eyes it already felt complete in 0.14.1. An incredible achievement in so few years
Oh and since I have my flu sickened grumpy old man hat on I saw that f32 could be subject to change too? How about keeping the stability/familiarity of f32, and naming the new real type ff32 - fast-float?
On the other-hand, a constant stream of changes and renames would keep the LLM bots confused And in that case I’d advocate for making the language test sources private too.
Yeah it’s worrisome to see “breaking” tag in excepted up coming tickets. 0.16 broke most of the code examples online. I think the new io model is great but heck if your going to break things then clear them all out . Make 0.16 nuclear spend until Oct to make the rest of the major breaking changes. So moving forward it’s like a slow tapper as zig approaches 1.0
As far as I remember zig fmt has been used a few times in the past to handle migrating breaking updates. I generally think this is fine, especially since so far I’ve been able to handle the required migrations manually. I also think it really is not a big deal to relearn a few keywords, if that’s all we need to avoid the hell of C++ clunky keywords with multiple conflicting and unintuitive meanings, then I’m all for it.
As for bitpacked though, I’m not convinced this is actually helpful, as the far bigger problem in my opinion is not remembering that it’s for bits, but remembering which of the bits actually comes first (or last?).
In general I would also take all these ideas with a grain of salt, many of them are still just that: an idea. We will definitely see more breakage in the future, but I don’t think it will be as groundbreaking as you may think. So far it seems like the team only changes things when there is a good reason for it and it’s actually beneficial to the programmer, and in that case I think it’s worth doing the migration. (e.g. I think the new Io system is pretty good, and alongside we got many improvements to other parts of the standard library, which e.g. prompted me to improve how I deal with timestamps in my game)
If Zig wants to be “a better C” then it must allow its ideas enough time to be evaluated in practical real-world projects before codifying them into a stable spec.
The language is still (explicitly) in an exploratory pre-1.0 phase of its life, and it relishes the freedom to explore radical new ideas and challenge existing conventions without being cursed with needing to uphold hasty or unviable design decisions in perpetuity.
The core team doesn’t make breaking changes for no reason, because they are not actively malicious, and when it’s possible they try to provide upgrade paths (sometimes automated with zig fmt; if you’ve been using the language since 0.7 you might remember it already having been used for upgrading code when they added multi object for loops or renamed the casting bultins), but they still have ideas that they want to try out before tagging 1.0 and they can and will break your code when they believe it’s for the greater good of the language. If such breaking changes is a deal breaker for you, then Zig is probably not the right language for you to use this point in time.
Indeed The documents I’m working from are MSB first. I came up with a simple solution, my packed struct code template starts with _0: bool = false to remind me.
Zig is already the perfect language for me to use at this point in time and so your comment has indirectly given me the simple solution; I actually have no need to upgrade. Thanks, I feel less grumpy already
I saw that f32 could be subject to change too? How about keeping the stability/familiarity of f32, and naming the new real type ff32 - fast-float?