lumberjackstian
Joined 9 years ago
Karma
20
Submissions
19
Member since
Nov 27
Recent submissions
Comment · 6 years ago
Ah right! I misread and assumed the course had happened before . Seems it was a small group in a prelaunch test.
Comment · 6 years ago
I'm not sure about much analysis and theory that explicitly captures branch prediction, but in last year's cppcon keynote Andrei offered a possible metric [0] where he takes into account the average "distance" between two subsequent array accesses.
It's basically, (C(n) + M(n) + kD(n)) / n
Where M is moves, C is comparisons, k is a some constant, and D is "distance".
Comment · 6 years ago
Why is lazy a failure and what makes it so?
And are there any languages where lazy is not a failure in your opinion?
Edit: removed link to wrong swift feature proposal.
Comment · 6 years ago
Aye correct! I should've been more clear about that, sorry.
Template arguments need to be known at compile time, and the extra set of parens is how templates parameters are declared in D.
Comment · 6 years ago
Yeah I realise I could've explained a bit more about template arguments indeed! The point was that it can be hard to specify the return type.
Comment · 6 years ago
When it comes to templates it's not until instantiation time - when the compiler see the code being used. So this is just an issue during compilation.
The docs on static if may shed some more light: https://dlang.org/spec/version.html#staticif
Comment · 6 years ago
Depends on the value of the template parameter. If it's 0 the return type is an int, if it's not 0 the return type is a string.
There's a wanting implementation of a sumtype in the standard library (https://dlang.org/phobos/std_variant.html#.Algebraic), and a much better one as a package: https://code.dlang.org/packages/sumtype
Comment · 6 years ago
I've felt this as well, been using D for a couple years now, and this is the kind of thing that just makes me have to context switch more than I'd like. With the current implementation of the language it's hard to avoid, and function's return type can be quite complex, so writing it down can be hard.
Another reason is the (ironically) dynamic nature of a return type. E.g.
auto whatDoesItReturn(int i)() { static if (i == 0) { return int.init; } else { return string.init; } }
Template code can do that quite easily and then you don't have a choice but to write auto as the return value.
What would be fantastic if the documentation could be given access to the the compiler's return type inference, so that it could document the auto returns with a little more info.
Another way useful approach would be to implement protocols like in swift, or traits like in scala/rust/others, signatures in ml, etc. Then you would be able to define the interface of what a function returns.
Comment · 6 years ago
Relevant post in a discussion thread that's related to the future of lazy in D: https://forum.dlang.org/post/[email protected]...