On Wednesday, July 14, 2010 13:57:13 Heywood Floyd wrote: > > Thank you for the elaborate answer! > > When you put it like that, it does make sense. But I'm sorry. I refuse. The > reason I refuse is those examples are void of any higher semantic meaning. > Once we add a semantic meaning, it simply becomes backwards: > > int[MAX_WIDTH][MAX_HEIGHT] map2d; > map2d[x][y] = 9; // Wrong! > > At least in my head, this is cognitive dissonance. To me, the language acts > as if it's low-level semantics outweighs my high-level semantics and I > should correct my thinking for that. I refuse! Seems to me it could just > as well work as: > > int[string][3] b; > int[3] firstB = b["foo"]; > int i = firstB[0]; > int j = (b["foo"])[0]; > int k = b["foo"][0]; > > But I feel like I'm the only one feeling this, so I'll just let it go and > hope my dear C-style arrays stay in :) > > BR > /HF > > PS. Never thought I'd find a reason to love C.. DS.
Personally, I don't like it, but I also don't think that it necessarily makes sense to change it. From the point of view of how the compiler deduces types, it's exactly how it should work. The problem, of course, is that it doesn't match how we think. However, in order for us to be able to deduce complicated types, the compiler must be totally consistent in how it deduces the type. A prime example would be function pointers (particularly using the C syntax). To be able to pick it apart properly, you're going to have to understand how the compiler does it. The type is complicated enough that you're stuck. To read arrays in the reverse order that is done now, you'd have to read everything else in the reverse order to be consistent, which would really mean types like this: [5](int) const a; The whole thing is ugly. There's no question of that. But to "fix" it breaks other stuff. Types are read right to left. Being consistent with that makes it possible to understand more complicated types. The downside is that some simpler types become harder to understand. However, as long as you use dynamic arrays, this really isn't a problem. int[][] a = new int[][](MAX_WIDTH, MAX_HEIGHT); is totally clear and it works in the order that you think. The problem is when you use statically-allocated arrays. Personally, I'd advise you to just use dynamic arrays unless you do some profiling and find that a static array is better in a particular case. Doing things that way makes it so that the weird ordering in declarations isn't generally a problem. I agree that this particular syntactic faux pas is a problem, but I don't think that anyone has come up with an appropriate solution. Simply reversing how it works now would make reading more complex types much harder. A more complex solution would likely be required. As it stands, it's a problem, but it's only a problem if you're declaring statically-allocated arrays. It's unpleasant, but it should be manageable. - Jonathan M Davis