Since nobody else is doing it, I'll be the one to write this forum thread.
Nim v0.20.0 is here, if you have been living under a rock the release article is here: https://nim-lang.org/blog/2019/06/06/version-0200-released.html ;)
1st, huge thanks to everyone who worked on nim.
2nd, if you happen to end on a "cannot allocate memory" error while compiling this in raspbian, it is probably because you have a program eating all your ram; chromium in my case.
2nd, if you happen to end on a "cannot allocate memory" error while compiling this in raspbian, it is probably because you have a program eating all your ram; chromium in my case.
Try to compile the compiler via koch boot -d:danger -d:leanCompiler. It takes 330MB on my machine.
I've uploaded a new kind of Docker image to the Hub, based on choosenim instead of manually built binaries: https://cloud.docker.com/u/nimlang/repository/docker/nimlang/choosenim
So, if you need an image for Nim 0.20.0 and don't care that much about its size, feel free to pull nimlang/choosenim. If you need devel version, just add choosenim devel to your Dockerfile.
under the old design so called "self assignments" could not work.
Consequence: sink parameters for objects that have a non-trivial destructor must be passed as by-pointer under the hood. A further advantage is that parameters are never destroyed, only variables are. The caller's location passed to a sink parameter has to be destroyed by the caller and does not burden the callee. (with the following problem example:)
from ranom import randomize, rand
proc select(cond: bool; a, b: sink string): string =
if cond:
result = a # moves a into result
else:
result = b # moves b into result
proc main =
var x = "abc"
var y = "xyz"
# possible self-assignment:
x = select(rand(1.0) < 0.5, x, y)
# 'select' must communicate what parameter has been
# consumed. We cannot simply generate:
# (select(...); wasMoved(x); wasMoved(y))
# NOTE, WE DON'T HAVE TO; IT JUST WORKS...
However, it seems that things have been fixed so the above example does work in Nim version 0.20.0 with the compiler using a combination of the hooks and ismoved called on the parameter that is used and not on the other one; the main difference between as it works now and as proposed in Destructors spec 2 seems to be the different type signature on =sink than =move with the current one having a var only on the destination parameter where the second has a var on both parameters, and what the compiler is doing underneath rather than combining the destination destruction and source resetting in the assignment and moving "hooks"
The new =move[T](dst, src: var T) not available yet has a different type signature than the =sink[T](dst: var T; src: T) it functionally replaces due to having to modify its source to reset it to show that it has been transferred (an implicit move); As these are automatically invoked when ownership is transferred under move semantics along with "cheats" so that the var parameter can be applied to a let variable, the only work around is to make all bindings to which we want to apply it var's and not let's and manually invoke a move on the source of the sink parameter when in the sink proc.
I don't know enough about the implementation details to know what is the easiest way, but it seems to me that a decision should be made whether to use the current =sink syntax or the new =move syntax (along with the changed definition of all of the "hooks") so that there aren't breaking changes forward.
In other words, it seems to me that the new Destructors spec 2 has two distinct parts as follows:
If implemented as per the spec, the first would be a breaking change due to the different signature of the =move hook and I would recommend that, if desired, it be included pre-version 1.0. This doesn't seem to be risky at all as the functionality seems to be the same as currently, although it could break some libraries due to the different syntax.
The second isn't very much a breaking change other than making such kludges as are necessary to make closures work across threads no longer be necessary and requiring an occasional owned, and as you say the compiler will guide where those are necessary. As this is relatively untested as yet, it likely should be deferred to a later point upgrade version or version 2.0.
If somehow development of the second could be accelerated to be included in version 1.0 if it works, it would make me happy ;-)
I'm sad to see strongSpaces go. (hey I still kinda prefer the old case insensitivity back when Nim was still Nimrod).
Are there plans to have a bunch of awesome examples and PR material prepared once we hit 1.0?
Are there plans to have a bunch of awesome examples and PR material prepared once we hit 1.0?
Hmmm good idea... :D
This is great. As a sidenote, I'm getting smaller final executables in Windows with MSVC 2019 compiler. Looking into the final binary I see less "holes" in the generated file. Are we using different switches regarding alignment or something like that?
Where I can read about the "New Runtime"?
Thanks!!!
After a month of hard work, our second release candidate of Nim 1.0 is ready — Nim v0.20.2:
https://nim-lang.org/blog/2019/07/17/version-0202-released.html