std.simd

Robert Jacques sandford at jhu.edu
Fri Mar 16 13:39:36 PDT 2012


On Fri, 16 Mar 2012 08:24:58 -0500, David Nadlinger <see at klickverbot.at>  
wrote:

> On Thursday, 15 March 2012 at 23:32:29 UTC, Robert Jacques wrote:
>> Then you should to leave namespace room for that higher level library.
>
> What makes you thing that there would be only one such high-level  
> library wanting to define a floatN type?

The fact that several people have proposed unifying the existing libraries  
any putting them into phobos :)

>
> There is no such thing as a global namespace in D (well, one could  
> probably argue that the things defined in object are). Thus, I don't see  
> a problem with re-using a name in a third-party library, if its a good  
> fit in both places – and you'll probably have a hard time coming up with  
> a better name for SIMD stuff than float4.
>
> If at some point you want to mix types from both modules, you could  
> always use static or renamed imports. For example, »import lowlevel =  
> std.simd« would give you »lowlevel.float4 upVector;«, which might be  
> clearer in the context of your application than any longer, pre-defined  
> name could ever be.
>
> True, we shouldn't generally pick very likely-to-collide names by  
> default just because we can so, but denying the existence of the D  
> module system altogether is going to set us back to using library name  
> prefixes everywhere, like in C (and sometimes C++) code.
>
> David

Unrelated libraries using the same name is relatively painless. Highly  
related libraries that conflict, on the other hand, are generally painful.  
Yes, there are a lot of mechanisms available to work around this, but  
selective imports and renaming all add to the cognitive load of using and  
writing the code.

To me float4 isn't a SIMD name; its a vector name and if it's implemented  
using SIMD, great, but that's an implementation detail. I can understand a  
close to the metal SIMD library and encourage the work. But if it isn't  
also going to be a vector library, if possible, it shouldn't use the  
vector names.


More information about the Digitalmars-d mailing list