www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Things that may be removed

reply bearophile <bearophileHUGS lycos.com> writes:
There are some things I'd like to see added to the D language, but what things
can be removed from it?

"Perfection is attained, not when no more can be added, but when no more can be
removed."
-- Antoine de Saint-Exupéry.
:-)

"There should be one-- and preferably only one --*obvious* way to do it."
-- Python Zen, emphasis added by me :-)

Bye,
bearophile
Dec 17 2008
next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
bearophile wrote:

 There are some things I'd like to see added to the D language, but what things
can be removed from it?
 
 "Perfection is attained, not when no more can be added, but when no more can
be removed."
 -- Antoine de Saint-Exupéry.
 :-)
 
 "There should be one-- and preferably only one --*obvious* way to do it."
 -- Python Zen, emphasis added by me :-)
 
 Bye,
 bearophile


Why, of course, the C syntax for types:

int (*x[5])[3];
int (*x)(char);
int (*[] x)(char);

*Ugh*...
Dec 17 2008
next sibling parent reply Gide Nwawudu <gide btinternet.com> writes:
On Wed, 17 Dec 2008 10:57:02 -0200, Ary Borenszweig
<ary esperanto.org.ar> wrote:


bearophile wrote:

 There are some things I'd like to see added to the D language, but what things
can be removed from it?
 
 "Perfection is attained, not when no more can be added, but when no more can
be removed."
 -- Antoine de Saint-Exupéry.
 :-)
 
 "There should be one-- and preferably only one --*obvious* way to do it."
 -- Python Zen, emphasis added by me :-)
 
 Bye,
 bearophile


Why, of course, the C syntax for types:

int (*x[5])[3];
int (*x)(char);
int (*[] x)(char);

*Ugh*...


Totally agree, learning two ways of doing things is just more effort,
but then again I didn't like C's style of declarations in the first
place. Learning Pascal before C maybe toughen me up, I haven't
suffered RSI typing ARRAY OF :)

http://mindprod.com/jgloss/unmainobfuscation.html
[snip]
29. Exploit Schizophrenia: Java is schizophrenic about array
declarations. You can do them the old C, way String x[], (which uses
mixed pre-postfix notation) or the new way String[] x, which uses pure
prefix notation. If you want to really confuse people, mix the
notations: e.g. 
byte[] rowvector, colvector, matrix[];
which is equivalent to: 
byte[] rowvector;
byte[] colvector;
byte[][] matrix;


At least D doesn't allow the mixture of pre/postfix notations in a
declaration.

Gide
Dec 17 2008
parent reply bearophile <bearophileHUGS lycos.com> writes:
Gide Nwawudu:

 Learning Pascal before C maybe toughen me up, I haven't
 suffered RSI typing ARRAY OF :)


But Pascal arrays have other qualities, an example:

type 
  TyArr = Array ['e' .. 'x'] of Integer;
var
  a1: TyArr;
begin
  a1['f'] := 10;
...

That array has that range of chars as indexes, and if you want the compiler at
run time will control that only that range of chars is used. In D you can do
that as (probably typedef is much less common in D code than the types section
in Pascal programs):

typedef int['x' - 'e'] TyArr;
TyArr a1;
int main() {
    a1['f' - 'e'] = 10;
...

But maybe such things aren't common enough to deserve a special support.

Bye,
bearophile
Dec 17 2008
parent reply "Nick Sabalausky" <a a.a> writes:
"bearophile" <bearophileHUGS lycos.com> wrote in message 
news:gib2kj$2bib$1 digitalmars.com...

 Gide Nwawudu:

 Learning Pascal before C maybe toughen me up, I haven't
 suffered RSI typing ARRAY OF :)


 But Pascal arrays have other qualities, an example:

 type
  TyArr = Array ['e' .. 'x'] of Integer;
 var
  a1: TyArr;
 begin
  a1['f'] := 10;
 ...

 That array has that range of chars as indexes, and if you want the 
 compiler at run time will control that only that range of chars is used. 
 In D you can do that as (probably typedef is much less common in D code 
 than the types section in Pascal programs):

 typedef int['x' - 'e'] TyArr;
 TyArr a1;
 int main() {
    a1['f' - 'e'] = 10;
 ...

 But maybe such things aren't common enough to deserve a special support.

 Bye,
 bearophile


VB6 (and maybe VBScript) allows the lower bound of an array to be any 
interger less than whatever the upper bound is. Personally, I've never liked 
that. The mere possibility for that forces all code that uses arrays to use 
the ugly "UBound(array) - LBound(array)" to get length (unless you want to 
write and use a non-standard array length function) and start all iterations 
at "LBound(array)" instead of 0. Then again, since D has ".length" and 
"foreach", those might not be problems for D.

I think Andrei has previously suggested the idea of dropping the keyword 
"new" from class instantiations / heap allocations. I wouldn't like that. 
The "new" makes class instantiations / heap allocations easily greppable. I 
don't think I would want to give that up.

Also, as far as the quoted in the original post (such as "Perfection is 
attained, not when no more can be added, but when no more can be removed."). 
I normally agree with such sentiment, but I don't consider it to bve 
particularly applicable to language design. I see a progamming langauge as 
being not a tool, but a toolbox. You wouldn't design a real 
carpentry/construction/etc. toolbox with a "Perfection is attained, not when 
no more can be added, but when no more can be removed." philosophy, would 
you? If you did, it would end up containing nothing but a hammer and a note 
saying "If all you have is a hammer, everything looks like a nail". If you 
did it with language design, you'd ultimately end up with brainfuck.
Dec 17 2008
parent reply "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Wed, 17 Dec 2008 23:45:55 +0100, Nick Sabalausky <a a.a> wrote:


 I think Andrei has previously suggested the idea of dropping the keyword
 "new" from class instantiations / heap allocations. I wouldn't like that.
 The "new" makes class instantiations / heap allocations easily  
 greppable. I
 don't think I would want to give that up.


IIRC, the idea was to replace it with a member function, i.e. foo.new();

-- 
Simen
Dec 17 2008
parent "Nick Sabalausky" <a a.a> writes:
"Simen Kjaeraas" <simen.kjaras gmail.com> wrote in message 
news:op.umbxr0n41hx7vj biotronic.osir.hihm.no...

 On Wed, 17 Dec 2008 23:45:55 +0100, Nick Sabalausky <a a.a> wrote:


 I think Andrei has previously suggested the idea of dropping the keyword
 "new" from class instantiations / heap allocations. I wouldn't like that.
 The "new" makes class instantiations / heap allocations easily 
 greppable. I
 don't think I would want to give that up.


 IIRC, the idea was to replace it with a member function, i.e. foo.new();


I was under the impression it was about changing this:

class Foo {}
auto f = new Foo();

To this:

class Foo {}
auto f = Foo();

Maybe I was mistaken though.
Dec 17 2008
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Ary Borenszweig:

 Why, of course, the C syntax for types:
 int (*x[5])[3];
 int (*x)(char);
 int (*[] x)(char);
 *Ugh*...


Try porting code that uses heavily n-dimensional tensors from C to D, and you
understand why supporting the C syntax for arrays (with inverted coordinates in
the definition) is a godsend :-)

Bye,
bearophile
Dec 17 2008
next sibling parent reply Christian Kamm <kamm-incasoftware removethis.de> writes:
 Ary Borenszweig:

 Why, of course, the C syntax for types:
 int (*x[5])[3];
 int (*x)(char);
 int (*[] x)(char);
 *Ugh*...




bearophile wrote:

 Try porting code that uses heavily n-dimensional tensors from C to D, and
 you understand why supporting the C syntax for arrays (with inverted
 coordinates in the definition) is a godsend :-)


Maybe we could enable them conditionally?

pragma(parser, enable_cstyle_func_and_array_decls);
{
    int (*x[5])[3];
}
Dec 17 2008
next sibling parent reply cemiller <chris dprogramming.com> writes:
On Wed, 17 Dec 2008 23:04:43 -0800, Christian Kamm  
<kamm-incasoftware removethis.de> wrote:


 Ary Borenszweig:

 Why, of course, the C syntax for types:
 int (*x[5])[3];
 int (*x)(char);
 int (*[] x)(char);
 *Ugh*...




 bearophile wrote:

 Try porting code that uses heavily n-dimensional tensors from C to D,  
 and
 you understand why supporting the C syntax for arrays (with inverted
 coordinates in the definition) is a godsend :-)


 Maybe we could enable them conditionally?

 pragma(parser, enable_cstyle_func_and_array_decls);
 {
     int (*x[5])[3];
 }


They are conditional: you choose to write them or not <g>
Dec 19 2008
parent BCS <ao pathlink.com> writes:
Reply to cemiller,


 On Wed, 17 Dec 2008 23:04:43 -0800, Christian Kamm


 pragma(parser, enable_cstyle_func_and_array_decls);
 {
 int (*x[5])[3];
 }


 They are conditional: you choose to write them or not <g>
 


I want DMD (and grep) to help me chose to not let my minions make me READ them
Dec 19 2008
prev sibling parent reply "Stewart Gordon" <smjg_1998 yahoo.com> writes:
"Christian Kamm" <kamm-incasoftware removethis.de> wrote in message 
news:gicsm9$2qiv$1 digitalmars.com...
<snip>

 Maybe we could enable them conditionally?

 pragma(parser, enable_cstyle_func_and_array_decls);
 {
    int (*x[5])[3];
 }


What would this do?  Enable C-style declarations for the whole source file? 
From this point forward?  Within the active scope?  If it's meant to apply 
to the content of the given {}, then there should be a semicolon there.

Either way, it wouldn't work.  The whole point of pragmas is for features 
that a given compiler may or may not support.  And if a given compiler 
doesn't support this syntax, it will fail regardless.

Stewart.

-- 
My e-mail address is valid but not my primary mailbox.  Please keep replies 
on the 'group where everybody may benefit.
Dec 20 2008
parent reply Christian Kamm <kamm-incasoftware removethis.de> writes:
Christian Kamm:

 Maybe we could enable them conditionally?

 pragma(parser, enable_cstyle_func_and_array_decls);
 {
    int (*x[5])[3];
 }




Stewart Gordon wrote:

 What would this do?  Enable C-style declarations for the whole source
 file?
 From this point forward?  Within the active scope?  If it's meant to apply
 to the content of the given {}, then there should be a semicolon there.


I assume you mean 'should not be'. That's true, but I didn't want to alter
the grammar of the pragma statement to allow for it. 

Since there's no dedicated mechanism for compiler control, there aren't many
options. I guess a version(CStyle_decls) with the side effect of enabling
the parsing of C style declarations inside its block could work too. But
it's not pretty either.


 Either way, it wouldn't work.  The whole point of pragmas is for features
 that a given compiler may or may not support.  And if a given compiler
 doesn't support this syntax, it will fail regardless.


Well, there are a few predefined pragmas, like msg and lib. This could also
be a required, predefined one. 

But don't get hung up on the syntax. My main point was that most D modules
will not use the C style declarations. They may be useful when porting
legacy code though, so being able to enable them on a per file or per block
basis seemed like a reasonable compromise if getting rid of them completely
is not an option.
Dec 21 2008
parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Christian Kamm wrote:

 Christian Kamm:

 Maybe we could enable them conditionally?

 pragma(parser, enable_cstyle_func_and_array_decls);
 {
    int (*x[5])[3];
 }




 
 Stewart Gordon wrote:

 What would this do?  Enable C-style declarations for the whole source
 file?
 From this point forward?  Within the active scope?  If it's meant to apply
 to the content of the given {}, then there should be a semicolon there.


 
 I assume you mean 'should not be'. That's true, but I didn't want to alter
 the grammar of the pragma statement to allow for it. 


How do you mean, alter the grammar? Pragmas allow
-----
pragma(ident)		   // influence block of declarations
{   declaration;
     declaration;
}
-----
with this type of semantic (see 
http://www.digitalmars.com/d/1.0/pragma.html).


 Since there's no dedicated mechanism for compiler control, there aren't many
 options. I guess a version(CStyle_decls) with the side effect of enabling
 the parsing of C style declarations inside its block could work too. But
 it's not pretty either.


That's an ugly hack. Don't use a version to do a pragma's job.



Anyway, my vote is for eliminating C-style declarations altogether.
Dec 21 2008
parent reply Christian Kamm <kamm-incasoftware removethis.de> writes:
Frits van Bommel wrote:

 How do you mean, alter the grammar? Pragmas allow
 -----
 pragma(ident)            // influence block of declarations
 {   declaration;
      declaration;
 }
 -----
 with this type of semantic (see
 http://www.digitalmars.com/d/1.0/pragma.html).


Ah, I didn't realize that was legal. Thanks for pointing it out!
Dec 21 2008
parent "Stewart Gordon" <smjg_1998 yahoo.com> writes:
"Christian Kamm" <kamm-incasoftware removethis.de> wrote in message 
news:gilm7t$1h2j$1 digitalmars.com...

 Frits van Bommel wrote:

 How do you mean, alter the grammar? Pragmas allow




<snip>

 Ah, I didn't realize that was legal. Thanks for pointing it out!


Furthermore, you'd have to alter the grammar anyway in order to support this 
feature, by adding

PragmaStatement:
    pragma ( parser , enable_cstyle_func_and_array_decls ) 
NoScopeStatementThatMayContainCStyleDecls

among other things.

Stewart.

-- 
My e-mail address is valid but not my primary mailbox.  Please keep replies 
on the 'group where everybody may benefit.
Dec 21 2008
prev sibling next sibling parent Ary Borenszweig <ary esperanto.org.ar> writes:
bearophile wrote:

 Ary Borenszweig:

 Why, of course, the C syntax for types:
 int (*x[5])[3];
 int (*x)(char);
 int (*[] x)(char);
 *Ugh*...


 
 Try porting code that uses heavily n-dimensional tensors from C to D, and you
understand why supporting the C syntax for arrays (with inverted coordinates in
the definition) is a godsend :-)


That's a good point. But can't you do:

extern(C) {
    ...
}

for that? Well, some signatures might leek in the interface, but if they 
are hard to understand (I could learn them, but if there's a simpler 
notation, what for?) than it'll be harder to use for D users, and 
they'll feel they are programming in a mix of C and D, not in D.


 
 Bye,
 bearophile
Dec 18 2008
prev sibling parent "Stewart Gordon" <smjg_1998 yahoo.com> writes:
"bearophile" <bearophileHUGS lycos.com> wrote in message 
news:gici0r$2d56$1 digitalmars.com...

 Ary Borenszweig:

 Why, of course, the C syntax for types:
 int (*x[5])[3];
 int (*x)(char);
 int (*[] x)(char);
 *Ugh*...


 Try porting code that uses heavily n-dimensional tensors from C to
 D, and you understand why supporting the C syntax for arrays (with
 inverted coordinates in the definition) is a godsend :-)


That sounds like a case of wanting to use D for legacy apps.  I'm not sure 
that we really need C syntax for that, especially considering that legacy 
apps are one thing in the "Who D is Not For" list.

This syntax ought to be at least deprecated soon, and eventually removed.

Somebody recently exposed an ambiguity in D's syntax due to this legacy: is

    Identifier ( * Identifier ) ( Identifier ) ;

a declaration of a function pointer or a call to a function returned by a 
function?

Stewart.

-- 
My e-mail address is valid but not my primary mailbox.  Please keep replies 
on the 'group where everybody may benefit.
Dec 20 2008
prev sibling next sibling parent reply Jason House <jason.james.house gmail.com> writes:
SFINAE

Accidental use of SFINAE  is confusing.

Code using SFINAE is tough or impossible to follow.

Use of SFINAE can lead to longer compile times.

Removing SFINAE will expose shortfalls in D's metaprogramming facilities.

Combining all of these faults into a templated library and you have C++'s STL
or Boost all over again. They're amazingly useful in C++, but D can do far
better!

bearophile Wrote:


 There are some things I'd like to see added to the D language, but what things
can be removed from it?
 
 "Perfection is attained, not when no more can be added, but when no more can
be removed."
 -- Antoine de Saint-Exupéry.
 :-)
 
 "There should be one-- and preferably only one --*obvious* way to do it."
 -- Python Zen, emphasis added by me :-)
 
 Bye,
 bearophile
Dec 17 2008
parent "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
On Wed, Dec 17, 2008 at 7:14 PM, Jason House
<jason.james.house gmail.com> wrote:

 SFINAE

 Accidental use of SFINAE  is confusing.

 Code using SFINAE is tough or impossible to follow.

 Use of SFINAE can lead to longer compile times.

 Removing SFINAE will expose shortfalls in D's metaprogramming facilities.

 Combining all of these faults into a templated library and you have C++'s STL
or Boost all over again. They're amazingly useful in C++, but D can do far
better!


There's one more - SFINAE has become all but unnecessary in D, at
least in D2.  static if and template constraints (the if() after the
template header) seem to be much more general (and easier to follow)
than SFINAE.
Dec 17 2008
prev sibling next sibling parent reply sandeepk <a b.com> writes:
bearophile Wrote:


 Ary Borenszweig:

 Why, of course, the C syntax for types:
 int (*x[5])[3];
 int (*x)(char);
 int (*[] x)(char);
 *Ugh*...


 
 Try porting code that uses heavily n-dimensional tensors from C to D, and you
understand why supporting the C syntax for arrays (with inverted coordinates in
the definition) is a godsend :-)
 
 Bye,
 bearophile


I think the right solution for this is to include a tool that rewrites them
into D style.
Dec 17 2008
parent reply BCS <ao pathlink.com> writes:
Reply to sandeepk,


 bearophile Wrote:
 

 Try porting code that uses heavily n-dimensional tensors from C to D,
 and you understand why supporting the C syntax for arrays (with
 inverted coordinates in the definition) is a godsend :-)
 


 I think the right solution for this is to include a tool that rewrites
 them into D style.
 


vote ++;
Dec 18 2008
parent reply KennyTM~ <kennytm gmail.com> writes:
BCS wrote:

 Reply to sandeepk,
 

 bearophile Wrote:


 Try porting code that uses heavily n-dimensional tensors from C to D,
 and you understand why supporting the C syntax for arrays (with
 inverted coordinates in the definition) is a godsend :-)


 I think the right solution for this is to include a tool that rewrites
 them into D style.


 
 vote ++;
 
 


http://www.digitalmars.com/d/2.0/htod.html ?
Dec 18 2008
parent BCS <ao pathlink.com> writes:
Reply to KennyTM~,


 BCS wrote:
 

 Reply to sandeepk,
 

 bearophile Wrote:
 

 Try porting code that uses heavily n-dimensional tensors from C to
 D, and you understand why supporting the C syntax for arrays (with
 inverted coordinates in the definition) is a godsend :-)
 


 I think the right solution for this is to include a tool that
 rewrites them into D style.
 


 vote ++;
 


 http://www.digitalmars.com/d/2.0/htod.html ?
 


not quite. That's for headers. What about code files?
Dec 19 2008
prev sibling next sibling parent reply Don <nospam nospam.com> writes:
bearophile wrote:

 There are some things I'd like to see added to the D language, but what things
can be removed from it?
 
 "Perfection is attained, not when no more can be added, but when no more can
be removed."
 -- Antoine de Saint-Exupéry.
 :-)
 
 "There should be one-- and preferably only one --*obvious* way to do it."
 -- Python Zen, emphasis added by me :-)
 
 Bye,
 bearophile


That is an excellent question.
Some items in my list are controversial, the first two have already been 
mentioned.

* C-style declarations
* SFINAE
* \n, \r as a string (free up the backslash character)
* #line (make it a pragma instead)
* Octal (it's not 1952 any more)
* the comma operator (allow in selected places, eg for(; ;++a, ++b)).
* package. In DMD, it's a broken implementation of a broken concept.
* 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).
* is() expressions (I love what you can do with it, but it's 
unintuitive, and traits is a much better solution)
* .sort for AAs.
* Object.toString(). Encourages bad design. It's not powerful enough to 
be useful.
Dec 22 2008
next sibling parent KennyTM~ <kennytm gmail.com> writes:
Don wrote:

 bearophile wrote:

 There are some things I'd like to see added to the D language, but 
 what things can be removed from it?

 "Perfection is attained, not when no more can be added, but when no 
 more can be removed."
 -- Antoine de Saint-Exupéry.
 :-)

 "There should be one-- and preferably only one --*obvious* way to do it."
 -- Python Zen, emphasis added by me :-)

 Bye,
 bearophile


 
 That is an excellent question.
 Some items in my list are controversial, the first two have already been 
 mentioned.
 
 * C-style declarations
 * SFINAE
 * \n, \r as a string (free up the backslash character)
 * #line (make it a pragma instead)
 * Octal (it's not 1952 any more)
 * the comma operator (allow in selected places, eg for(; ;++a, ++b)).
 * package. In DMD, it's a broken implementation of a broken concept.
 * 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).
 * is() expressions (I love what you can do with it, but it's 
 unintuitive, and traits is a much better solution)
 * .sort for AAs.
 * Object.toString(). Encourages bad design. It's not powerful enough to 
 be useful.


Just a comment:

Octal could be useful in chmod-ing, although saying 0321 != 321 is still 
confusing. I'd suggest keeping octal but change the way of declaring it 
(e.g. python's 0o321 or even toBase!(8, "321").)
Dec 22 2008
prev sibling next sibling parent reply "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
On Mon, Dec 22, 2008 at 7:46 AM, Don <nospam nospam.com> wrote:

 That is an excellent question.
 Some items in my list are controversial, the first two have already been
 mentioned.

 * C-style declarations
 * SFINAE
 * \n, \r as a string (free up the backslash character)
 * #line (make it a pragma instead)
 * Octal (it's not 1952 any more)
 * the comma operator (allow in selected places, eg for(; ;++a, ++b)).
 * package. In DMD, it's a broken implementation of a broken concept.
 * 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).
 * is() expressions (I love what you can do with it, but it's unintuitive,
 and traits is a much better solution)
 * .sort for AAs.


I suppose you mean for normal arrays.  How about reverse as well?


 * Object.toString(). Encourages bad design. It's not powerful enough to be
 useful.


I agree with absolutely everything you've listed here.
Dec 22 2008
parent reply bearophile <bearophileHUGS lycos.com> writes:
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.

Bye,
bearophile
Dec 22 2008
next sibling parent reply "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
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?
Dec 22 2008
parent reply "Stewart Gordon" <smjg_1998 yahoo.com> writes:
"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.
Dec 22 2008
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
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
Dec 22 2008
prev sibling parent "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
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?
Dec 22 2008
prev sibling parent reply "Bill Baxter" <wbaxter gmail.com> writes:
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
Dec 22 2008
parent reply KennyTM~ <kennytm gmail.com> writes:
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.
Dec 23 2008
parent "Bill Baxter" <wbaxter gmail.com> writes:
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
Dec 23 2008
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Don:

Thank you for your list, the first true good answer to this post of mine :-)


 * C-style declarations


I agree that having two ways to do the same thing is generally very bad. But I
have personally seen how much useful they are when translating C code to D, so
I think some intermediate solution may be better (a way to denote a single C
declaration? A way to switch them on only in a module like the module(safe)
syntax? With pragmas? I don't know).



 * \n, \r as a string (free up the backslash character)


Do you mean things like?
writefln("hello" \n);
I agree. I don't think they are much useful.



 * Octal (it's not 1952 any more)


More than a year ago I have offered solutions to this. In the meantime Python3
has implemented something similar. It helps avoid bugs.



 * the comma operator (allow in selected places, eg for(; ;++a, ++b)).


I agree. It's quite dangerous. In some places it's useful, so better to limit
how and where it can be used.



 * package. In DMD, it's a broken implementation of a broken concept.


I think the D module system needs a public brainstorming to fix it :-)



 * The postincrement and postdecrement operators (make x++, x-- identical 
 to ++x, --x, except that it is illegal to use the return value.


I am not sure this is exactly what I want, but I agree they are tricky and not
intuitive enough, and deserve some improvements in D.



Allowing 
 operator overloading of the postfix operators was a silly hack in C++. 
 It's a freedom nobody wants).


I don't understand much.



 * .sort for AAs.


AAs don't have a sort.
you can do:
aa.keys.sort or aa.values.sort, but I think this is useful (I'd just like the
ability to give a sorting "key" to such methods, but this is something more
than the current D, so it's off topic in this thread that is about the things
that may be removed).



 * Object.toString(). Encourages bad design. It's not powerful enough to 
 be useful.


Here I don't agree much with you. toString is mostly for debugging, for
developers, etc. So I think it's useful and good enough (I may want a way to
add a second default way to represent an object/struct, to allow a lower-level
representation, like __repr__ of Python, but it's not essential).

Your list is longer than the "lists" written by other people, but I think there
are some other redundant things that may be removed from the language. Your
list is nice and I mostly like it, but it's mostly about small things :-)

Among the small things, are all those quotation ways to like q{} good?
(Recently some people have said it's "dangerous" syntax, and I agree).

Another redundant syntax is to define a struct (statically):
auto x = Foo(20, 10)
Foo x = {20, 10};
Here I don't see the point of keeping the C syntax too.

There are several other things, mostly coming from C, that may be redundant. As
you may remember, part of this question of mine regarding the things that can
be removed was born from this point 11 here:
http://yosefk.com/c++fqa/defective.html#defect-11

Bye,
bearophile
Dec 22 2008
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Don wrote:

 bearophile wrote:

 There are some things I'd like to see added to the D language, but=20
 what things can be removed from it?

 "Perfection is attained, not when no more can be added, but when no=20
 more can be removed."
 -- Antoine de Saint-Exup=E9ry.
 :-)

 "There should be one-- and preferably only one --*obvious* way to do i=




t."

 -- Python Zen, emphasis added by me :-)

 Bye,
 bearophile


=20
 That is an excellent question.
 Some items in my list are controversial, the first two have already bee=


n=20

 mentioned.
=20
 * C-style declarations
 * SFINAE
 * \n, \r as a string (free up the backslash character)
 * #line (make it a pragma instead)
 * Octal (it's not 1952 any more)
 * the comma operator (allow in selected places, eg for(; ;++a, ++b)).
 * package. In DMD, it's a broken implementation of a broken concept.
 * The postincrement and postdecrement operators (make x++, x-- identica=


l=20

 to ++x, --x, except that it is illegal to use the return value. Allowin=


g=20

 operator overloading of the postfix operators was a silly hack in C++. =



 It's a freedom nobody wants).
 * is() expressions (I love what you can do with it, but it's=20
 unintuitive, and traits is a much better solution)
 * .sort for AAs.
 * Object.toString(). Encourages bad design. It's not powerful enough to=


=20

 be useful.


This looks like a pretty darn good list. Could you give detail on what's =

wrong with #line (lack of minimalism I suppose?) and how you'd replace=20
obj.toString? Also, is() is a built-in thing so traits can't do all it do=
es.


Andrei
Dec 22 2008
parent reply Max Samukha <samukha voliacable.com.removethis> writes:
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"
Dec 22 2008
parent reply "Denis Koroskin" <2korden gmail.com> writes:
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).
Dec 22 2008
parent Max Samukha <samukha voliacable.com.removethis> writes:
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?
Dec 27 2008
prev sibling next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Don (nospam nospam.com)'s article

 bearophile wrote:

 There are some things I'd like to see added to the D language, but what things




can be removed from it?

 "Perfection is attained, not when no more can be added, but when no more can




be removed."

 -- Antoine de Saint-Exupéry.
 :-)

 "There should be one-- and preferably only one --*obvious* way to do it."
 -- Python Zen, emphasis added by me :-)

 Bye,
 bearophile


 That is an excellent question.
 Some items in my list are controversial, the first two have already been
 mentioned.
 * C-style declarations
 * SFINAE
 * \n, \r as a string (free up the backslash character)
 * #line (make it a pragma instead)
 * Octal (it's not 1952 any more)
 * the comma operator (allow in selected places, eg for(; ;++a, ++b)).
 * package. In DMD, it's a broken implementation of a broken concept.
 * The postincrement and postdecrement operators (make x++, x-- identical
 to ++x, --x, except that it is illegal to use the return value.


Why?  This is a nice piece of syntactic sugar to make relatively simple code
more
concise.


 Allowing
 operator overloading of the postfix operators was a silly hack in C++.
 It's a freedom nobody wants).
 * is() expressions (I love what you can do with it, but it's
 unintuitive, and traits is a much better solution)


Agreed.  I love D's compile-time reflection but there are about 100 overlapping
ways to do it, and that's a bit excessive.


 * .sort for AAs.
 * Object.toString(). Encourages bad design. It's not powerful enough to
 be useful.


Please, no.  I love Object.toString().  Sometimes, both in finished products and
when printf-debugging, it's nice to just be able to get a basic string
representation of an object.  Can you please explain how it encourages bad
design?
Dec 22 2008
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
dsimcha wrote:

 == Quote from Don (nospam nospam.com)'s article

 * The postincrement and postdecrement operators (make x++, x-- identical
 to ++x, --x, except that it is illegal to use the return value.


 
 Why?  This is a nice piece of syntactic sugar to make relatively simple code
more
 concise.


I think he refers to defining them as distinct functions. He doesn't 
want to render either usage invalid.


Andrei
Dec 22 2008
prev sibling next sibling parent John Reimer <terminal.node gmail.com> writes:
Hello Don,


 bearophile wrote:
 

 There are some things I'd like to see added to the D language, but
 what things can be removed from it?
 
 "Perfection is attained, not when no more can be added, but when no
 more can be removed."
 -- Antoine de Saint-Exupéry.
 :-)
 "There should be one-- and preferably only one --*obvious* way to do
 it." -- Python Zen, emphasis added by me :-)
 
 Bye,
 bearophile


 That is an excellent question.
 Some items in my list are controversial, the first two have already
 been
 mentioned.
 * C-style declarations
 * SFINAE
 * \n, \r as a string (free up the backslash character)
 * #line (make it a pragma instead)
 * Octal (it's not 1952 any more)
 * the comma operator (allow in selected places, eg for(; ;++a, ++b)).
 * package. In DMD, it's a broken implementation of a broken concept.
 * 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).
 * is() expressions (I love what you can do with it, but it's
 unintuitive, and traits is a much better solution)
 * .sort for AAs.
 * Object.toString(). Encourages bad design. It's not powerful enough
 to
 be useful.



Can I add foreach_reverse? :)

-JJR
Dec 22 2008
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"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.
Dec 23 2008
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
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
Dec 23 2008
next sibling parent reply Don <nospam nospam.com> writes:
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
Dec 24 2008
next sibling parent "Nick Sabalausky" <a a.a> writes:
"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.
Dec 24 2008
prev sibling parent reply Yigal Chripun <yigal100 gmail.com> writes:
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
Dec 24 2008
parent reply "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
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.)
Dec 24 2008
next sibling parent Yigal Chripun <yigal100 gmail.com> writes:
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)) {...}
Dec 24 2008
prev sibling parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
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?
Dec 25 2008
parent Max Samukha <samukha voliacable.com.removethis> writes:
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
Dec 25 2008
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"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.
Dec 24 2008
prev sibling parent Yigal Chripun <yigal100 gmail.com> writes:
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 





 * 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.
Dec 23 2008
prev sibling parent reply Mikola Lysenko <mikolalysenko gmail.com> writes:
ifloat, idouble, ireal, cfloat, cdouble ... and of course creal
Dec 22 2008
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Mikola Lysenko:

 ifloat, idouble, ireal, cfloat, cdouble ... and of course creal


cfloat and cdouble seem useful to me.
They aren't redundant ways to do something.

Bye,
bearophile
Dec 22 2008
parent reply KennyTM~ <kennytm gmail.com> writes:
bearophile wrote:

 Mikola Lysenko:

 ifloat, idouble, ireal, cfloat, cdouble ... and of course creal


 
 cfloat and cdouble seem useful to me.
 They aren't redundant ways to do something.
 
 Bye,
 bearophile


But but but... there's std.complex already.
Dec 23 2008
parent bearophile <bearophileHUGS lycos.com> writes:
KennyTM~:

 But but but... there's std.complex already.


You are right, I am sorry.

bearophile
Dec 23 2008
prev sibling parent reply "Stewart Gordon" <smjg_1998 yahoo.com> writes:
"Mikola Lysenko" <mikolalysenko gmail.com> wrote in message 
news:giouum$1fnk$1 digitalmars.com...

 ifloat, idouble, ireal, cfloat, cdouble ... and of course creal


Why?

http://www.digitalmars.com/d/2.0/builtin.html

Stewart.

-- 
My e-mail address is valid but not my primary mailbox.  Please keep replies 
on the 'group where everybody may benefit.
Dec 22 2008
parent reply Mikola Lysenko <mikolalysenko gmail.com> writes:
Stewart Gordon Wrote:


 "Mikola Lysenko" <mikolalysenko gmail.com> wrote in message 
 news:giouum$1fnk$1 digitalmars.com...

 ifloat, idouble, ireal, cfloat, cdouble ... and of course creal


 
 Why?
 
 http://www.digitalmars.com/d/2.0/builtin.html
 
 Stewart.
 
 -- 
 My e-mail address is valid but not my primary mailbox.  Please keep replies 
 on the 'group where everybody may benefit. 
 


Please do not misunderstand -- I am not against builtins.  Dynamic/associative
arrays along with all their fancy syntax for iteration, concatenation and
slicing, are my favorite features in D.  I think that dynamic arrays alone
ought to be enough to sell D to any sane programmer, and I really wish more
languages would adopt similar features (I especially miss it when I'm
programming in CUDA.)  Dynamic arrays are such a successful innovation that
pretty much every D program around uses them (at the very least in
main(char[][]) ).

On the other hand, complex builtins are largely ignored.  Like array-types,
complex builtins were an early experiment in D's design (dating back to the
bad-old days before operator overloading or templates were even on the drawing
board!)  However, unlike arrays they are almost never used.  To quantify just
how rare, I tried the following google code search experiment:

Searches:
http://www.google.com/codesearch?q=lang%3Ad
http://www.google.com/codesearch?q=cfloat+lang%3Ad
http://www.google.com/codesearch?q=cdouble+lang%3Ad
http://www.google.com/codesearch?q=creal+lang%3Ad

Results:
D: 43,000 items
cfloat: 643 items
cdouble: 594 items
creal: 725 items

Even as low as these numbers are, they are still highly inflated inflated. 
After painstakingly going through each result, I can confidently claim that all
instances of the complex data types indexed by google fall into one of the
following categories:

1. Code from Tango/Phobos' math module
2. A special case in a generic template container
3. A special case in a generic IO module
4. Part of a D lexer

Notably absent from this list are cases where complex types were used for
actual arithmetic.  In fact, it seems that the only consequence of the complex
data types in real D is the generation of superfluous special cases !!!  (I
encourage anyone else to try repeating this experiment if they think I'm being
hyperbolic.)

Of course, it is true that builtin-complex does have some advantages.  The one
which is claimed on the rationale page is that the syntax is nicer.  This is
probably true, but I am unconvinced that it matters.  From my experience, I can
think of only one time where I actually found this feature useful - when I was
writing a Mandelbrodt set viewer to test out the complex number syntax in D. 
At any rate, I suspect that clever hackers in the D community can probably do
just as well, if not better, using clever template language tricks.

The other major argument for complex numbers as a builtin is the potential for
low level optimization.  To be honest, I have no idea how this actually works. 
I can't think of any optimization a compiler could do with a builtin complex
that it couldn't just as easily pull off on a templatized-struct.  I don't feel
that this claim holds much water, but I wouldn't mind being enlightened if
someone could demonstrate otherwise.

On the other hand, templatized complex numbers have several unique advantages. 
They can be easily extended to incorporate high precision or rational
arithmetic (which is useful in some audio processing applications.)  As an
algebraic tool, the basic complex class can be exploited to build up more
advanced algebraic types, such as Clifford algebras.  Finally (and most
importantly), the present template system would treat them like just another
struct, thus reducing enormous amounts of utterly redundant created to deal
with 6 extra primitive types.



In summary, here is how they stack up:

Builtin Complex:
Pros:
+ Syntactic sugar for imaginary literals
+ Potential for more advanced optimizations

Cons:
- Rarely used (see above)
- Language bloat
- Results in redundant interface code (special cases for IO, most templates,
etc.)
- "Imaginary Real" is a ridiculous name


Template Complex:
Pros:
+ Simplifies language
+ Easier template interfaces (complex!(T) vs. ifloat, idouble, ireal, cfloat,
cdouble, creal)
+ Supports rational, exact and variable precision arithmetic
+ Useful for implementing several algebraic systems, (Gaussian integers,
Clifford Algebras, quaternions)

Cons:
- Would require changing D in ways that break some existing code



Conclusion: Complex builtins were an interesting idea, but in practice they're
rarely used. Phasing them into a library template would eliminate a bunch of
redundant code, simplify the language in a meaningful way and improve
flexibility.  Win all around.

-Mik
Dec 22 2008
parent bearophile <bearophileHUGS lycos.com> writes:
Mikola Lysenko:


 Conclusion: Complex builtins were an interesting idea, but in practice they're
rarely used. Phasing them into a library template would eliminate a bunch of
redundant code, simplify the language in a meaningful way and improve
flexibility.  Win all around.<


It seems that your ideas are already accepted by D2 developers :-)
http://www.digitalmars.com/d/2.0/phobos/std_complex.html

Bye,
bearophile
Dec 23 2008