5 ms·

Thanks! 1. Right now, you can emulate this with the transmute builtin function. Not yet sure if the additional complexity of this feature would be worth it. 2

Thanks! 1. Right now, you can emulate this with the transmute builtin function. Not yet sure if the additional complexity of this feature would be worth it. 2. Array bounds checks can be avoided by using the unchecked_index builtin. Uninitialized locals are not yet possible, but I think it makes sense to eventually add a construct to allow that, for situations that need every last bit of performance. 3. I've only started to look into LLVM recently, thanks for the heads up. 4. See my comment here: https://news.ycombinator.com/item?id=19599908 https://news.ycombinator.com/item?id=19599908 5. C# programmers would like to disagree with you ;). Note that the formatting issue is not due to significant whitespace, as you'd have the same issue writing up a Golang snippet. 6. Editor support (specifically, language server) should help a lot here. 7. The string based types are only used for inserting the right cast to make the C compiler happy, so they should not be an obstacle. 8. Compile time evaluation can be used for some cases. Adding a preprocessor comes with its own set of tradeoffs, haven't yet decided what to do there. 9. A lowercase l looks a lot like a 1 in many fonts, hence the uppercase L. Will consider adding an i suffix.

Crinus 8y ago
1. The point of this is to avoid repeating the common headers and have the type system validate that a pointer/reference of a subtype is compatible with its parent type (in C you'd need to typecast which can be dangerous). 5. I also tend to name dynarrays as lists, but in this case you have both List and Array and the only difference seems to be that one has a capacity while the other doesn't. Having both can be a bit confusing when you actually wanted a (linked) list. 6. It will only help when inside the editor, hence why i explicitly wrote "when looking at its use in a diff (or any other non-syntax highlighted, non-code aware code viewing context)". 8. None of the examples i mentioned can be solved with compile-time evaluation (except some cases of IFDEF DEMO) since they change what code is actually compiled (e.g. if you want to use an API that may not even be available on a target - like e.g. DirectX on Linux) or generate code themselves. 9. I do not think it makes much sense to worry about that, there are fonts that have 0 and O look the same, let the user fix their fonts, do not punish those who use unambiguous fonts with inconsistency. Trust your users.
- nickmqb 8y ago
  1. That's true, I didn't mean to imply that transmute is equivalent, there would definitely be benefits to the feature you're suggesting. But it also brings additional complexity of course. 6. Sorry, I totally missed that part of your comment! A language server won't help in that case. At least wrt to return types though, you're always allowed to specify them for clarity. I can imagine building some tooling that automatically infers and adds explicit return type annotations if they are missing. You could run this as a commit hook if you wanted to enforce that as a coding standard. 8. Right, I was referring to the IFDEF DEMO case (assuming it's used to implement straightforward feature flags). I agree that for the other cases that you mentioned we'd need something else. For now, for some situations, you could compile with different files (e.g. gfx_opengl.mu, gfx_directx.mu, etc.), though it's a pretty crude solution, especially if you want to combine conditions (e.g. Linux + OpenGL). Definitely thinking about this.

Crinus 8y ago

1. The point of this is to avoid repeating the common headers and have the type system validate that a pointer/reference of a subtype is compatible with its parent type (in C you'd need to typecast which can be dangerous). 5. I also tend to name dynarrays as lists, but in this case you have both List and Array and the only difference seems to be that one has a capacity while the other doesn't. Having both can be a bit confusing when you actually wanted a (linked) list. 6. It will only help when inside the editor, hence why i explicitly wrote "when looking at its use in a diff (or any other non-syntax highlighted, non-code aware code viewing context)". 8. None of the examples i mentioned can be solved with compile-time evaluation (except some cases of IFDEF DEMO) since they change what code is actually compiled (e.g. if you want to use an API that may not even be available on a target - like e.g. DirectX on Linux) or generate code themselves. 9. I do not think it makes much sense to worry about that, there are fonts that have 0 and O look the same, let the user fix their fonts, do not punish those who use unambiguous fonts with inconsistency. Trust your users.

nickmqb 8y ago
1. That's true, I didn't mean to imply that transmute is equivalent, there would definitely be benefits to the feature you're suggesting. But it also brings additional complexity of course. 6. Sorry, I totally missed that part of your comment! A language server won't help in that case. At least wrt to return types though, you're always allowed to specify them for clarity. I can imagine building some tooling that automatically infers and adds explicit return type annotations if they are missing. You could run this as a commit hook if you wanted to enforce that as a coding standard. 8. Right, I was referring to the IFDEF DEMO case (assuming it's used to implement straightforward feature flags). I agree that for the other cases that you mentioned we'd need something else. For now, for some situations, you could compile with different files (e.g. gfx_opengl.mu, gfx_directx.mu, etc.), though it's a pretty crude solution, especially if you want to combine conditions (e.g. Linux + OpenGL). Definitely thinking about this.