Oh I got it - the twoForOne procs are only working on a copy (not ref) of Foo.
Sorry :)
Yeah, sorry, just spotted that..
If .. but `twoForOneBackConcept()` and `twoForOneBackGeneric()` do not get a
var parameter.
This may be a silly question, but in the OderWat example above, on the two proc
calls for type Foo (x), should x.v be updated in outer scope? i.e First echo
shows (v: 5, s: Test), second echo shows (v: 5, s: Test) - on my system.
Should the second call not then echo (v: 6, s: Test) considering x
First of all, reading sources and seeing `proc twoForOneBackConcept(a:
Countable): Countable` one understands the procedure's signature, what the
procedure takes and what it returns, oppositely to just using `[T]`, which is,
int this aspect, almost like in dynamically typed languages: all one ca
I think that is a good example. With generics error messages might appear
somewhere in the implementation of a procedure, and when the procedure is quite
complex and not written by the user of that procedure, the error might become
very complicated to understand.
I did not dive deeply into concepts as they are not yet "stable" but I think
this shows a bit how simple generics and concepts differ.
# a simple concept example
type Countable = concept c
inc c
dec c
type Foo = object
v: int
s: string
Yes concepts in c++ have the same design goal as in Nim. Even though concepts
can be declared as a type, they are much more like a compatibility guarantee.
To be honest, Generics in Nim (templates in c++) work already pretty well
without concepts, but in case someone puts a type into a generic f
I've seen quite a bit of discussion about concepts on this forum. However I
have not seen much description of what the end goal is for concepts (maybe I
missed it?).
In particular, are nim´s concepts mean to be similar to the equally named work
in progress C++ feature? If so, what are the diffe
