Things that may be removed

[Bill Baxter]

On Tue, Dec 23, 2008 at 6:08 PM, KennyTM~ <kennytm at gmail.com> wrote:
> Bill Baxter wrote:
>>
>> On Mon, Dec 22, 2008 at 11:43 PM, Jarrett Billingsley
>> <jarrett.billingsley at gmail.com> wrote:
>>>
>>> On Mon, Dec 22, 2008 at 8:59 AM, bearophile <bearophileHUGS at lycos.com>
>>> 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