View mode: basic / threaded / horizontal-split · Log in · Help
December 24, 2008
Re: Things that may be removed
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.
>
>
December 24, 2008
Re: Things that may be removed
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
December 24, 2008
Re: Things that may be removed
"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.
December 24, 2008
Re: Things that may be removed
"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.
December 24, 2008
Re: Things that may be removed
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
December 24, 2008
Re: Things that may be removed
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.)
December 24, 2008
Re: Things that may be removed
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)) {...}
December 25, 2008
Re: Things that may be removed
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?
December 25, 2008
Re: Things that may be removed
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
December 27, 2008
Re: Things that may be removed
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?
Next ›   Last »
1 2 3 4 5
Top | Discussion index | About this forum | D home