3 ms·

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 par

by 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.

by Crinus 8y ago

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.