On Fri, 16 Mar 2012 08:24:58 -0500, David Nadlinger <[email protected]>
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.
