Remove const qual from covariant methods in Type hierarchy

[edi33416]

This PR is useful to the the C++ header generator to generate the dmd frontend header files that are used by gdc.

For a detailed description of the motivation, please see PR

This is an alternative to #10319 , as making the methods const proved to be a non-trivial issue. For more details about this, follow the discussion from this comment downwards.

[dlang-bot]

Thanks for your pull request and interest in making D better, @edi33416! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please verify that your PR follows this checklist:

• My PR is fully covered with tests (you can see the coverage diff by visiting the details link of the codecov check)
• My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
• I have provided a detailed rationale explaining my changes
• New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.

---

If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub fetch digger
dub run digger -- build "master + dmd#10330"

[edi33416]

CC @jacob-carlborg @rainers @ibuclaw @Geod24

[jacob-carlborg]

What's the point of removing existing const?

[andralex]

@jacob-carlborg D supports a finer-grained covariance than C++, which does not allow covariance on const methods overriding non-const methods.

[jacob-carlborg]

Ok, I see.

[andralex]

cc @WalterBright

[Geod24]

This does not seem like an improvement to the code.
Covariant const is a great tool, and AFAIK is currently supported in the bindings we have, so loosing this because of auto-generation is far from appealing.

[rainers]

The manual C++ headers just add the additional qualifiers as comments. Can't the header generator just do the same, i.e. emit the prototype of the function as declared in the introducing base class?

[edi33416]

Closing this as I made the header generator emit the prototype of the function as declared in the introducing base class, as @rainers suggested.