I'll be back soon

Daniel Kozak via Digitalmars-d digitalmars-d at puremagic.com
Wed Aug 10 11:38:15 PDT 2016


Dne 10.8.2016 v 14:52 Ilya Yaroshenko via Digitalmars-d napsal(a):

> On Wednesday, 10 August 2016 at 10:33:11 UTC, Martin Nowak wrote:
>> On Wednesday, 10 August 2016 at 05:49:55 UTC, Ilya Yaroshenko wrote:
>>> In addition, most of functions has very different API comparing with 
>>> their prototypes from std.algorithms: multiple dimensions, multiple 
>>> tensors, selection type, plus ndFind accepts static array as the 
>>> first argument.
>>
>> Overloads from different modules don't conflict when it's not 
>> possible to one of them. So if all of ndslice.algorithm functions 
>> only work with ndslices, and none of std.algorithm functions work 
>> with ndslices, you're fine.
>> I'd even consider forwarding std.algorithm.searching.find to 
>> ndslice.algorithm.find a better solution than adding awkward prefixes 
>> that look like we're using C.
>>
>> I haven't yet used ndslice much though.
>
> This is true for find, but not true for other algorithms, because of 
> two reasons:
>
> 1. std.algorithm works with ndslices because ndslices is random access 
> ranges composed of n-1-dimensional elements.
> 2. most of algorithms are super-templates:
>  a. template map(fun...)
>  b. template ndMap(fun...)
> so they would not work with the same namespace if names are identical.
But one can still do something like:

import nd = std.experimental.ndslice;
// now I can use nd.map which is not so different from ndMap
// and there could be some special module with aliases for those who are 
unable
// to use one char '.' extra :)
module std.experimental.ndslice.aliases;
alias ndMap = nd.map;
...


So I am against prefixes in func names like ndMap and so.




More information about the Digitalmars-d mailing list