Why don't get rid of this for Nim 2.0? Is it overcomplicated?
> simply because in the first block I initialized Runnable outside of arguments
> list?
Yes.
Orc supports this code IIRC but I think it's a bad idea.
I've looked at std/tasks page in the stdlib, and cannot understand why's first
block does not work:
import std/tasks
type
Runnable = ref object
data: int
proc hello(a: Runnable) =
a.data += 2
block:
let x = Runnable(data:
I've read the [second example](https://play.nim-lang.org/#ix=4e9w). It's really
a problem. A use-element-address-after-moved bug, with no pointer or `addr`
used explicitly.
As you can tell, my C# training is tripping me up. Thanks for the clarification
everyone! Cheers!
> Nim does "left-to-right" everywhere but it's a design bug for assignments:
> assignments should be right-to-left.
Has this been added to the issues on Github?
> Well actually this is only 1 of the two issues I mentioned and I don't think
> the issue I was facing was either of those.
Could yo
Yes, for newbies it will be the true disaster - errors, dependencies hell, no
example source code in gitlab/github, some unexplained words in examples and so
on.
But the book is not for newbies - om page 5 it is explicitly stated "this book
for people who can already program". I would add - "an
`isNil` for seqs and strings can still be found in the
[documentation](https://nim-lang.org/docs/system.html#isNil%2Cstring), but
marked as `{.error.}`.
Well actually this is only 1 of the two issues I mentioned and also I don't
think the issue I was facing was either of those.
But also, I do understand that these things are not easy to solve from a
compiler perspective.
Your code shouldn't compile on devel (nimv2). The problems are many. For one
the i member might now contain garbage, if it was a variable with an internal
pointer like a seq/string/etc that could cause segmentation fault. Also is if
you switch branches without freeing memory you get a memory lea
Let's say I have this type of _ref object_ :
type
ValueKind = enum
Integer
String
Block
Value = ref object
case kind: ValueKind:
of Integer:
i: int
of String:
Nim does "left-to-right" everywhere but it's a design bug for assignments:
assignments should be right-to-left. ;-)
This is a relatively well-known corner case. Different languages define the
order of evaluation for assignments differently.
**C++:** implementation defined.
**D:** implementation defined.
**Python:** order of evaluation is left-to right, but for assignment it's
right-to-left.
**Java:** chose
Ok I will try that, thank you.
15 matches
Mail list logo
