<div class="gmail_quote">On 16 March 2012 22:39, Robert Jacques <span dir="ltr"><<a href="mailto:sandford@jhu.edu">sandford@jhu.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Fri, 16 Mar 2012 08:24:58 -0500, David Nadlinger <<a href="mailto:see@klickverbot.at" target="_blank">see@klickverbot.at</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Thursday, 15 March 2012 at 23:32:29 UTC, Robert Jacques wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Then you should to leave namespace room for that higher level library.<br>
</blockquote>
<br>
What makes you thing that there would be only one such high-level library wanting to define a floatN type?<br>
</blockquote>
<br></div>
The fact that several people have proposed unifying the existing libraries any putting them into phobos :)</blockquote><div><br></div><div>I personally can't see it happening. Above the most primitive level that I've tried to cover with std.simd, I think it'll be very hard to find agreement on what that API should look like.</div>
<div>If you can invent a proposal that everyone agrees on, I'd be very interested to see it. Perhaps if you extend the fairly raw and D-ish API that I've tried to use in std.simd it could work, but I don't think many people will like using that in their code. I anticipate std.simd will be wrapped in some big bloated class by almost everyone that uses it, so why bother to add the emulation at that level?</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>

<br>
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.<br>

<br>
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.<br>

<br>
David<br>
</blockquote>
<br></div>
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.<br>

<br>
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.<br>

</blockquote></div><br><div>Can you give me an example of a non-simd context where this is the case? Don't say shaders, because that is supported in hardware, and that's my point.</div><div>Also there's nothing stopping a secondary library adding/emulating the additional types. They could work seamlessly together. flaot4 may come from std.simd, float3/float2 may be added by a further lib that simply extends std.simd.</div>