On Thursday, 2 January 2014 at 20:23:40 UTC, Stewart Gordon wrote:
The compiler rejecting the code is the most pleasant bug that's possible IMO.
It's still unpleasant relative to the intuitive expectation that numerical types should support all basic numerical operations.
Not being overly restrictive in what types you will allow it to be used with is an important part of serving a good range of use cases.
It's a question of balance: breadth of support vs. ease of implementation and maintenance. Some use cases may be better served in other ways than rolling them into one "catch-all" type.
I'm sure we have a small handful already. We just need to find them. For instance, given the time I could probably dig up my rational number implementation and update it to current D.
I'd really like to see that anyway, for its own sake; I've been working on a std.rational based on David Simcha's work, it would be good to compare.
How would it complicate the implementation? Removing the undocumented rule whereby Complex!(Complex!T) folds to Complex!T would be a slight simplification.
It would involve non-trivial revisions to the internals of Complex.
If you want to submit a pull request supporting this I'm sure it'll be considered carefully, but it is not something to be done casually.
Maybe the right course of action is to have a parameter to the template that suppresses the type restriction and the folding rule, so that people who want to use it on a type that might not work properly can do so. This would be a relatively small change.
I do not know how familiar you are with the internals of std.complex.Complex but I think it would be a good idea to go through them in some detail before asserting that changes like this would be "relatively small".
