A few items I'd like to see added to BRS. Figured maybe if I list them here, others will join in with ideas, and maybe some will make sense to Roku and be possible to implement without breaking existing code. Some of these have easy work arounds of course, but could be done better in the compiler I think. Some may be there already and I just haven't noticed them, and will appreciate being pointed in the right direction.
Switch / Case, this has come up more than once, even Joel piped in as something he'd like to see if memory serves me right. Using a compile time hash based jump table like C#, a run time check with ranges like TurboPascal/Delphi, or even a brute force walk (syntactic sugar to if else else else...). Any of them would be awesome, and the first one would be much more efficient than the stacked elses we have now.
A tokenize that doesn't eliminate empty values. This would allow better parsing of CSV and other non XML/Json EDI data, either using new function, or adjusting tokenize to have a second arity to all this. We can do this with Regex now but that is rather slow.
A case insensitive string compare, this could be implemented in the base compiler code much more efficiently than us adjusting to lower or upper case before compare.
Compiler constants or aliases, being able to set certain constants that the compiler replaces during compile, avoids cluttering the m. array and the associated runtime costs.
Single line version of for, for each, and while, much like the if variant in BRS, just a personal preference I'd like to see.
An internal 'null' check that handles both "<unitialized>" and invalid. String checking is inefficient anyway, and any internal routine would be much better than the 'return Type(Item)<>"<uninitialized>" and Item<>Invalid' I use and have repeatedly seen in others code.
Dev mode compiler blocks that don't compiie when not in the dev sandbox, avoids runtime checks, even though they admittedly have no real run-time cost.
The ability to preset an array size on associative arrays to avoid progressively resizing for large arrays, like we can on basic arrays. I don't actually know how these are internally implemented, so this might be a meaningless request.
If I was reaching for the unreasonable I'd add...
Multithreading, which I simulate now with a getmessage wrapper method that loops an array of micro-granular state machines to allow background processes, I know this would be a massive restructuring.
Linq, which every c# programmer here knows and I assume appreciates, but that would be rather excessive and in some cases impractical.