Unexpected negative interaction between subtypes and templates #51

New issue

Closed

opened 2022-08-07 16:43:43 +00:00 by glen · 1 comment

glen commented

2022-08-07 16:43:43 +00:00

Owner

There are now a couple places where the number section has to provide identical implementations for the Pocomath types number and NumInt. That's because if not, then eventually some generic template that's not right for number gets instantiated (on a bunch of types). It can't displace a number implementation, but there's no guard against creating a NumInt implementation even though that type was properly handled by the previously existing number implementation.

This is a bug. It should not be necessary to repeat an implementation for subtypes to protect it from template override.

I think it ccould be fixed fairly easily with better checks in the template instantiation code. However, I am not going to work on that at the moment because the difficulty might become moot, depending on which parts of Pocomath are integrated into typed-function, and how.

There are now a couple places where the `number` section has to provide identical implementations for the Pocomath types `number` and `NumInt`. That's because if not, then eventually some generic template that's not right for `number` gets instantiated (on a bunch of types). It can't displace a `number` implementation, but there's no guard against creating a `NumInt` implementation even though that type was properly handled by the previously existing `number` implementation. This is a bug. It should not be necessary to repeat an implementation for subtypes to protect it from template override. I think it ccould be fixed fairly easily with better checks in the template instantiation code. However, I am not going to work on that at the moment because the difficulty might become moot, depending on which parts of Pocomath are integrated into typed-function, and how.