> All my relevant projects rely on generics with methods.
Well that's bad, we need to find a solution. In my mind I `method` is better
replaced altogether with a `class` macro that produces a traditional VTable.
On one hand, I can't see why methods couldn't be generic… on the other hand, I
can't think of any compelling reason to combine runtime and compile time
polymorphism. At least not explicitly.
Looks like this package broke after a deprecation in Nim 0.20.0.
See
[https://github.com/nim-lang/Nim/blob/devel/changelogs/changelog_0_20_0.md#breaking-changes-in-the-standard-library](https://github.com/nim-lang/Nim/blob/devel/changelogs/changelog_0_20_0.md#breaking-changes-in-the-standard-libr
Only generic **methods** are deprecated. Generic procs (types, etc.) are not
affected by this.
Yes, generic methods are deprecated:
[https://github.com/nim-lang/Nim/blob/devel/changelogs/changelog_0_20_0.md#changes-affecting-backwards-compatibility](https://github.com/nim-lang/Nim/blob/devel/changelogs/changelog_0_20_0.md#changes-affecting-backwards-compatibility)
I haven't upgraded yet (will do after I ship this next project), Have you
noticed this warning with Generic Procedures?
I just noticed that something as simple as
type
Test[T] = ref object of RootObj
method call[T](t: Test[T]) {.base.} = discard
Run
now generates a warning `generic methods are deprecated`.
All my relevant projects rely on generics with methods. Is there a
@Araq, as I have mentioned in other posts, I am trying to apply some of the new
memory management ideas under the current version 0.20.0 system, with problems
as follows:
1\. The "old" closures aren't compatible with what closures will be as they
rely on a (local) GC'ed ref to an environment st
> Nim 0.20.0 is now in Debian Unstable and will trickle down to Ubuntu and
> other derivatives.
Also, Nim 0.20.0 is now in Manjaro Testing, and it will probably be in the next
Manjaro Stable updade.
