# Defining real and complex variants of an abstract type for vector calculus

**URL:** <https://fortran-lang.discourse.group/t/defining-real-and-complex-variants-of-an-abstract-type-for-vector-calculus/7843>\
**Category:** Help\
**Created:** [April 15, 2024, 8:25am UTC](https://fortran-lang.discourse.group/t/defining-real-and-complex-variants-of-an-abstract-type-for-vector-calculus/7843 "2024-04-15T08:25:49Z")\
**Posts on this page:** 1\
**Showing post:** 8

<div class="post-metadata">

**Author:** ![FedericoPerini](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/federicoperini/32/1750_2.png) [@FedericoPerini](https://fortran-lang.discourse.group/u/FedericoPerini)\
**Post date:** [April 16, 2024, 1:38pm UTC](https://fortran-lang.discourse.group/t/defining-real-and-complex-variants-of-an-abstract-type-for-vector-calculus/7843/8 "2024-04-16T13:38:03Z")

</div>

> [@loiseaujc](#):
>
> it’ll be beneficial in the long run

I like this and @hkvzjal’s FSPARSE approach: pre-processing is the most productive usage of your code right now. Unfortunately, the current Fortran standard does not allow any smart generics coding with number types, because the `class(*)` approach is really mainly useful for vertical inheritance, but not as much for horizontal polymorphism (plus, it is resolved at runtime hence slow, if repeated many times). Some including myself have been hoping to see number-centered generics features such as with `real(*)` or `numeric(*)` (sounds Fortrannic, does it?) being considered for an upcoming language proposal, but that’s not going to happen anytime soon.

---

_[View the full topic](https://fortran-lang.discourse.group/t/defining-real-and-complex-variants-of-an-abstract-type-for-vector-calculus/7843)._