On Tue, Dec 23, 2008 at 6:08 PM, KennyTM~ <[email protected]> wrote: > Bill Baxter wrote: >> >> On Mon, Dec 22, 2008 at 11:43 PM, Jarrett Billingsley >> <[email protected]> wrote: >>> >>> On Mon, Dec 22, 2008 at 8:59 AM, bearophile <[email protected]> >>> wrote: >>>> >>>> Jarrett Billingsley: >>>>> >>>>> I suppose you mean for normal arrays. How about reverse as well? >>>> >>>> I'd like to see better and faster "reverse" and "sort", but I think they >>>> are useful. Why do you want to see them removed? I think built-in types may >>>> enjoy more methods, not less. >>> >>> So they can be replaced with library methods. The built-in sort >>> doesn't even allow you to sort on a predicate. Even if we extend the >>> built-in sort to support this, it'll never be as flexible as some >>> people want it. If a sort function can perform just as well or better >>> than the built-in sort while being more flexible, what's the point of >>> having the built-in sort? >> >> One good thing about the built-in .sort and .reverse functions is that >> you can be sure they'll work as CTFE. >> A library sort function isn't so likely to. >> >> --bb > > What prevents a sort() function from a standard library with default > parameters from being CTFE-ed? > > A .sort property built into the language is convenient, but not necessary I > think.
I just doubt that the current CTFE engine is capable of running typical sort routines meant for run-time use, that's all. If it could I agree that even that advantage to built-in sort goes away. --bb
