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 "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 next sibling parent "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
prev sibling next 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
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


 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 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];
 }


I want DMD (and grep) to help me chose to not let my minions make me READ them
Dec 19 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 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
parent 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?


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
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 "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
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 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=


 -- 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 bee=

 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=

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

 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=

 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.

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


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


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

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

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 next sibling parent "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.

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
prev sibling next sibling parent "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
prev sibling next 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 next sibling 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 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)).


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


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


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


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?


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.

Dec 23 2008
prev sibling parent "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