Jonathan M Davis: > but is the overhead of creating a tuple to do that > warranted in a systems programming language?
This is an interesting point. My experience shows that while you write code there are situations where you care for performance, even a lot. In such situations a system language must give you ways to get the performance you need. But there are many other situations where you know performance is not the most important thing, because it's in a less critical path, because you know you will sort only few items once in a while, or because you are writing a 20 lines long script-line program. In such situations you want to write less code (because less code often means less testing, less bugs, less code to read and modify), you want higher level code (because this makes the program simpler to understand and to think about). Such situations are common, and in my opinion in them a good language has to give you higher level ways to do what you need to do. This is multi-level programming. A max function that takes an unary key function that returns a 2-tuple built on the fly is probably not the most efficient code. But it's very short (especially if your language gives a succint syntax for tuples and lambdas), it's not bug-prone and it's quite handy and easy to to understand and to think about. So I'd like it in Phobos. A system language has to give you ways to be efficient, and probably it also has to offer ways to show and put in evidence where you are not doing things efficiently (like a compiler switch that lists all heap allocations of a module, or all its heap closures), but I don't want it to force me to write low-level code where I don't want to do it. There are plenty of situations where writing low-level code is not the best thing to do. Bye, bearophile
