More D newb questions.

Walter Bright newshound1 at digitalmars.com
Mon May 5 22:44:49 PDT 2008


Me Here wrote:
> So why would defining opCat for the basic types, suddenly cause (or require)
> that opCat's defined for composites to behave differently?

First of all, what if you wanted
	T ~ T => T[]
for *all* types in generic code? You've got an obvious problem, because 
it behaves very inconsistently for different types. Secondly, what about 
structs? Should structs behave like basic types, or like arrays here? (I 
discussed this conundrum further in another post in this thread.)


> Had someone pointed out earlier that my immediate problem could be solved by
> using:
> 
> 	table[ 
> 	    b1 << 14 | b2 << 12 | b3 << 10 | b4 <<  8 | 
> 	    b5 <<  6 | b6 <<  4 | b7 <<  2 | b8 
> 	][] = [ 
> 	    abcd[ b1 ], abcd[ b2 ], abcd[ b3 ], abcd[ b4 ], 
> 	    abcd[ b5 ], abcd[ b6 ], abcd[ b7 ], abcd[ b8 ]
> 	]; (**)
> 
> We probably wouldn't be having this conversation. But that doesn't persuade me
> that catenation of basic types wouldn't a) answer peoples expectations; b) or
> break generics. That said, I'm not at all sure that string handling /should/ be
> dealt with using generic array type manipulations.

I don't know of any reason why it shouldn't be (since arrays are a 
fundamental data type), or why having 'c'~'d' is so advantageous we 
should preclude generic code from manipulating arrays.

> Insertions, deletions and
> in-place mutations are very common operations on char[]s, but far less so on
> int[] real[], creal[] etc.

That doesn't justify treating them inconsistently. Remember, this 
started out with the complaint about an inconsistency. I don't agree 
that it's an inconsistency, but assuming that it is, at least one gets a 
reasonable error message for it, rather than silently doing something 
surprising.


> What does that equate to, maybe 8 or 10 opcodes?

That's a lot when you're faced with a "D sucks because array ops are 
slow" benchmark. It can double the time in the loop.


> (*BTW. Why does char[] replaceSlice(char[] string, char[] slice, char[]
> replacement) require both the target string and target slice of that string?)

Because all three parameters are needed to give sufficient information.



More information about the Digitalmars-d mailing list