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