Nick Sabalausky wrote:
> "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.
>

If I decided to develop my own custom micro-controller as well, only mine uses base [put random number here] or what ever other valid reason I have for working with numbers in some base, should I ask for that base to be added to the language as well?
A more general solution is to allow arbitrary base representations. don suggested toBase!(base)(number) or something similar. adding syntax sugar for that is better IMO than just adding base 4.
here's a first attempt:
<number>B<base>. so 01010101B2 is a binary number. compiler will check that the digits are in the proper range, so 123B2 is a compile-time error.To represent the digits we can use English letters as in Hex or have another syntax form like 123#112#323#334B1000



>> * 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.
>
>

bearophile wrote:
> 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.

Exactly. I just think it's ridiculous that octal has a privileged syntax:
int a = 06;
int b = 09;
either both lines should compile, or neither.
I like the 0c635 syntax.

>>> * 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).

That would be useful, but it's not the comma operator.
> 
> Bye,
> bearophile

"Don" <nospam@nospam.com> wrote in message news:git0p7$2tah$1@digitalmars.com...
> bearophile wrote:
>> 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.
>
> Exactly. I just think it's ridiculous that octal has a privileged syntax:
> int a = 06;
> int b = 09;
> either both lines should compile, or neither.
> I like the 0c635 syntax.
>

Geez! I had no idea prepending a zero made it octal. That's terrible.

"bearophile" <bearophileHUGS@lycos.com> wrote in message news:gis9up$n5m$1@digitalmars.com...
> 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
>

I see. I had assumed the comma operator was only valid in the "init" and "increment" sections of a for loop. Didn't know it was usable outside of that. In that case, I'd have to mostly agree. But I would hate to lose the ability to write a for loop such as the one you wrote above.

Don wrote:
> bearophile wrote:
>> 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.
>
> Exactly. I just think it's ridiculous that octal has a privileged syntax:
> int a = 06;
> int b = 09;
> either both lines should compile, or neither.
> I like the 0c635 syntax.
>
>>>> * 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).
>
> That would be useful, but it's not the comma operator.
>>
>> Bye,
>> bearophile

why not replace the current comma operator with tuple support?
the comma op needs to be higher than assingment in precedence and instead of evaluating the expressions left to right and returning the value of the _last_ expression as the return value of the op, return _all_ expressions' return values as a value tuple. the current behavior that is really used only in for loops can be implemented with tuples as well.

insted of:
for (int i = 0, long j = 0; ...; ...) {...}

we'll use something like:
for (Tuple!(int, long) (a, b) = (0, 0); ...; ...) {...}

-- Yigal

On Wed, Dec 24, 2008 at 5:24 PM, Yigal Chripun <yigal100@gmail.com> wrote:
> why not replace the current comma operator with tuple support?
> the comma op needs to be higher than assingment in precedence and instead of
> evaluating the expressions left to right and returning the value of the
> _last_ expression as the return value of the op, return _all_ expressions'
> return values as a value tuple. the current behavior that is really used
> only in for loops can be implemented with tuples as well.
>
> insted of:
> for (int i = 0, long j = 0; ...; ...) {...}

Actually that's not legal syntax.  You're thinking of "int i = 0, j = 0", which is parsed as a single declaration statement which declares two variables.  This does not use the comma operator.

The place where the comma operator is used is in the increment:

for(..; ..; i++, j++)

All that has to be done here is the comma has to be added to the increment grammar of the for loop.  (MiniD does this.)

Jarrett Billingsley wrote:
> On Wed, Dec 24, 2008 at 5:24 PM, Yigal Chripun<yigal100@gmail.com>  wrote:
>> why not replace the current comma operator with tuple support?
>> the comma op needs to be higher than assingment in precedence and instead of
>> evaluating the expressions left to right and returning the value of the
>> _last_ expression as the return value of the op, return _all_ expressions'
>> return values as a value tuple. the current behavior that is really used
>> only in for loops can be implemented with tuples as well.
>>
>> insted of:
>> for (int i = 0, long j = 0; ...; ...) {...}
>
> Actually that's not legal syntax.  You're thinking of "int i = 0, j =
> 0", which is parsed as a single declaration statement which declares
> two variables.  This does not use the comma operator.
>
> The place where the comma operator is used is in the increment:
>
> for(..; ..; i++, j++)
>
> All that has to be done here is the comma has to be added to the
> increment grammar of the for loop.  (MiniD does this.)

and what if I do instead:
int i; long j;
for (i = 0, j = 0; ...; ++i, ++j) {...}
that should be legal, right? I don't use this feature that often....

I was trying to suggest a more general solution rather than adding a special case for "for" loops. IMO, with proper tuple support you do not need special cases. i.e.:
(++i, ++j) is a regular tuple that given i = 2 and j = 5 will evaluate to (3, 6) which can be assinged to the loop variable:

for (Tuple!(int, long) (a, b) = (0, 1); cond; (++a, ++b)) {...}

Jarrett Billingsley wrote:
> On Wed, Dec 24, 2008 at 5:24 PM, Yigal Chripun <yigal100@gmail.com> wrote:
>> why not replace the current comma operator with tuple support?
>> the comma op needs to be higher than assingment in precedence and instead of
>> evaluating the expressions left to right and returning the value of the
>> _last_ expression as the return value of the op, return _all_ expressions'
>> return values as a value tuple. the current behavior that is really used
>> only in for loops can be implemented with tuples as well.
>>
>> insted of:
>> for (int i = 0, long j = 0; ...; ...) {...}
> 
> Actually that's not legal syntax.  You're thinking of "int i = 0, j =
> 0", which is parsed as a single declaration statement which declares
> two variables.  This does not use the comma operator.
> 
> The place where the comma operator is used is in the increment:
> 
> for(..; ..; i++, j++)
> 
> All that has to be done here is the comma has to be added to the
> increment grammar of the for loop.  (MiniD does this.)

Actually, that isn't even needed. Since the return value of the increment is never used, and it can be any type at all, there would be no reason to change that line of code at all.
So the increment clause is suddenly a tuple? Who cares; it still increments just fine, doesn't it? :)

The only potential problem (which I just now thought of) would be increments with type void (e.g. ++i, iter.step()). Do tuple values allow void elements? If not, would it do any harm to allow them?

On Thu, 25 Dec 2008 15:09:59 +0100, Frits van Bommel <fvbommel@REMwOVExCAPSs.nl> wrote:

>Jarrett Billingsley wrote:
>> On Wed, Dec 24, 2008 at 5:24 PM, Yigal Chripun <yigal100@gmail.com> wrote:
>>> why not replace the current comma operator with tuple support?
>>> the comma op needs to be higher than assingment in precedence and instead of
>>> evaluating the expressions left to right and returning the value of the
>>> _last_ expression as the return value of the op, return _all_ expressions'
>>> return values as a value tuple. the current behavior that is really used
>>> only in for loops can be implemented with tuples as well.
>>>
>>> insted of:
>>> for (int i = 0, long j = 0; ...; ...) {...}
>> 
>> Actually that's not legal syntax.  You're thinking of "int i = 0, j = 0", which is parsed as a single declaration statement which declares two variables.  This does not use the comma operator.
>> 
>> The place where the comma operator is used is in the increment:
>> 
>> for(..; ..; i++, j++)
>> 
>> All that has to be done here is the comma has to be added to the increment grammar of the for loop.  (MiniD does this.)
>
>Actually, that isn't even needed. Since the return value of the
>increment is never used, and it can be any type at all, there would be
>no reason to change that line of code at all.
>So the increment clause is suddenly a tuple? Who cares; it still
>increments just fine, doesn't it? :)
>
>The only potential problem (which I just now thought of) would be increments with type void (e.g. ++i, iter.step()). Do tuple values allow void elements? If not, would it do any harm to allow them?

I wish void values would be legal. One more inconsistency hindering generic programming would probably go from the type system. Now almost any place when void is used as a type needs to be special-cased. For example, I don't see why the following should be illegal:

T foo(T = void)()
{
    return T.init;
}

foo(); // error

On Mon, 22 Dec 2008 21:45:06 +0300, "Denis Koroskin" <2korden@gmail.com> wrote:

>> 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).

There hasn't been a response from Walter to those discussions. Is it safe to assume __traits is not going to change soon?