Thank you, guys for sharing! I think I picked up enough ammo to continue my quest!
Not joking, no. AZERTY (France, Belgium) and QWERTZ (German-speaking countries) don’t have shifted keys for { and }, they’re accessed with the AltGr key, which lives where US layouts have the right Alt key. So instead of fluently hitting one of two big shift keys, you have to hit one small Alt key.
They’re also on number keys, this is particularly annoying for QWERTZ, where the numbers are 7 and 0, I encourage you to try and type right-Alt-0 and right-Alt-7 for a sense of how badly this sucks. With AZERTY it’s 4 and 5, so typing it with both hands is not as bad.
I know about this mainly from German programmers complaining about it, for the record, rather than out of some Special Interest in international keyboard layouts. Programmers in those countries often switch to a less onerous keyboard layout when programming, or just switch period.
5 Likes
I know I’m a bit hash, there is indeed some truly wonderful C/C++ codebase (looking at you Raylib). But my point was more that Zig is very readable so it’s easy for a beginner to look at advance Zig code and still make sense of it, the same is hard to say for most C/C++ out there unless you are already really versed into it.
1 Like
I can confirm as a French that the French ISO layout is truly god tier awful for programming, this is why I and most devs I know in France code on US or UK Qwerty but now it’s hard to find laptop with Qwerty kb 
1 Like
4 posts were split to a new topic: Neovim insert mode keybinds
Any standard library function that allocates on the heap receives an
Allocatoras parameter. Anything that doesn’t do so won’t allocate on heap, guaranteed
Actually it’s not guaranteed at all.
2 Likes
This resembles with C#/D/Swift ‘value types/reference types’ stuff.
Syntactically the same, semantically not. Bad IMHO.
Leaving aside the peculiarity of disagreeing with yourself this way, old-dee0xeeed was talking about the standard library, where so far as I know, it is in fact guaranteed that anything which allocates will take an allocator (and vice versa).
This is indeed a convention, not a law of the language, and that’s good. Application code in particular can benefit from global allocation, in terms of code organization.
If you’re not auditing a library your code is using, at least lightly, then a hidden global allocator is the least of your worries. If you spot a library (code intended to be used by other Zig code as a module) using an allocator without the entry point taking one, feel free to supply a patch, or raise an issue on the tracker, if only so that other people can be aware of it.
I am firmly of the opinion that library code should follow this convention strictly, and generically where possible. It may make sense under rare circumstances for a library to, for example, assume an arena, but it’s better if it doesn’t.
Use of an interior allocator, if there is any, should be isolated to a C interface, where there isn’t a lot of choice in the matter. We have std.heap.c_allocator as an adapter for this purpose.
1 Like
Who is that ‘old-dee0xeeed’? 
Currently I do not give an eye to Zig’s standard library,
'cause it’s evolving thing and nobody knows where it will come eventually.
I 200% agree, but there is no mechanism to prevent using memory allocations on the sly.
1 Like
True! Nor is there a mechanism to prevent a library from deleting your hard drive. Caveat author.
I think “other people won’t want to use a library which takes allocation out of the hands of the user” is enough social covenant to prevent this from becoming a problem. Time will tell.
There are enough good reasons to do otherwise that convention is what we have to work with. My experience in other language ecosystems is that it punches way above its weight. Type piracy in Julia, for instance, is exceedingly rare, simply because it’s frowned upon.
300% agree, but “other people” might not even suspect that a library they are using is doing something kinda “prohibited”.
Thank you for clarification @mnemnion. I am not sure what is the better alternative. Significant white spaces like Python or Yaml? I suffer from the same problem of not being a native English speaker and I use to use keyboard stickers, now days I just program on us-eng keyboard and use virtual keyboards to write in my native language. Anything Zig picks will hurt somebody in some shape or form. IMHO: moving from {} to anything else would alienate C programmers Zig is trying to target.
C# rules are very cut and dry (sorry, no deep knowledge of D/Swift). Value types are always passed by value (stack copy), reference types (hence the name) are always passed by reference (stack holds the reference, heap holds the actual value). BTW: C# array is a reference type, so there is no way to copy C# array items to stack.
This was my main point about ^ actually. I suspect (just based on reading the issues) that ptr.* was chosen more out of familiarity than because ^ is annoying to type on some keyboards. If you read through, it took a few passes before someone hit on [identifier] [dot] [star] being unambiguous to parse.
I think that was the better choice, personally, and Pascal was my first language. Sticking with the * familiar from C, but reversing declaration and dereferencing like Pascal, it’s a good balance.
Random fact: Pascal pointers were originally defined as ↑, not ^. The 1963 ASCII standard had an up arrow, where the caret is now. That was officially changed in 1967, but that sort of change propagated slowly, particularly in Europe.
We’ve drifted pretty far off the topic, though, which has split once already, so that’s enough lore out of me for now.
3 Likes