I just noticed that something as simple as
type
Test[T] = ref object of RootObj
method call[T](t: Test[T]) {.base.} = discard
now generates a warning generic methods are deprecated.
All my relevant projects rely on generics with methods. Is there a plan for the future for such projects?
Yes, generic methods are deprecated: https://github.com/nim-lang/Nim/blob/devel/changelogs/changelog_0_20_0.md#changes-affecting-backwards-compatibility
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.
I removed all generics methods in Arraymancer, instead all my inherited types carry their "handler" proc in a field.
I had a showstopper issue with generic methods not able to resolve variant fields in Arraymancer for custom inherited types unless that custom inherited type was also generic (https://github.com/mratsim/Arraymancer/issues/327).
Generic methods are now deprecated; they never worked well.
As a constant user of them, I would say they actually worked just fine. What's the benefit of removing them? Just as a preparation for removing method altogether?
When I got into Nim I was pretty pleased to find that it even supports methods not attachable to base -- something you couldn't do in C++. I see why this has been deprecated some time ago. But deprecating generic methods in general leaves Nim even behind C++ and a whole class of problems don't have clear solution now in Nim.
I'm also a happy user of generic methods. I had originally started with tuples-of-procs and then moved code over to method.
In theory, yes, macros could give us methods. However, after looking at the various macro-powered-methods projects, I don't think any of them support generics. I'm not sure how much of a lift it is to support generics but I'm weary to assume that it's a straightforward task especially if it was deemed too costly to develop/maintain in the compiler itself.
There is also the question of whether concepts will ever support "vtr" ? If so, it seems possibly even more difficult to develop macro support for methods in a way that integrates well with concepts.
AFAIK removal of generic methods is so that under-the-hood we can switch the methods implementation to a vtable (compared to the current dispatch tree) but we do need a blog post explaining the way forward, i.e. there will be a replacement.
Regarding generic macros, you cannot use macro foo[T](x: T): untyped but you can use macro foo(x: typed): untyped you will get into a lot of headaches that I detailed here https://github.com/nim-lang/RFCs/issues/44, unfortunately several backlinks were lost in the move to a separate RFCs repo.
For the last part VTable concepts, concepts were deemed to experimental yet to build another key feature on top. The separation of the manual into a stable and experimental manual and the fine-grained {.experimental: myfeature.} pragma should help.
concepts were deemed to experimental yet to build another key feature on top
Uh that's sad, it would have been nice to have static and runtime polymorphism coexist nicely within the same mechanism
AFAIK removal of generic methods is so that under-the-hood we can switch the methods implementation to a vtable
But shouldn't a vtable be able to handle generics that are attached to the base just fine? For instance, the Test class has a vtable with a single slot for call. An instantiation Test[int] would point to an int instantiation of call, and a Test[float] would point to the float instantiation. To my knowledge that's how it works in C++.
On the other hand, generics not attached to the base, can result in multiple instantiations for a single method. This requires full program analysis, and doesn't play well with vtables.
Well yes, the problem is that we don't attach methods to a type so when you write G[T] we cannot instantiate every method that "belongs to" G. And methods we don't generate cannot participate in the dispatching process.
Now that I've written that, maybe we can instantiate generics during dispatcher generation...
Sorry to wake up the thread 3 years later, but it is the only Google-result that shows up :D
So, the deprecated message still shows up, but it seems to be working well. I am writing a small scene-graph for my render engine and wonder whether I should transition away from generic methods or not.
Some details about my use case: Generic methods are usefull for me because of the following: The scene's tree nodes (entities in the scene) need to use runtime polymorphism, to allow different types of entities to be handled during runtime (and allow users of the library to add their own entity-types). So methods are unavoidable (I guess?). Now, e.g. my mesh-entity I implemented with generics, in order to allow the user of the API to just specify vertex type and index type (uint16/uint32) for the mesh.
As far as I can see, the only other option to avoid generic methods here would be to have a macro that the API user can call to generate the non-generic method.
So the question is, in case I need to worry about the future of generic methods: What would be a good alternative here? On the other hand nim 2.0 seems to not yet have abandoned generic methods?