I, on the other hand, am not in any way put off by someone not trying to answer every single part of a comment, when it starts out with "Odin seems like a bunch of features copied from a bunch of different languages without making sure they're (a) good and (b) consistent"!
> Things like ranges being `1..5` in one context but `1:5` in another
Is this true? Perhaps illustrate why "Slice expressions and range expressions [are] different was on purpose, as they are very different operations semantically". You should be able to clear that up easily by pointing to the language overview or something.
> but still having classic for loops which ranges almost completely obsolete
Is this unreasonable? And
> but why add the latter syntax to the language anyway, then tell people not to use it?
Same. If there are good reasons there should be good (and simple) explanations.
Questions like these should be an opportunity to clarify the whys of the language. Ignoring them is discouraging.
For slice expressions, the reason for the syntax was done on purpose for the following reasons:
* It's the same syntax as Go and Python, making it familiar to others who have used those languages
* It allows for partial ranges e.g. `x[:]`, `x[:n]`, `x[i:]`
* Partial ranges with the _two_ range expressions (a..<b and a..=b) look awful and are inconsistent: `x[..<]` `x[..=]`, `x[..<n]` `x[..=n]`, `x[i..<]` `x[i..=]`
* You effectively only ever want Python/Go like semantics with slicing because Odin is a 0-index language
* Ranges in Odin are only allowed in two contexts: `cases` and `for in` loops.
As for C-style for loops, they are not obsolete by any stretch and any one who thinks so in think that the compiler can easily optimize a magical complex iterator without any problem. In languages without C-style for loops, you'll see people try to emulate them regardless with variables and a while loop, not just an iterator.
As for syntax, where does it say "don't use it"? I really don't understand why people state things without evidence.
>As for C-style for loops, they are not obsolete by any stretch and any one who thinks so in think that the compiler can easily optimize a magical complex iterator without any problem.
In Nim, non-closure iterators are guaranteed to be inlined, so `for i in 0..<16` always compiles to what you'd write in C.
>In languages without C-style for loops, you'll see people try to emulate them regardless with variables and a while loop, not just an iterator.
There's no “emulation” going on. A C-style for loop is literally just different syntax for a while loop.
Interesting (funny) side note:
Niklaus Wirth did return the very same token named colon for ".." as well as for ":" in his Pascal compiler (page 24 and 25 in [1]). So back then you could have chosen whatever you prefer… :-)
Now that's pretty good. May I suggest if it's not there already to add it to the language FAQ?
> As for syntax, where does it say "don't use it"?
I was quoting the questioner in good faith. If I re-quoted something untrue, sorry. As for why people do things like that, yeah, seen that before and I can't explain it.
> As for C-style for loops, they are not obsolete by any stretch and any one who thinks so in think that the compiler can easily optimize a magical complex iterator without any problem. In languages without C-style for loops, you'll see people try to emulate them regardless with variables and a while loop, not just an iterator.
C-style for loops are used for three things:
- worse syntax for `for x in y..z`
- worse syntax for `for x in iterator` (although only C++ does this to my knowledge)
- being Clever, and the resulting code being unreadable
There's nothing to 'emulate'. C-style for loops are the ones doing the emulating, of range loops. It's just syntax for a particular kind of loop. There's nothing whatsoever different between a while loop and an infinite loop with a break condition, and there's nothing whatsoever different between a for loop and a while loop with a particular final operation.
But a while loop represents a construct that is useful more often than not, because you very frequently do want a break condition, while a for loop does not, because the condition-affecting operation is rarely at the end of the loop. It's precisely what I was talking about - adding it because C has it, and not because it is useful. Show me a use of a for loop that isn't an iterator and isn't a range, and I'll show you something that'd be far more readable as a while loop.
Oh, and Rust has conclusively proven that yes, you can in fact optimize ridiculously complicated iterators to tiny loops
> As for syntax, where does it say "don't use it"? I really don't understand why people state things without evidence.
You're right, I had it confused with a different feature: "The expression {} can be used for all types to act as a zero type. This is not recommended as it is not clear and if a type has a specific zero value shown above, please prefer that." Pretty much the exact same question, though.
> * Partial ranges with the _two_ range expressions (a..<b and a..=b) look awful and are inconsistent: `x[..<]` `x[..=]`, `x[..<n]` `x[..=n]`, `x[i..<]` `x[i..=]`
> * You effectively only ever want Python/Go like semantics with slicing because Odin is a 0-index language
It seems very odd to compare Odin's syntax with syntax that doesn't exist in any language, as proof that Odin's syntax is better. Why would you not compare it with the actual range syntax of a common language? Say, Rust. `x[a..=b]`, `x[a..b]`, `x[a..]`, `x[..a]`, `x[..]`, `for x in a..b`, `for x in a..=b`. I see no awful looking or inconsistent syntax there. The point is that no, there is no semantic difference between the two; a range of values between two endpoints is a universal construct, and iterating it means to scan across it, and slicing with it means to produce all the indices contained within it. And you say 'you effectively only ever want Python/Go like semantics with slicing' as though this wouldn't be true for range loops as well.
A lot of new information was released today in a collaboration between danish, swedish, german and french media. Sadly, I haven’t found a good english language article yet.
I can't imagine OpenCL in any way being involved with the rendering of the UI. Maybe you're confusing it with OpenGL?
If you're having problems making use of an eGPU (that's supported by apple, which rules out nvidia!), you should report that. eGPUs will probably be a common use case.
Regarding the new Nvidia provided mac driver, does this have any influence on Vulkan or modern OpenGL support? Or would that require changes in macOS itself (that would presumably never happen)?
I'm using a Philips BDM4065UC at home. It's just under 40", 4K at 60hz. This gives you the same pixel density as a "normal" 27" monitor, but with far more space. I prefer it over smaller dual monitors, and feel no need for more screen space.
