One other wrinkle more in line with this thread topic is making things work for
general object types but specific standard key types. In C one might handle
that by taking an `offsetof` for where they key field is within an object and
`sizeof` for the size of object in the array. In Nim, one
@Stefan_Salewski - I think this idea of having a family of overloaded procs to
sort on standard types is very good. I have almost raised it myself several
times.
It would be useful for `cmp`-less `sort` procs on such type to be _stable_
sorts (meaning elements with identical keys retain
Reading this blog post
[http://nibblestew.blogspot.de/2017/11/aiming-for-c-sorting-speed-with-plain-c.html](http://nibblestew.blogspot.de/2017/11/aiming-for-c-sorting-speed-with-plain-c.html)
> I just remembered a discussion some time ago:
S. Salewski wrote:
> A consequence may be, that for
The symbol binding rules for generics are outlined in the manual
[here](http://manual.nim-lang.org/docs/manual.html#generics-symbol-lookup-in-generics).
It might help if the section defined what exactly 'open' and 'closed' symbols
are, since most programmers don't know about compiler-specific
> Why should it be surprising? Procedure calls and field accesses in generics
> aren't resolved until instantiation time.
Yes, you may know that from other languages, I can not remember reading it in
the Nim docs. I saw a hint in Tables module defining a custom hash proc, but
until today I
Why should it be surprising? Procedure calls and field accesses in generics
aren't resolved until instantiation time. What if wuff was a field of 'a'?
Anyway, if by 'inlining' you mean, 'can the Nim compiler/backend compiler
inline generics', then yes, it can be inlined.
I don't quite
# module m1
proc p1*[T](a: T) =
echo a.wuff
template t1*[T](a: T) =
echo a.wuff
# module m2
import m1
type
T = object
i: int
proc wuff(a: T): string =
result = "miau"
var t: T
m1.t1(t)
