so crazy that that zig searches for dependency loops with DFS(basically a stack) but doesn't tell you either the stack or the duplicated value when it reports errors
11:00 i actually use b and p prefixes exclusively too. Its nice, when possible, to be able to work with variables without having to go look at type definitions. The b prefix is just to shorten boolean names which otherwise i would prefix with "should" or "is" for example "shouldJump" becomes "bJump". Boolean variables names without some sort of prefix indicating it a boolean can be confusing as to what they actually are, in my opinion. As for the p prefix i do that to avoid confusion about whether the variable is the actual thing or a pointer to the thing. It clearly indicates you should deref it if you want to access it. I dont prefix any other variables with type info because i dont think it generally hinders you to work with them when you don't know whether its a U16 or a S32 or even a F64. If its a number, then its a number, as far as the logic you have in your head when you work with them.
I guess that makes sense. I see the argument that pointers are more interesting than numbers, although I think even when just doing a subtraction knowing if something is signed or unsigned makes a huge difference (do I need to avoid overflow from subtracting a big number from a small one, etc.). I think it's possible that I see the same problem and gravitate towards a different solution. If my class/fn has so much content that I'm struggling to remember what the types of the variables are, I'm probably struggling with having to track too much context anyways. I often find myself splitting out functions for no reason other than scope isolation of variables lol
ah yes i love when i find the exact question i'm looking for but it's an OPEN GH ISSUE on the COMPILER
Compilers are just software, all software has bugs. It's no big deal :)
Can you increase font size?
could we get a trimmed version of the qr seriers after this is finished? it was great but a little too long for me
Most youtubers get around this by paying for editors =P
Jokes aside. Keep up the great work
so crazy that that zig searches for dependency loops with DFS(basically a stack) but doesn't tell you either the stack or the duplicated value when it reports errors
40:25 zig reduce needs to compile itself, then you can run -h on it.
11:00 i actually use b and p prefixes exclusively too. Its nice, when possible, to be able to work with variables without having to go look at type definitions.
The b prefix is just to shorten boolean names which otherwise i would prefix with "should" or "is" for example "shouldJump" becomes "bJump". Boolean variables names without some sort of prefix indicating it a boolean can be confusing as to what they actually are, in my opinion.
As for the p prefix i do that to avoid confusion about whether the variable is the actual thing or a pointer to the thing. It clearly indicates you should deref it if you want to access it.
I dont prefix any other variables with type info because i dont think it generally hinders you to work with them when you don't know whether its a U16 or a S32 or even a F64. If its a number, then its a number, as far as the logic you have in your head when you work with them.
Thankfully we have type hints these days
I guess that makes sense. I see the argument that pointers are more interesting than numbers, although I think even when just doing a subtraction knowing if something is signed or unsigned makes a huge difference (do I need to avoid overflow from subtracting a big number from a small one, etc.).
I think it's possible that I see the same problem and gravitate towards a different solution. If my class/fn has so much content that I'm struggling to remember what the types of the variables are, I'm probably struggling with having to track too much context anyways. I often find myself splitting out functions for no reason other than scope isolation of variables lol
In one version of the future some syntax highlighters will allow such things if you want.