Hello all,

There are various generic functions in Phobos that can benefit from type-specific overloads.  For example, in std.math and std.numeric, functions that deal with integers may benefit from having specialized implementations to work with BigInt.

Question: what's the appropriate location for these overloads?  In the same module as their type, or in the same module as the function they're overloading?  What are the implications for correct inferring of what function to use, or useful aliases (e.g. alias abs = std.math.abs)?

Thanks & best wishes,

    -- Joe

03-Nov-2013 13:07, Joseph Rushton Wakeling пишет:
> Hello all,
>
> There are various generic functions in Phobos that can benefit from
> type-specific overloads.  For example, in std.math and std.numeric,
> functions that deal with integers may benefit from having specialized
> implementations to work with BigInt.
>
> Question: what's the appropriate location for these overloads?  In the
> same module as their type,

Yes, it's the only path that scales.

> or in the same module as the function they're
> overloading?

Hardly scales - by the end of day they shouldn't be all imported by std.math. Plus it's BigInt business to do some dirty internal work to speed up common algorithms.

> What are the implications for correct inferring of what
> function to use, or useful aliases (e.g. alias abs = std.math.abs)?

Technically as long as the types are different there is no hijacking going on (w/o aliases). The moment you add an alias it's as if you declare it in your module, so it would fail to match on BigInt because of anti-hijacking.

//this should work though:
alias abs = std.math.abs;
alias abs = std.bigint.abs;

> Thanks & best wishes,
>
>      -- Joe


-- 
Dmitry Olshansky

On 03/11/13 10:18, Dmitry Olshansky wrote:
> //this should work though:
> alias abs = std.math.abs;
> alias abs = std.bigint.abs;

Yea, which makes sense -- any code that needs both should _know_ it needs both.

Actually, abs itself is not really a problem here as std.math.abs should work for just about any integer-like type, the real places where this will matter are stuff like greatest common divisor or least common multiple ...

I had some concern about generic numerical code that doesn't know the type it's operating on, but on the other hand such code probably shouldn't be calling a specific implementation of (e.g.) abs, gdc or whatever.