Mafi Wrote: > > I don't really like it. Of course the order of indices feels better but > it breaks the rule of reading types from right to left. It also > introduces more parenthesis and a new keyword into types (amongst const, > immutable and delegate etc). Consider: > shared array[3](const( array[5] immuttable((SList!(int)*)[]) )) > WTF, that doesn't look good. I would be a real type if your answer was > accepted. > > It was > shared const( immutable(Slist!(int)*[])[5] )[3] > which reads perfectly from right to left. > > What about this: > // int[width,height] as sugar for int[height][width] > int[width,height] arr = ...; > // arr[x,y] as sugar for arr[x][y] > int element = arr[x,y]; > // then this works as expected > int[height] column = arr[x];
Interesting! First of all, I definitely think that how arrays are declared now would have to stay just the way it is, no matter what. I don't think stuff like that is changeable this late in a language. But, seems to me these two methods of declaring arrays could coexist. One is the shorter syntactical "sugar" method, the other is the elaborate, but perhaps clearer method. These kinds of long way/shortcuts are already in the language, I believe. Like how void()() is automatically a template, comes to mind. (Or did that make sense?) Then, I simply can't resist commenting this exceptional beauty. I'm gonna call it theThing: shared const( immutable(Slist!(int)*[])[5] )[3] theThing; Well. I have to confess, to me, it doesn't read perfectly from right to left. I might be reading it wrong, but to me it reads from right to left, and from left to right, at the same time. Is it a shared const array of something, or a shared array of const something? You can't really tell unless you go back and forth, and almost count the parenthesis. For instance, by looking at the declaration above, what type is a theThing[0][1] ::= ?? It's really not easy to say, for me anyway. I'm sure you get better at reading these things. So it might not be fair to say that it's "unclear". It's just my subjective opinion, and that may be biased by my lack of experience in the matter. Now back to the other thing: shared array[3] const array[5] immutable array[] (SList!(int)*) Sure, this is too verbose. I agree. Still, I think it's clearer. Much clearer. Verbose, but clear. Here I couldn't help but making an interesting obvservation: Those storage classes could also be seen as types. What if we allowed the storage classes to have some syntactical sugar too, for arrays? We could have: shared[3] const[5] immutable[] SList!(int)* theThing; That does read from left to right in one go, and to me, it's still clear what's going on, and, it's not verbose. In fact, it's less verbose than the parenthesis-sprinkled version we saw first. Further, it's almost magically easy to read: We have a shared array of 3 const arrays of 5 immutable dynamic arrays of Slist!(int)*. It just reads, like you read text, quite naturally. (I'm not sure this would actually be the same type as the first declaration, erh, but yes. You get my intention.) So again, what type is a theThing[0][1] ::= ?? Well, if we look at the declaration above it's quite easy: We just cut the line after the second array, const[5], and the rest of the line, that's our type. theThing[0][1] ::= immutable[] SList!(int)* Now, to me, that's just plain beautiful. *** And last, the int[x,y] arr; I like it. Simple. Nice. Maybe it becomes weird when we have mixed array types, like int[uint,,5] arr? Well at least the illusion of an intact order is maintained. BR /HF
