And if the first branch is not true, they cannot both be `nil`.
proc `==`*[T](x, y: ref T): bool =
if system.`==`(x, y):
return true
elif x.isNil() or y.isNil():
return false
else:
return system.`==`(x[], y[])
Run
Use `system.`==`` to prevent recursive calls, as in the first branch.
proc `==`*[T](x, y: ref T): bool =
if system.`==`(x, y):
true
elif unlikely(x.isNil()):
y.isNil()
elif unlikely(y.isNil()):
x.isNil()
else:
system.`==`(x[], y[
There're two spaces before `some`, but only one of them is next to the start of
the string, so only one is stripped.
Thanks, I guess the solution then is something like:
template value_equality[T](_: type[T]) =
proc `==`*(x, y: T): bool =
if system.`==`(x, y):
true
elif unlikely(x.isNil()):
y.isNil()
elif unlikely(y.isNil()):
x.isNil()
It's a bad idea and won't work. You'll get subtle bugs.
Yeah, it means Nim 2.0 rc2 is soon.
One more optimisation
proc `==`*[T](x, y: ref T): bool =
if system.`==`(x, y): return true
if unlikely(x.isNil()):
return y.isNil()
elif unlikely(y.isNil()):
return x.isNil()
else:
return x[] == y[]
Run
> Without a borrow checker there is no way to ensure this safety so what Nim
> assumes you mean when you do var a = someVarGetter(myVal) is that you want to
> copy.
That is one reason, but the primary reason is consistency with everything else:
var x = a[i]
x = 4 # does it affe
Not sure why `trim` proc doesn't remove leading space and prints `' some'`
instead of `'some'`, [play](https://play.nim-lang.org/#ix=4shK)?
import nre
proc trim*(s: string): string =
s.replace(re("\\A[\\n\\s\\t]|[\\n\\s\\t]\\Z"), "")
let s = """{
some
Even so, you have to perform nil-checks.
proc `==`*[T](x, y: ref T): bool =
if unlikely(x.isNil()):
return y.isNil()
elif unlikely(y.isNil()):
return x.isNil()
else:
return x[] == y[]
Run
"No results matched your search" ?
Since `var T` is a memory safe pointer to a value it must exist in the end.
Without a borrow checker there is no way to ensure this safety so what Nim
assumes you mean when you do `var a = someVarGetter(myVal)` is that you want to
copy. That is all the documentation is attempting to convey. The
The part I don't understand though- with `mgetOrPut` the manual goes to great
lengths to explain that a mutable copy of the value is returned.
import tables
var t = initTable[string,string]()
var foo = t.mgetOrPut("foo", "bar")
foo = "fuz"
echo foo # prints bar, not
Oh great thanks for explaining! That helps a lot
No, I meant to define it not in `system.nim` but in my own code. But I don't
want to define it every time for every type, I want to define it only once, for
all ref types.
Please disregard the previous message, I'd overlooked something! But now I've
got it.
Okay so my Eureka moment was that there have to be two different `[]`
accessors, one for `Foo` and one for `var Foo`, and that's exactly what's
happening in the tables module where there is one for `Table` and
well as you can see in the code I sent, the most common way is to pass in an
object marked with var. Then both this object and all of it's members are
guaranteed to survive this stackframe and can be returned again in mutable form.
This is e.g. also what `Table` does, where you pass in a `var Ta
Thanks for explaining!
Can you show me how to create such an l-value and return it? If I just define a
mutable variable it resides on stack and cannot be returned.
you forgot to pass a value for key in your example, though that's not the
reason this error appears (it's there even when you fix it).
To return `f[key]` as a `var string`, it needs to be an value which can be
modified (an l value is what you would say in C land). But your `[]` proc
returns jus
Yes, for once if you have a ref object with cycles it can lead to an infinite
loop or stack overflow.
The other issue would be that it goes against the default semantics of ref
objects in Nim, which a lot of code relies on, assuming you want to replace it
in system.nim.
I don't think it's an i
It says in the manual that a mutable return value needs to be derived from the
first argument of the proc.
What is strange that for the `mgetOrPut` proc, calling `[]` seems to count as
deriving, but using a custom proc does not.
Here, it seems to be a problem that a copy of an immutable variabl
I would like to redefine it as below, would it cause any problems?
proc `==`*[T](x, y: ref T): bool =
x[] == y[]
Run
22 matches
Mail list logo
