On 16 July 2010 20:11, Mafi <m...@example.org> wrote: > Am 16.07.2010 11:12, schrieb Heywood Floyd: > > Lars T. Kyllingstad Wrote: >> >> I do agree that, if possible, the language should match how most people >>> think. But in this case, it is impossible, because of templates. How >>> would the following example work with T = int[3], if arrays worked the >>> way you want? >>> >>> struct MyArray(T) >>> { >>> T[] a; >>> } >>> >>> C doesn't have this issue, because it doesn't have templates. And I'll >>> have my templates over C-style array declarations any time, thank you. :) >>> >>> -Lars >>> >> >> >> Well, I suppose the obvious way is to introduce array as a proper type, >> and not >> just as syntactical sugar. For instance, consider: >> >> array[11] int myArr; >> > ... > > 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. > > So why all the extra parenthesis? Do you think they are required? Instead of: shared array[3](const( array[5] immutable((SList!(int)*)[]) )) consider this: shared array[3] const array[5] immutable array (SList!(int)*) (or array[] instead of just array)
Actually, tbh I think they all look horrible. :-P I hope I never encounter such an impractical beast. > 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]; > That doesn't look too bad. Groet, Tim