December 22, 2008
On Mon, 22 Dec 2008 10:55:27 -0600, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

>Also, is() is a built-in thing so traits can't do all it does.
Probably, he meant __traits. Another thing to remove is the underscores. Keywords are highlighted in all editors with D support, so there is no need to make __traits "stand out" like that. std.traits could be renamed to something like "std.reflection"
December 22, 2008
On Mon, 22 Dec 2008 21:30:20 +0300, Max Samukha <samukha@voliacable.com.removethis> wrote:

> On Mon, 22 Dec 2008 10:55:27 -0600, Andrei Alexandrescu
> <SeeWebsiteForEmail@erdani.org> wrote:
>
>> Also, is() is a built-in thing so traits can't do all it does.
> Probably, he meant __traits. Another thing to remove is the
> underscores. Keywords are highlighted in all editors with D support,
> so there is no need to make __traits "stand out" like that. std.traits
> could be renamed to something like "std.reflection"

I treat the whole __traits feature as a hack. There are better alternatives (discussed many times) with same functionality and better syntax (Foo.traits.isAbstractClass, writefln.traits.isVirtualFunction etc to name one).
December 22, 2008
On Mon, Dec 22, 2008 at 11:43 PM, Jarrett Billingsley <jarrett.billingsley@gmail.com> wrote:
> On Mon, Dec 22, 2008 at 8:59 AM, bearophile <bearophileHUGS@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
December 22, 2008
"Jarrett Billingsley" <jarrett.billingsley@gmail.com> wrote in message news:mailman.245.1229956988.22690.digitalmars-d@puremagic.com...
<snip>
>> 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.

How does having built-in sort prevent anybody from implementing sort in a library?

> 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?

I'm sure Walter can come up with a rationale for having sort built in.

But I still doubt there's any reason for keeping it as limited as it is.

Stewart.

-- 
My e-mail address is valid but not my primary mailbox.  Please keep replies on the 'group where everybody may benefit. 

December 22, 2008
Stewart Gordon:
> How does having built-in sort prevent anybody from implementing sort in a library?

The funny thing is they can be syntax-compatible too: in my libs there are sorted() and sort() (the first creates a new array and the second works in-place), they can be used like this:

string[] a2 = ["Liu", "Verylongword", "word", "average"];
a2.sort(&len!(string));

Result:
a2 == ["Liu", "word", "average", "Verylongword"]

Where len() is a refined function template that returns length of lazy/eager iterables, using the .length attribute where possible.

So a2.sort and a2.sort(...)/a2.sorted(...) don't clash.

Bye,
bearophile
December 22, 2008
On Mon, Dec 22, 2008 at 5:54 PM, Stewart Gordon <smjg_1998@yahoo.com> wrote:
> How does having built-in sort prevent anybody from implementing sort in a library?

It doesn't.  But as I said:

>> 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?
December 23, 2008
Bill Baxter wrote:
> On Mon, Dec 22, 2008 at 11:43 PM, Jarrett Billingsley
> <jarrett.billingsley@gmail.com> wrote:
>> On Mon, Dec 22, 2008 at 8:59 AM, bearophile <bearophileHUGS@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.
December 23, 2008
On Tue, Dec 23, 2008 at 6:08 PM, KennyTM~ <kennytm@gmail.com> wrote:
> Bill Baxter wrote:
>>
>> On Mon, Dec 22, 2008 at 11:43 PM, Jarrett Billingsley <jarrett.billingsley@gmail.com> wrote:
>>>
>>> On Mon, Dec 22, 2008 at 8:59 AM, bearophile <bearophileHUGS@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
December 24, 2008
"Don" <nospam@nospam.com> wrote in message news:gio27n$2o0f$1@digitalmars.com...
> bearophile wrote:
>> There are some things I'd like to see added to the D language, but what things can be removed from it?
>>
>
> * C-style declarations

I certainly wouldn't mind seeing these go. But then, I haven't tried to port much C/C++ code to D.

> * \n, \r as a string (free up the backslash character)
> * #line (make it a pragma instead)

Agreed.

> * Octal (it's not 1952 any more)

Disagree. Octal can often useful on low-level embedded stuff. Heck, I've worked on a recent microcontroller where even base-4 was extremely handy. If anything, I'd recommend adding base-4 to D, and certainly not removing octal.

> * the comma operator (allow in selected places, eg for(; ;++a, ++b)).
> * Object.toString(). Encourages bad design. It's not powerful enough to be
> useful.

What is the problem with these?

> * The postincrement and postdecrement operators (make x++, x-- identical to ++x, --x, except that it is illegal to use the return value. Allowing operator overloading of the postfix operators was a silly hack in C++. It's a freedom nobody wants).

I'm certainly not a fan of post??crement. They lead to confusing code/results. Plus, I don't know if this is still relevent, but back when I was using C++, doing "foo++;" instead of "++foo;" on a non-primitive was considered bad because (IIRC) it created a useless temp copy (or something like that). Granted, I'd much rather type "x++" than "++x", but the behavior of post??crement is something I could certainly do without.


December 24, 2008
Nick Sabalausky:
> Disagree. Octal can often useful on low-level embedded stuff.

I think the point was to improve the syntax of octal numbers, not to remove them. So 0125 becomes a syntax error (as usual to keep compatibility with C, otherwise it's better to make it just mean 125), and invent a less error-prone syntax for octal numbers. For example 0oxxxx.


> > * the comma operator (allow in selected places, eg for(; ;++a, ++b)).
> What is the problem with these?

Generally the comma operator is useful only in particular situations, and in other situations it may lead to errors.

This is an acceptable use (but this too may lead to some errors):
for( i = 0, j = MAX; i <= j; ++i, --j )

This shows some of the stupid uses of the comma operator: http://stackoverflow.com/questions/54142/c-comma-operator

A way to use the comma operator is to allow multiple simultaneous assignments:
x, y = y, x
a, b, c = c, b, a
Etc.
(The compiler can minimize the operations and intermediate memory required to do that).

Bye,
bearophile