std.complex
Joseph Rushton Wakeling
joseph.wakeling at webdrake.net
Thu Jan 2 13:10:40 PST 2014
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".
More information about the Digitalmars-d
mailing list