Sean Kelly wrote: > On Sep 12, 2011, at 1:12 PM, Adam Burton wrote: > >> Sean Kelly wrote: >> >>> Looks much nicer than the current std.socket. A few random comments >>> from a quick scan of the code: >>> >>> Socket.send/receive should use ubyte[], not void[] for the data. >> Regardless if it is correct or wrong I think there is a reason it is >> void[] (I am sure you are aware of this but just in case you are not ;)). >> All arrays implicitly convert to void[] >> (http://www.digitalmars.com/d/2.0/arrays.html - Implicit conversions) and >> the array length is automatically modified such that it is a byte count >> (for example assigning a dstring "hello" to void[] sets void[]'s length >> to 20 while dstring is 5), this lets you send data to send/receive >> without having to cast it. I've inferred that to mean void[] is expected >> for buffers of bytes and ubyte[]/byte[] as arrays of bytes. > > Sure… but is this a feature that's actually desirable here? I suppose it > would be good for sending char strings, but other than that I'd probably > want to serialize the data somehow before sending it. Like I said, regardless if it is correct or wrong. I'm not arguing for it either way I was just making sure it was known why it would use void[].
If the data is serialized or not it makes no difference if send/receive uses ubyte[] or void[] since void[] can handle both. I quite like the idea of void[] representing a chunk of memory that could contain anything, serialized data; an array of ubytes or strings, and allow ubyte[] to just represent an array of ubytes (after all is serialized data an array of bytes or a block of data containing various data types cramed into it in some organised manner?). In the end it is just a convention I like, not attached to it or anything, and D tends to discourage working based on conventions anyway, I guess I am somewhat playing devil's advocate in this paragraph :-). The only reason I can see not to change it to ubyte[] is it seems to me a change that would be breaking, due to some code maybe needing casts, (or atleast require a fairly simple deprecation) with no real benefit (as far as I can see). That's assuming it is not turned into std.socket2 :-).
