There’s been a lot of talk in the last few years about major language features that Delphi doesn’t have. Stuff like Unicode and Generics which finally got added in D2009, stuff like 64-bit compilation that’s perenially slated for another year or two out, and so on. There’s currently a major debate going on (and on and on) in the Delphi forums about the team’s statement that the next release won’t include inline assembly, and the effects that that will or won’t have on library compatibility and future development.
But there are also more minor, simple things that we don’t have, and some of them are a little bit silly.
For example, what’s wrong with this code?
const NAMES: array[0..3] of string = ('Alice', 'Bob', 'Catherine');
Well, that’s pretty simple, actually. In case you don’t immediately notice the issue, the compiler will point it out to you the instant you try to build:
[DCC Error] E2072 Number of elements (3) differs from declaration (4)
So we see that the Delphi compiler is perfectly capable of correctly counting the number of elements declared in a const array, and of giving you an error if that number is not the same as the number of elements you declared that you were going to put in the array.
Which brings me to my question. Since the compiler is capable of correctly counting the number of elements you put there, and since the concept of dynamic arrays exists in Delphi, wherein you’re not required to declare a size upfront, why won’t this compile?
const NAMES: array of string = ('Alice', 'Bob', 'Catherine');
Can someone give me a good reason why? Because I really can’t think of one. We’re not introducing any new syntax into the language; “array of” has been around for years. And in situations where you’ve got long arrays of const records that need to be updated frequently, (something I’ve dealt with both at work and in personal projects,) having the compiler use its built-in array-element-counting skills for you instead of against you would be very nice.
As long as you don’t need the first element’s index to be something other than 0, there’s really no point in having to repeat the same information (the upper bound) twice, once as a number and once as an inherent part of the list of elements. That’s a bit of a DRY principle violation there, and it’s painful for exactly the reason they came up with the DRY principle in the first place: because when you change one of the two, you have to change the other one too or else it breaks.
So does anyone know why this doesn’t work yet?