Conflating pointers with arrays: C's biggest mistake? (2009)
The proposal here is way too vague. And if you flesh it out, things start to fall apart: If nul-termination of strings is gone, does that mean that the fat pointers need to be three words long, so they have a &quot;capacity&quot; as well as a &quot;current length&quot;? If not, how do you manage to get string variable on the stack if its length might change? Or in a struct? How does concatenation work such that you can avoid horrible performance (think Java&#x27;s String vs. StringBuffer)? On the other hand, if the fat pointers have a length and capacity, how do I get a fat pointer to a substring that&#x27;s in the middle of a given string?<p>Similar questions apply to general arrays, as well. Also: Am I able to take the address of an element of an array? Will that be a fat pointer too? How about a pointer to a sequence of elements? Can I do arithmetic on these pointers? If not, am I forced to pass around fat array pointers as well as index values when I want to call functions to operate on pieces of the array? How would you write Quicksort? Heapsort? And this doesn&#x27;t even start to address questions like &quot;how can I write an arena-allocation scheme when I need one&quot;?<p>In short, the reason that this sort of thing hasn&#x27;t appeared in C is not because nobody has thought about it, nor because the C folks are too hide-bound to accept a good idea, but rather because it&#x27;s not clear that there&#x27;s a real, workable, limited, concise, solution that doesn&#x27;t warp the language far off into Java&#x2F;C#-land. It would be great if there were, but this isn&#x27;t it.