1 year later, I'm still worried about that missed opportunity of stronger
immutability guarantees in Nim.
The whole distinction between var and let feels useless without this. When
looking at a proc signature, I have no way to know if its parameters will be
modified, unless they are
I think the new assignation semantic for strings and seqs is always copy (no
distinction between let and var). Copies are avoided whenever a move or passing
a const ref is possible. Can someone confirm this?
Restrictions about cyclic type defs and the "forwarding requirement" are
currently not in line with with nim's otherwise great flexibility, IMHO.
A "package-visibility/friendship" feature is probably needed too (but as
yglukhov said) not as a replacement of aforementioned features :)
Global scope should work as any scope, and call destructors when ending.
> adianv said: why should it be called ? x is global and gets never out of
> scope.
The whole point on RAII is to be abble to bind the lifetime of a resource to
the lifetime of an object, to make sure the resource is
if you're ok with a var object, you can do:
type Person = object
first, last: string
proc init(self: var Person, first, last: string) =
self.first = first
self.last = last
proc `=`*[T](d: var Person; src: Person) {.error.} =
discard
-d:release should use LTO whenever available on the underlying compiler if you
ask me :) Any downside on making this the default behavior?|
It would be interesting to compile it through emscripten to compare the perfs
with the original version
I was going to talk about this on IRC but I figured out a post would be more
appropriate. This is also my first post on this forum so _hello,
nim-community_. I usually don't get involved in such stuff, but since Nim is
running towards 1.0 and I have huge expectations for it, I'm making an
