www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - dmd 1.046 and 2.031 releases

reply Walter Bright <newshound1 digitalmars.com> writes:
Something for everyone here.


http://www.digitalmars.com/d/1.0/changelog.html
http://ftp.digitalmars.com/dmd.1.046.zip


http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.031.zip
Jul 05 2009
next sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Ooooh... looks very nice.  Thanks again, Walter. :)

Incidentally, the links to Final Switch Statement and Case Range
Statement in the changelog for 2.031 are broken.
Jul 05 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Daniel Keep wrote:
 Ooooh... looks very nice.  Thanks again, Walter. :)

Actually, a lot of people worked on this release, not just me.
 
 Incidentally, the links to Final Switch Statement and Case Range
 Statement in the changelog for 2.031 are broken.

Jul 05 2009
next sibling parent Daniel Keep <daniel.keep.lists gmail.com> writes:
Walter Bright wrote:
 Daniel Keep wrote:
 Ooooh... looks very nice.  Thanks again, Walter. :)

Actually, a lot of people worked on this release, not just me.

True; but it's getting harder to keep track of. How about this? Thanks, mixin(reduce!"a~`, `~b"(D_CONTRIBUTORS)).
Jul 05 2009
prev sibling parent Tim Matthews <tim.matthews7 gmail.com> writes:
Walter Bright wrote:
 Daniel Keep wrote:
 Ooooh... looks very nice.  Thanks again, Walter. :)

Actually, a lot of people worked on this release, not just me.
 Incidentally, the links to Final Switch Statement and Case Range
 Statement in the changelog for 2.031 are broken.


You quoted that but still missed that you've mixxed up your 'a href links with the display name'. Thanks a lot for this release.
Jul 06 2009
prev sibling next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Sun, 05 Jul 2009 22:05:10 -0700, Walter Bright wrote:

 Something for everyone here.
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.046.zip
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.031.zip

The -deps= switch is helpful, but can we also have a "-nogen" switch so that a compile is done but no object files are created. Kind of like the "-c" switch which does a compile but no linking. Then we can use "-deps=dep.txt -nogen" to get the dependency data so build tools can then work out what needs to actually be compiled. And in that vein, a hash (eg CRC32, MD5, SHA256) of the file's used by DMD would be nice to see in the 'deps' file. Would help build tools detect which files have been modified. May I make a small syntax suggestion for the deps format. Instead of enclosing a path in parentheses, and using ':' as a field delimiter, have the first (and last) character of each line be the field delimiter to use in that line. The delimiter would be guaranteed to never be part of any of the fields' characters. That way, we don't need escape characters and parsing the text is greatly simplified. Also, simplifying the paths by resolving the ".." and "." would be nice. eg. !std.stdio!c:\dmd\dmd\src\phobos\std\stdio.d!public!std.format!c:\dmd\dmd\src\phobos\std\format.d! If this is ok can I submit a patch? -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Jul 05 2009
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
The deps thing comes from the LDC group. They've been relying on it 
as-is, so they'd need to agree on any changes.
Jul 05 2009
parent Christian Kamm <check-ldc commits.com> writes:
Walter Bright Wrote:
 The deps thing comes from the LDC group. They've been relying on it 
 as-is, so they'd need to agree on any changes.

Actually, it's from Tomasz' xfBuild http://wiki.team0xf.com/index.php?n=Tools.XfBuild . As it is intended as a generally useful dependency format though, I'm sure he'll open for suggestions.
Jul 06 2009
prev sibling next sibling parent Lutger <lutger.blijdestijn gmail.com> writes:
What about pragmas? Aren't both rebuild/dsss and Build using them for 
linking? It seems to me, you would still have to parse the source files for 
those.
Jul 06 2009
prev sibling next sibling parent reply BCS <none anon.com> writes:
Hello Derek,

 The -deps= switch is helpful, but can we also have a "-nogen" switch
 so that a compile is done but no object files are created. 

look at: -o-
Jul 06 2009
parent Derek Parnell <derek psych.ward> writes:
On Mon, 6 Jul 2009 15:03:20 +0000 (UTC), BCS wrote:

 Hello Derek,
 
 The -deps= switch is helpful, but can we also have a "-nogen" switch
 so that a compile is done but no object files are created. 

look at: -o-

Thanks, I've never noticed that switch before. Excellent. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Jul 06 2009
prev sibling parent Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
Derek Parnell wrote:
 Then we can use "-deps=dep.txt -nogen" to get the dependency data so build
 tools can then work out what needs to actually be compiled. And in that
 vein, a hash (eg CRC32, MD5, SHA256) of the file's used by DMD would be
 nice to see in the 'deps' file. Would help build tools detect which files
 have been modified.

I think this should be the job of the build tool, not the compiler. For example, xfBuild uses the compiler-generated dependency files to keep track of its own project database containing dependencies and file modification times. I guess I'll be adding hashes as well :) Why a separate file? When doing incremental builds, you'll only pass some of the project's modules to the compiler so the deps file would not contain everything. The proper approach is to parse it and update the project database with it.
 May I make a small syntax suggestion for the deps format. Instead of
 enclosing a path in parentheses, and using ':' as a field delimiter, have
 the first (and last) character of each line be the field delimiter to use
 in that line. The delimiter would be guaranteed to never be part of any of
 the fields' characters. That way, we don't need escape characters and
 parsing the text is greatly simplified.

I don't think the parsing is currently very complicated at all, but I guess YMMV. I'd argue that the current format is easier to generate and more human-readable than your proposed syntax. The latter might also be harder to process by UNIXy tools like grep or cut.
 Also, simplifying the paths by resolving the ".." and "." would be nice. 

Yea, that would be nice. -- Tomasz Stachowiak http://h3.team0xf.com/ h3/h3r3tic on #D freenode
Jul 07 2009
prev sibling next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Sun, 05 Jul 2009 22:05:10 -0700, Walter Bright wrote:

 Something for everyone here.
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.046.zip
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.031.zip

One of the very much appreciated updates here is "Implicit integral conversions that could result in loss of significant bits are no longer allowed.". An excellent enhancement, thank you. But I am confused as this below compiles without complaint... ----------- import std.stdio; void main() { byte iii; ubyte uuu = 250; iii = uuu; writefln("%s %s", iii, uuu); } ----------- Output is ... -6 250 But I expected the compiler to complain that an unsigned value cannot by implicitly converted to a signed value as that results in loss of *significant* bits. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Jul 05 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Derek Parnell wrote:
 One of the very much appreciated updates here is "Implicit integral
 conversions that could result in loss of significant bits are no longer
 allowed.". An excellent enhancement, thank you.

Thank Andrei for that, he was the prime mover behind it.
 
 But I am confused as this below compiles without complaint...
 -----------
 import std.stdio;
 void main()
 {
    byte iii;
    ubyte uuu = 250;
    iii = uuu;
    writefln("%s %s", iii, uuu);
 }
 -----------
 
 Output is ...
 -6 250
 
 But I expected the compiler to complain that an unsigned value cannot by
 implicitly converted to a signed value as that results in loss of
 *significant* bits.

We tried for a long time to come up with a sensible way to deal with the signed/unsigned dichotomy. We finally gave that up as unworkable. Instead, we opted for a method of significant bits, *not* how those bits are interpreted. -6 and 250 are the same bits in byte and ubyte, the difference is interpretation.
Jul 05 2009
parent reply Derek Parnell <derek psych.ward> writes:
On Sun, 05 Jul 2009 23:35:24 -0700, Walter Bright wrote:

 Derek Parnell wrote:
 One of the very much appreciated updates here is "Implicit integral
 conversions that could result in loss of significant bits are no longer
 allowed.". An excellent enhancement, thank you.

Thank Andrei for that, he was the prime mover behind it.

Yes, our English language is poor. I should have said "thank yous" ;-)
 But I am confused as this below compiles without complaint...
 -----------
 import std.stdio;
 void main()
 {
    byte iii;
    ubyte uuu = 250;
    iii = uuu;
    writefln("%s %s", iii, uuu);
 }
 -----------
 
 Output is ...
 -6 250
 
 But I expected the compiler to complain that an unsigned value cannot by
 implicitly converted to a signed value as that results in loss of
 *significant* bits.

We tried for a long time to come up with a sensible way to deal with the signed/unsigned dichotomy. We finally gave that up as unworkable. Instead, we opted for a method of significant bits, *not* how those bits are interpreted. -6 and 250 are the same bits in byte and ubyte, the difference is interpretation.

I am disappointed. I hope that you haven't stopped working on a solution to this though, as allowing D to silently permit bugs it could prevent is not something we are hoping for. I can see that the argument so far hinges on the meaning of "significant". I was hoping that a 'sign' bit would have been significant. As for "the same bits in X and Y, the different is interpretation", this is something that can be selective. For example ... ---------- short iii; struct U {align (1) byte a; byte b;} U uuu; iii = uuu; ---------- The bits in 'uuu' can be accommodated in 'iii' so why not allow implicit conversion? Yes, that is a rhetorical question. Because we know that the struct means something different to the scalar 'short', conversion via bit-mapping is not going to be valid in most cases. However, we also know that a signed value is not the same as an unsigned value even though they have the same number of bits; that is the compiler already knows how to interpret those bits. I'm struggling to see why the compiler cannot just disallow any signed<->unsigned implicit conversion? Is it a matter of backward compatibility again? -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Jul 05 2009
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Derek Parnell wrote:
 I'm struggling to see why the compiler cannot just disallow any
 signed<->unsigned implicit conversion? Is it a matter of backward
 compatibility again?

What's the signed-ness of 5? When you index a pointer, is the index signed or unsigned?
Jul 06 2009
parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 06 Jul 2009 00:11:26 -0700, Walter Bright wrote:

 Derek Parnell wrote:
 I'm struggling to see why the compiler cannot just disallow any
 signed<->unsigned implicit conversion? Is it a matter of backward
 compatibility again?

What's the signed-ness of 5?

Positive. A positive number can be assigned to an 'int' if there is no size issue. What's the problem that I'm obviously missing?
 When you index a pointer, is the index signed or unsigned?

An index can be either. What's the problem here? -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Jul 06 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Derek Parnell wrote:
 On Mon, 06 Jul 2009 00:11:26 -0700, Walter Bright wrote:
 
 Derek Parnell wrote:
 I'm struggling to see why the compiler cannot just disallow any
 signed<->unsigned implicit conversion? Is it a matter of backward
 compatibility again?


Positive. A positive number can be assigned to an 'int' if there is no size issue.

It can also be an unsigned.
 What's the problem that I'm obviously missing?
  
 When you index a pointer, is the index signed or unsigned?

An index can be either. What's the problem here?

auto x = p1 - p2; What's the type of x?
Jul 06 2009
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Denis Koroskin wrote:
 auto x = p1 - p2;

 What's the type of x?

ptrdiff_t, signed counterpart of size_t

Do you really want an error if you go: size_t y = p1 - p2; ?
Jul 06 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Denis Koroskin wrote:
 I'd put an assert and mad a case explicit, if there is a size_t is so 
 badly needed for ptr difference:
 
 assert(p1 >= p2);
 size_t y = cast(size_t)p1 - p2;

Aside from the typo in that code (!) the problem with casts is they are a sledgehammer approach. Casts should be minimized because they *hide* typing problems in the code. The more casts in the code, the more the type-checking abilities of the compiler are disabled. I suspect this will *hide* more bugs than it reveals. The reality is is that most integers used in programs are positive and relatively small. int and uint are equally correct for these, and people tend to use both in a mish-mash. Trying to build a barrier between them that requires explicit casting to overcome is going to require a lot of casts that accomplish nothing other than satisfying a nagging, annoying compiler. I've used such a compiler - Pascal back in the early 80s. All the casts it required me to insert basically sucked (and never revealed a single bug). When I discovered C with its sensible system of implicit casting, it was like putting on dry clothes after being soaked out in the cold rain.
Jul 06 2009
parent Chad J <chadjoan __spam.is.bad__gmail.com> writes:
Walter Bright wrote:
 Denis Koroskin wrote:
 I'd put an assert and mad a case explicit, if there is a size_t is so
 badly needed for ptr difference:

 assert(p1 >= p2);
 size_t y = cast(size_t)p1 - p2;

Aside from the typo in that code (!) the problem with casts is they are a sledgehammer approach. Casts should be minimized because they *hide* typing problems in the code. The more casts in the code, the more the type-checking abilities of the compiler are disabled. I suspect this will *hide* more bugs than it reveals. The reality is is that most integers used in programs are positive and relatively small. int and uint are equally correct for these, and people tend to use both in a mish-mash. Trying to build a barrier between them that requires explicit casting to overcome is going to require a lot of casts that accomplish nothing other than satisfying a nagging, annoying compiler. I've used such a compiler - Pascal back in the early 80s. All the casts it required me to insert basically sucked (and never revealed a single bug). When I discovered C with its sensible system of implicit casting, it was like putting on dry clothes after being soaked out in the cold rain.

In the context of a sign-sensitive language assert(p1 >= p2); size_t y = cast(size_t)p1 - p2; looks to me like it is equivalent to size_t y = p1 - p2; but in the context of a sign-insensitive language. The difference in behavior is that the former has a runtime assert, which is arguably useful. The difference in aesthetics/maintainability is that the former has that undesirable cast in there. Perhaps we can have the best of both worlds, and just make the latter work but automatically insert the given runtime assert while in debug/non-release mode. So in D2 the code size_t y = p1 - p2; would become assert(p1 >= p2); size_t y = p1 - p2; during compilation. Sure having negative indices around would eventually crash the program anyways, but it's really helpful to have the program crash as close to the bug's location as possible. (Also not seeing that typo. dmd seems to think it's alright syntactically, and don't we want p1 to be greater?)
Jul 06 2009
prev sibling parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 06 Jul 2009 03:13:45 -0700, Walter Bright wrote:

 Derek Parnell wrote:
 On Mon, 06 Jul 2009 00:11:26 -0700, Walter Bright wrote:
 
 Derek Parnell wrote:
 I'm struggling to see why the compiler cannot just disallow any
 signed<->unsigned implicit conversion? Is it a matter of backward
 compatibility again?


Positive. A positive number can be assigned to an 'int' if there is no size issue.

It can also be an unsigned.

Which is a positive value, right? Can you think of any unsigned value which is also negative?
 What's the problem that I'm obviously missing?
  
 When you index a pointer, is the index signed or unsigned?

An index can be either. What's the problem here?

auto x = p1 - p2; What's the type of x?

Is that what you meant by "index a pointer"? Anyhow, it is a signed value. The difference between any two random memory addresses can be positive or negative. Whatever the 'signedness' of 'x' is, the expression "p2 + x == p1" must be true. If p1 is 0 and p2 is uint.max then 'x' must still be able to hold (-uint.max)
 Denis Koroskin wrote:
 auto x = p1 - p2;

 What's the type of x?

ptrdiff_t, signed counterpart of size_t

Do you really want an error if you go: size_t y = p1 - p2;

Yes I do. size_t y = cast(size_t)p1 - p2; -- No error. ptrdiff_t y = p1 - p2; -- No error. size_t y = p1 - p2; -- Error. Safety is supposed to be enhance by using D, is it not? -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Jul 06 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Derek Parnell wrote:
 Safety is supposed to be enhance by using D, is it not?

See my post to Denis. Requiring too many casts reduces safety by essentially disabling the static type checking system.
Jul 06 2009
parent Derek Parnell <derek psych.ward> writes:
On Mon, 06 Jul 2009 11:02:12 -0700, Walter Bright wrote:

 Derek Parnell wrote:
 Safety is supposed to be enhance by using D, is it not?

See my post to Denis. Requiring too many casts reduces safety by essentially disabling the static type checking system.

I totaly agree that cast() should be avoided, almost at all costs. A better way in this situation is to use a variable that can accommodate the range of possible values. Only use the cast() construct if you are deliberately doing something other than normal. For example, if you know that the different between two addresses will always be less than a 16-bit value AND you are deliberately storing the difference in a 'short' then using a cast() is a good idea as it alerts the code reader to this unusual situation. short x = cast(short)(p1 - p2); However, auto x = p1 - p2; should imply that 'x' is able to hold any value from -(uintptr_t.max) to uintptr_t.max inclusive. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Jul 06 2009
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Derek Parnell wrote:
 I'm struggling to see why the compiler cannot just disallow any
 signed<->unsigned implicit conversion? Is it a matter of backward
 compatibility again?

What's the signed-ness of 5? When you index a pointer, is the index signed or unsigned?
Jul 06 2009
prev sibling next sibling parent reply MIURA Masahiro <echochamber gmail.com> writes:
Thanks for the new release!  Are case ranges limited to 256 cases?

% cat -n foo.d
     1  import std.conv;
     2  import std.stdio;
     3
     4  void main(string[] args)
     5  {
     6      int i = to!int(args[0]);
     7
     8      switch (i) {
     9      case int.min: .. case -1:   // line 9
    10          writefln("negative");
    11          break;
    12      case 0:
    13          writefln("zero");
    14          break;
    15      default:
    16          writefln("positive");
    17          break;
    18      }
    19  }
% dmd foo.d
foo.d(9): Error: more than 256 cases in case range
%
Jul 06 2009
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
MIURA Masahiro wrote:
 Thanks for the new release!  Are case ranges limited to 256 cases?

Yes.
Jul 06 2009
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Denis Koroskin wrote:
 Does it compare on case-by-case basis? Up to 256 comparisons?

What do you mean? Obj2asm will show what it is doing.
Jul 06 2009
parent Ary Borenszweig <ary esperanto.org.ar> writes:
Denis Koroskin wrote:
 On Mon, 06 Jul 2009 14:12:40 +0400, Walter Bright 
 <newshound1 digitalmars.com> wrote:
 
 Denis Koroskin wrote:
 Does it compare on case-by-case basis? Up to 256 comparisons?

What do you mean? Obj2asm will show what it is doing.

I mean, will it translate switch (i) { case 0: .. case 9: doSomething(); } into if (i == 0 || i == 1 || i == 2 || etc) doSomething(); or into if (i >=0 || i <= 9) doSomething();

I'm sure it translate it to: case 0: case 1: case 2: case 3: case 4: case 5: case 6: case 7: case 8: case 9: That's obvious from the "maximum of 256 cases allowed". And also you can see that in the source code. :) Statement *CaseRangeStatement::semantic(Scope *sc) ... /* This works by replacing the CaseRange with an array of Case's. * * case a: .. case b: s; * => * case a: * [...] * case b: * s; */
Jul 06 2009
prev sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Walter Bright escribio':
 MIURA Masahiro wrote:
 Thanks for the new release!  Are case ranges limited to 256 cases?

Yes.

Why?
Jul 06 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Ary Borenszweig wrote:
 Walter Bright escribio':
 MIURA Masahiro wrote:
 Thanks for the new release!  Are case ranges limited to 256 cases?


Why?

To avoid dealing with it in the back end for the moment. The back end will die if you pass it 3,000,000 case statements :-)
Jul 06 2009
parent BCS <ao pathlink.com> writes:
Reply to Walter,

 Ary Borenszweig wrote:
 
 Walter Bright escribio':
 
 MIURA Masahiro wrote:
 
 Thanks for the new release!  Are case ranges limited to 256 cases?
 



will die if you pass it 3,000,000 case statements :-)

I get your point. OTOH I rather suspect the back end will die if you give it 3,000,000 of just about anything.
Jul 06 2009
prev sibling next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Mon, 06 Jul 2009 12:19:47 +0400, Walter Bright  
<newshound1 digitalmars.com> wrote:

 MIURA Masahiro wrote:
 Thanks for the new release!  Are case ranges limited to 256 cases?

Yes.

Does it compare on case-by-case basis? Up to 256 comparisons?
Jul 06 2009
prev sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Mon, 06 Jul 2009 14:12:40 +0400, Walter Bright  
<newshound1 digitalmars.com> wrote:

 Denis Koroskin wrote:
 Does it compare on case-by-case basis? Up to 256 comparisons?

What do you mean? Obj2asm will show what it is doing.

I mean, will it translate switch (i) { case 0: .. case 9: doSomething(); } into if (i == 0 || i == 1 || i == 2 || etc) doSomething(); or into if (i >=0 || i <= 9) doSomething();
Jul 06 2009
prev sibling next sibling parent reply =?UTF-8?B?IuOBruOBl+OBhOOBiyAobm9zaGlpa2EpIg==?= writes:
Thank you for the great work, Walter and all the other contributors.

But I am a bit disappointed with the CaseRangeStatement syntax.
Why is it
    case 0: .. case 9:
instead of
    case 0 .. 9:

With the latter notation, ranges can be easily used together with 
commas, for example:
    case 0, 2 .. 4, 6 .. 9:

And CaseRangeStatement, being inconsistent with other syntaxes using the 
.. operator, i.e. slicing and ForeachRangeStatement, includes the endpoint.
Shouldn't D make use of another operator to express ranges that include 
the endpoints as Ruby or Perl6 does?
Jul 06 2009
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
のしいか (noshiika) wrote:
 Thank you for the great work, Walter and all the other contributors.
 
 But I am a bit disappointed with the CaseRangeStatement syntax.
 Why is it
    case 0: .. case 9:
 instead of
    case 0 .. 9:
 
 With the latter notation, ranges can be easily used together with 
 commas, for example:
    case 0, 2 .. 4, 6 .. 9:
 
 And CaseRangeStatement, being inconsistent with other syntaxes using the 
 .. operator, i.e. slicing and ForeachRangeStatement, includes the endpoint.
 Shouldn't D make use of another operator to express ranges that include 
 the endpoints as Ruby or Perl6 does?

I think this was hashed out ad nauseum in the n.g. D does introduce another operator, the :..case operator <g>.
Jul 06 2009
next sibling parent reply grauzone <none example.net> writes:
Walter Bright wrote:
 のしいか (noshiika) wrote:
 Thank you for the great work, Walter and all the other contributors.

 But I am a bit disappointed with the CaseRangeStatement syntax.
 Why is it
    case 0: .. case 9:
 instead of
    case 0 .. 9:


Or case [0..10]: ? Compatible to how list slicing works. Ah yes, bikeshed issue, but my solution is more beautiful. Also, Walter, did you ever think about doing something about the fall-through-by-default issue? Of course in a way that preserves C compatibility.
Jul 06 2009
next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
grauzone wrote:
 Also, Walter, did you ever think about doing something about the 
 fall-through-by-default issue? Of course in a way that preserves C 
 compatibility.

There have always been much more pressing issues.
Jul 06 2009
prev sibling next sibling parent reply Tim Matthews <tim.matthews7 gmail.com> writes:
grauzone wrote:
 Walter Bright wrote:
 のしいか (noshiika) wrote:
 Thank you for the great work, Walter and all the other contributors.

 But I am a bit disappointed with the CaseRangeStatement syntax.
 Why is it
    case 0: .. case 9:
 instead of
    case 0 .. 9:


Or case [0..10]: ? Compatible to how list slicing works. Ah yes, bikeshed issue, but my solution is more beautiful. Also, Walter, did you ever think about doing something about the fall-through-by-default issue? Of course in a way that preserves C compatibility.

Do u mean this http://digitalmars.com/d/2.0/statement.html#FinalSwitchStatement
Jul 06 2009
parent reply grauzone <none example.net> writes:
Tim Matthews wrote:
 grauzone wrote:
 Walter Bright wrote:
 のしいか (noshiika) wrote:
 Thank you for the great work, Walter and all the other contributors.

 But I am a bit disappointed with the CaseRangeStatement syntax.
 Why is it
    case 0: .. case 9:
 instead of
    case 0 .. 9:


Or case [0..10]: ? Compatible to how list slicing works. Ah yes, bikeshed issue, but my solution is more beautiful. Also, Walter, did you ever think about doing something about the fall-through-by-default issue? Of course in a way that preserves C compatibility.

Do u mean this http://digitalmars.com/d/2.0/statement.html#FinalSwitchStatement

No. Also, this final switch feature seems to be only marginally useful, and normal switch statements do the same, just at runtime. So much for "more pressing issues" but it's his language and not mine so I'll shut up.
Jul 06 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
grauzone wrote:
 No. Also, this final switch feature seems to be only marginally useful, 
 and normal switch statements do the same, just at runtime. So much for 
 "more pressing issues" but it's his language and not mine so I'll shut up.

The final switch deals with a problem where you add an enum member in one file and then have to find and update every switch statement that uses that enum. There's no straightforward way to find them to ensure the case gets added to each switch. It's solving a similar problem that symbolic constants do. The fall-through thing, though, is purely local and so much less of an issue.
Jul 06 2009
parent reply Chad J <chadjoan __spam.is.bad__gmail.com> writes:
Walter Bright wrote:
 grauzone wrote:
 No. Also, this final switch feature seems to be only marginally
 useful, and normal switch statements do the same, just at runtime. So
 much for "more pressing issues" but it's his language and not mine so
 I'll shut up.

The final switch deals with a problem where you add an enum member in one file and then have to find and update every switch statement that uses that enum. There's no straightforward way to find them to ensure the case gets added to each switch. It's solving a similar problem that symbolic constants do. The fall-through thing, though, is purely local and so much less of an issue.

huh? These bugs always take me no less than 2 hours to find, unless I am specifically looking for fall-through bugs. They are that evil kind of bug where you can stare at the exact lines of code that cause it and remain completely clueless until the epiphany hits. This is no good, unless the compiler can be rewritten to induce epiphanies. "much less of an issue" T_T
Jul 06 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Chad J wrote:
 Walter Bright wrote:
 grauzone wrote:
 No. Also, this final switch feature seems to be only marginally
 useful, and normal switch statements do the same, just at runtime. So
 much for "more pressing issues" but it's his language and not mine so
 I'll shut up.

one file and then have to find and update every switch statement that uses that enum. There's no straightforward way to find them to ensure the case gets added to each switch. It's solving a similar problem that symbolic constants do. The fall-through thing, though, is purely local and so much less of an issue.

huh? These bugs always take me no less than 2 hours to find, unless I am specifically looking for fall-through bugs.

I agree. Probably a good option would be to keep on requiring break, but also requiring the user to explicitly specify they want fallthrough in the rare case when they do want it. I'd love to use "continue" for that but it's already "occupied" by cases like while (...) switch (...). Requiring !break or ~break would work but is a bit too cute. Adding a new keyword or a whole new switch statement is too much aggravation. I guess we'll have to live with it... Andrei
Jul 06 2009
next sibling parent Ary Borenszweig <ary esperanto.org.ar> writes:
Denis Koroskin wrote:
 On Mon, 06 Jul 2009 22:48:07 +0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:
 
 Chad J wrote:
 Walter Bright wrote:
 grauzone wrote:
 No. Also, this final switch feature seems to be only marginally
 useful, and normal switch statements do the same, just at runtime. So
 much for "more pressing issues" but it's his language and not mine so
 I'll shut up.

one file and then have to find and update every switch statement that uses that enum. There's no straightforward way to find them to ensure the case gets added to each switch. It's solving a similar problem that symbolic constants do. The fall-through thing, though, is purely local and so much less of an issue.

These bugs always take me no less than 2 hours to find, unless I am specifically looking for fall-through bugs.

I agree. Probably a good option would be to keep on requiring break, but also requiring the user to explicitly specify they want fallthrough in the rare case when they do want it. I'd love to use "continue" for that but it's already "occupied" by cases like while (...) switch (...). Requiring !break or ~break would work but is a bit too cute. Adding a new keyword or a whole new switch statement is too much aggravation. I guess we'll have to live with it... Andrei

Reuse goto?

I was thinking "continue case;" But of course this discussion is pointless because it's bikeshed idontknow...
Jul 06 2009
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Denis Koroskin wrote:
 Reuse goto?

So any case-labeled code should end either with a control flow statement that transfers control elswhere? That sounds like a great idea. Fall-through is so rare and so rarely intended, it makes sense to require the programmer to state the intent explicitly via a goto case. Andrei
Jul 06 2009
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Jesse Phillips escribió:
 On Mon, 06 Jul 2009 14:38:53 -0500, Andrei Alexandrescu wrote:
 
 Denis Koroskin wrote:
 Reuse goto?

that transfers control elswhere? That sounds like a great idea. Fall-through is so rare and so rarely intended, it makes sense to require the programmer to state the intent explicitly via a goto case. Andrei

The goto method already works, the only change needed would be to not have fallthru default. http://digitalmars.com/d/2.0/statement.html#GotoStatement

But that's kind of redundant: case 1: goto case 11: case 11: goto case 111: case 111: goto case 1111: case 1111: doIt(); don't you think? If you change the case expression, you must change it twice. Why not: case 1: continue case; case 11: continue case; etc.?
Jul 06 2009
next sibling parent BCS <none anon.com> writes:
Hello Ary,

 But that's kind of redundant:
 
 case 1: goto case 11:
 case 11: goto case 111:
 case 111: goto case 1111:
 case 1111:
 doIt();
 don't you think?
 

case 1, 11, 111, 1111: doIt();
 If you change the case expression, you must change it twice.
 
 Why not:
 
 case 1: continue case;
 case 11: continue case;
 etc.?
 

Or how about the way c# does it: consecutive cases are treated as a single target. For that matter, it's debatable if going from one case label to an immediately following one even constitutes a fall through considering they are attached to the following statement rater than being statements in there own right.
Jul 06 2009
prev sibling parent reply KennyTM~ <kennytm gmail.com> writes:
Ary Borenszweig wrote:
 Jesse Phillips escribió:
 On Mon, 06 Jul 2009 14:38:53 -0500, Andrei Alexandrescu wrote:

 Denis Koroskin wrote:
 Reuse goto?

that transfers control elswhere? That sounds like a great idea. Fall-through is so rare and so rarely intended, it makes sense to require the programmer to state the intent explicitly via a goto case. Andrei

The goto method already works, the only change needed would be to not have fallthru default. http://digitalmars.com/d/2.0/statement.html#GotoStatement

But that's kind of redundant: case 1: goto case 11: case 11: goto case 111: case 111: goto case 1111: case 1111: doIt(); don't you think?

Maybe http://msdn.microsoft.com/en-us/vcsharp/aa336815.aspx .
 
 If you change the case expression, you must change it twice.
 
 Why not:
 
 case 1: continue case;
 case 11: continue case;
 
 etc.?

Jul 07 2009
parent bearophile <bearophileHUGS lycos.com> writes:
KennyTM~ Wrote:
 Maybe http://msdn.microsoft.com/en-us/vcsharp/aa336815.aspx .

That compromise design looks good to be adopted by D too :-) Bye, bearophile
Jul 07 2009
prev sibling parent reply Chad J <chadjoan __spam.is.bad__gmail.com> writes:
Andrei Alexandrescu wrote:
 Chad J wrote:
 These bugs always take me no less than 2 hours to find, unless I am
 specifically looking for fall-through bugs.

I agree. Probably a good option would be to keep on requiring break, but also requiring the user to explicitly specify they want fallthrough in the rare case when they do want it. I'd love to use "continue" for that but it's already "occupied" by cases like while (...) switch (...). Requiring !break or ~break would work but is a bit too cute. Adding a new keyword or a whole new switch statement is too much aggravation. I guess we'll have to live with it... Andrei

Don't marginalize something that's important! The syntax is arbitrary. Just pick something that works. Also, IIRC, the main argument in favor of fallthrough behavior was compatibility with C code. Now that we have "final switch", we can, with reasonable certainty, assume that no C coder has written "final switch(...) ...". Thus we are allowed to choose a syntax that's different without breaking anything. And for those few people that want to write Duff's device, they can just use the old style switch-case. <rambling and syntax> I'm personally a bit biased to the haXe switch-case statements that I've been using for the past few months. In haXe you don't even have to write break; at the end, it will always exit the statement at the end of a case-block. It also has that behavior added in final switch where switching on an enum requires you to be exhaustive about your handling of the possibilities. It has worked well. If it isn't powerful enough, there's always "goto label;" where label is either some external label or the name of one of the cases. I think I've seen that in C#. That also worked well. So something like this: final switch( foo ) { case 0: goto 1; // emulate the fallthrough case 1: writefln("Got a zero or a one."); case 2: writefln("This isn't supposed to happen."); } I wouldn't complain if it was done some other way though. Just killing the fallthrough bugs would make me so much happier. </rambling and syntax>
Jul 06 2009
next sibling parent Chad J <chadjoan __spam.is.bad__gmail.com> writes:
Chad J wrote:
 Andrei Alexandrescu wrote:
 Chad J wrote:
 These bugs always take me no less than 2 hours to find, unless I am
 specifically looking for fall-through bugs.

also requiring the user to explicitly specify they want fallthrough in the rare case when they do want it. I'd love to use "continue" for that but it's already "occupied" by cases like while (...) switch (...). Requiring !break or ~break would work but is a bit too cute. Adding a new keyword or a whole new switch statement is too much aggravation. I guess we'll have to live with it... Andrei

Don't marginalize something that's important! The syntax is arbitrary. Just pick something that works. Also, IIRC, the main argument in favor of fallthrough behavior was compatibility with C code. Now that we have "final switch", we can, with reasonable certainty, assume that no C coder has written "final switch(...) ...". Thus we are allowed to choose a syntax that's different without breaking anything. And for those few people that want to write Duff's device, they can just use the old style switch-case. <rambling and syntax> I'm personally a bit biased to the haXe switch-case statements that I've been using for the past few months. In haXe you don't even have to write break; at the end, it will always exit the statement at the end of a case-block. It also has that behavior added in final switch where switching on an enum requires you to be exhaustive about your handling of the possibilities. It has worked well. If it isn't powerful enough, there's always "goto label;" where label is either some external label or the name of one of the cases. I think I've seen that in C#. That also worked well. So something like this: final switch( foo ) { case 0: goto 1; // emulate the fallthrough case 1: writefln("Got a zero or a one."); case 2: writefln("This isn't supposed to happen."); } I wouldn't complain if it was done some other way though. Just killing the fallthrough bugs would make me so much happier. </rambling and syntax>

Err, forgot to show usage in the example. auto foo = 0; final switch( foo ) { case 0: goto 1; // emulate the fallthrough case 1: writefln("Got a zero or a one."); case 2: writefln("This isn't supposed to happen."); } // "Got a zero or a one." is printed.
Jul 06 2009
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Chad J wrote:
 Andrei Alexandrescu wrote:
 Chad J wrote:
 These bugs always take me no less than 2 hours to find, unless I am
 specifically looking for fall-through bugs.

also requiring the user to explicitly specify they want fallthrough in the rare case when they do want it. I'd love to use "continue" for that but it's already "occupied" by cases like while (...) switch (...). Requiring !break or ~break would work but is a bit too cute. Adding a new keyword or a whole new switch statement is too much aggravation. I guess we'll have to live with it... Andrei

Don't marginalize something that's important! The syntax is arbitrary. Just pick something that works.

I've posted here and also sent private message to Walter asking him what he thinks of requiring each case to end with a control flow statement.
 Also, IIRC, the main argument in favor of fallthrough behavior was
 compatibility with C code.  Now that we have "final switch", we can,
 with reasonable certainty, assume that no C coder has written "final
 switch(...) ...".  Thus we are allowed to choose a syntax that's
 different without breaking anything.  And for those few people that want
 to write Duff's device, they can just use the old style switch-case.

That's not the restriction we're having. The C-compatibility restriction is to not have code that compiles in both C and D and has different semantics in the two languages. So requiring all case-labeled sections in a switch statement to end with a control flow statement would leave some code that compiles in C but not in D. That is acceptable.
 <rambling and syntax>
 I'm personally a bit biased to the haXe switch-case statements that I've
 been using for the past few months.  In haXe you don't even have to
 write break; at the end, it will always exit the statement at the end of
 a case-block.  It also has that behavior added in final switch where
 switching on an enum requires you to be exhaustive about your handling
 of the possibilities.  It has worked well.  If it isn't powerful enough,
 there's always "goto label;" where label is either some external label
 or the name of one of the cases.  I think I've seen that in C#.  That
 also worked well.
 
 So something like this:
 
 final switch( foo )
 {
 	case 0: goto 1; // emulate the fallthrough
 	case 1: writefln("Got a zero or a one.");
 	case 2: writefln("This isn't supposed to happen.");
 }
 
 I wouldn't complain if it was done some other way though.  Just killing
 the fallthrough bugs would make me so much happier.
 </rambling and syntax>

There is a goto case statement in D already. The only change we need to effect is to require it for fall-through code. Andrei
Jul 06 2009
parent Chad J <chadjoan __spam.is.bad__gmail.com> writes:
Andrei Alexandrescu wrote:
 [awesome stuff]
 
 
 Andrei

Jul 06 2009
prev sibling next sibling parent reply BCS <ao pathlink.com> writes:
Reply to Chad,

 Walter Bright wrote:
 
 The fall-through thing, though, is purely local and so much less of
 an issue.
 

These bugs always take me no less than 2 hours to find, unless I am specifically looking for fall-through bugs. They are that evil kind of bug where you can stare at the exact lines of code that cause it and remain completely clueless until the epiphany hits. This is no good, unless the compiler can be rewritten to induce epiphanies. "much less of an issue" T_T

The much worse class of bugs is the ones that you can be staring at the location of the bug, have an epiphany about what the bug is and still not be able to tell if it is the case: the bug is here, but cause by a line of code that could be anywhere.
Jul 06 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
BCS wrote:
 The much worse class of bugs is the ones that you can be staring at the 
 location of the bug, have an epiphany about what the bug is and still 
 not be able to tell if it is the case: the bug is here, but cause by a 
 line of code that could be anywhere.

If I understand that correctly, it's when you alter one line or declaration in one part of the code, and it silently breaks another piece of code far away in some other piece of not-obviously-related code. I tend to agree. It's why we don't hardcode array dimensions outside of the declaration - we started out in C by using a #define for it, and then in D encode the array dimension as part of the type. A local issue is one that has no adverse effects outside of the local context. The fall-through would be this. A non-local one is one like adding an enum case, because it can silently break code far away. D makes some significant progress in reducing the non-local effects of changes, and is one of the big improvements over using C and C++.
Jul 06 2009
prev sibling parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 06 Jul 2009 13:47:44 -0500, Andrei Alexandrescu wrote:

 Chad J wrote:
 Walter Bright wrote:
 grauzone wrote:
 No. Also, this final switch feature seems to be only marginally
 useful, and normal switch statements do the same, just at runtime. So
 much for "more pressing issues" but it's his language and not mine so
 I'll shut up.

one file and then have to find and update every switch statement that uses that enum. There's no straightforward way to find them to ensure the case gets added to each switch. It's solving a similar problem that symbolic constants do. The fall-through thing, though, is purely local and so much less of an issue.

huh? These bugs always take me no less than 2 hours to find, unless I am specifically looking for fall-through bugs.

I agree. Probably a good option would be to keep on requiring break, but also requiring the user to explicitly specify they want fallthrough in the rare case when they do want it. I'd love to use "continue" for that but it's already "occupied" by cases like while (...) switch (...). Requiring !break or ~break would work but is a bit too cute. Adding a new keyword or a whole new switch statement is too much aggravation. I guess we'll have to live with it...

"too much aggravation" for whom? Certainly not for the coder, IMO. Consider this syntax suggestion ... int x = 1; switch (x; fallthru) { case 1: write(1); case 2: write(2); } Output: 12 int x = 1; switch (x; break) { case 1: write(1); case 2: write(2); } Output: 1 int x = 1; switch (x; fallthru) { case 1: write(1); break; case 2: write(2); } Output: 1 int x = 1; switch (x; break) { case 1: write(1); fallthru; case 2: write(2); } Output: 12 The default case "switch (x) {" would be the same as "switch (x; fallthru) {". One new keyword, and not a standard English word, allows all bases to be covered. Too much aggravation for whom? By the way, the above syntax format suggestion is because I see that the syntax for 'switch' is ... switch ( Expression ) ScopeStatement and ScopeStatement is either a BlockStatement or a NonEmptyStatement. Meaning that switch (i) j = k; is valid syntax! Why is that? -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Jul 06 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Derek Parnell wrote:
 On Mon, 06 Jul 2009 13:47:44 -0500, Andrei Alexandrescu wrote:
 
 Chad J wrote:
 Walter Bright wrote:
 grauzone wrote:
 No. Also, this final switch feature seems to be only marginally
 useful, and normal switch statements do the same, just at runtime. So
 much for "more pressing issues" but it's his language and not mine so
 I'll shut up.

one file and then have to find and update every switch statement that uses that enum. There's no straightforward way to find them to ensure the case gets added to each switch. It's solving a similar problem that symbolic constants do. The fall-through thing, though, is purely local and so much less of an issue.

These bugs always take me no less than 2 hours to find, unless I am specifically looking for fall-through bugs.

also requiring the user to explicitly specify they want fallthrough in the rare case when they do want it. I'd love to use "continue" for that but it's already "occupied" by cases like while (...) switch (...). Requiring !break or ~break would work but is a bit too cute. Adding a new keyword or a whole new switch statement is too much aggravation. I guess we'll have to live with it...

"too much aggravation" for whom? Certainly not for the coder, IMO. Consider this syntax suggestion ...

Well, I think I'd call that aggravation. Andrei
Jul 06 2009
parent Derek Parnell <derek psych.ward> writes:
On Mon, 06 Jul 2009 14:42:12 -0500, Andrei Alexandrescu wrote:

 Well, I think I'd call that aggravation.

Ok, if we do not have to bend to the C winds, then the default would be to have switch NOT fall through. That way we do not have to code "break;" at all. Is that aggravation? And then for those rare times when a falling through is required, recycle the "goto" or any other existing key word - (I hear that "static" is always available) - to affect a fall through behaviour. Anyhow, sorry to have been a nuisance again. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Jul 06 2009
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
grauzone wrote:
 Walter Bright wrote:
 のしいか (noshiika) wrote:
 But I am a bit disappointed with the CaseRangeStatement syntax.
 Why is it
    case 0: .. case 9:
 instead of
    case 0 .. 9:


Or case [0..10]: ? Compatible to how list slicing works. Ah yes, bikeshed issue, but my solution is more beautiful.

No, it isn't compatible. [0..10] for slices does not include the 10, while the case range does. Using Andrei's syntax clearly makes the point that it is different, and not confusingly similar to something very different.
Jul 06 2009
prev sibling parent reply Jason House <jason.james.house gmail.com> writes:
Walter Bright Wrote:

 のしいか (noshiika) wrote:
 Thank you for the great work, Walter and all the other contributors.
 
 But I am a bit disappointed with the CaseRangeStatement syntax.
 Why is it
    case 0: .. case 9:
 instead of
    case 0 .. 9:
 
 With the latter notation, ranges can be easily used together with 
 commas, for example:
    case 0, 2 .. 4, 6 .. 9:
 
 And CaseRangeStatement, being inconsistent with other syntaxes using the 
 .. operator, i.e. slicing and ForeachRangeStatement, includes the endpoint.
 Shouldn't D make use of another operator to express ranges that include 
 the endpoints as Ruby or Perl6 does?

I think this was hashed out ad nauseum in the n.g.

Hardly. There seemed to mostly be complaints about it with Andrei saying things like "I can't believe you don't see the elegance of the syntax". In the end, Andrei commented that he shouldn't involve the community in such small changes and went silent.
Jul 06 2009
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Jason House:
 Hardly. There seemed to mostly be complaints about it with Andrei saying
things like "I can't believe you don't see the elegance of the syntax". In the
end, Andrei commented that he shouldn't involve the community in such small
changes and went silent.<

He was wrong. Even very intelligent people now and then do the wrong thing. Bye, bearophile
Jul 06 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
bearophile wrote:
 Jason House:
 Hardly. There seemed to mostly be complaints about it with Andrei saying
things like "I can't believe you don't see the elegance of the syntax". In the
end, Andrei commented that he shouldn't involve the community in such small
changes and went silent.<

He was wrong. Even very intelligent people now and then do the wrong thing.

Of course the latter statement is true, but is in no way evidence supporting the former. About the former, in that particular case I was right. Andrei
Jul 06 2009
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Andrei Alexandrescu wrote:
 bearophile wrote:
 Jason House:
 Hardly. There seemed to mostly be complaints about it with Andrei
 saying things like "I can't believe you don't see the elegance of the
 syntax". In the end, Andrei commented that he shouldn't involve the
 community in such small changes and went silent.<

He was wrong. Even very intelligent people now and then do the wrong thing.

Of course the latter statement is true, but is in no way evidence supporting the former. About the former, in that particular case I was right. Andrei

Now, now. Let's all play nicely together... I don't like the `case a:..case b:` syntax. It doesn't matter. The functionality is in place and the syntax has a sane explanation and rationale. Unless there's some egregious problem aside from being a bit on the ugly side [1], it's just bike-shedding. And I'm so, SOOO sick of bike-shedding. Please, let's all just move on. [1] like me. My girlfriend disagrees with me on this, though. *I* think she's crazy, but I'm not exactly inclined to try and change her mind. :)
Jul 06 2009
next sibling parent reply BCS <none anon.com> writes:
Hello Daniel,

 [1] like me. My girlfriend disagrees with me on this,

You have a girlfriend that even bothers to have an opinion on a programming issue, lucky bastard.
 though. *I* think she's crazy, but I'm not exactly
 inclined to try and change her mind. :)

That reminds me of a quote: "If you assume a woman's mind is supposed to work like a man's, the only conclusion you can come to is they are *all* crazy." OTOH you can switch the perspective on that around and I expect it's just as true. It should be pointed out that, almost by definition, you can't have 50% of the world be crazy.
Jul 07 2009
next sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
BCS wrote:
 Hello Daniel,
 
 [1] like me. My girlfriend disagrees with me on this,

You have a girlfriend that even bothers to have an opinion on a programming issue, lucky bastard.

No, when I said "like me", I meant: "Unless there's some egregious problem aside from being a bit on the ugly side (like me), ..." My girlfriend is actually a nurse, but I could ask for her opinion on case ranges if you want. :)
 though. *I* think she's crazy, but I'm not exactly
 inclined to try and change her mind. :)

That reminds me of a quote: "If you assume a woman's mind is supposed to work like a man's, the only conclusion you can come to is they are *all* crazy." OTOH you can switch the perspective on that around and I expect it's just as true. It should be pointed out that, almost by definition, you can't have 50% of the world be crazy.

My opinion is based more on that, with respect to the above issue, she seems to think differently to more or less everyone else I've ever met, including myself.
Jul 07 2009
parent BCS <none anon.com> writes:
Hello Daniel,

 BCS wrote:
 
 Hello Daniel,
 
 [1] like me. My girlfriend disagrees with me on this,
 

programming issue, lucky bastard.

"Unless there's some egregious problem aside from being a bit on the ugly side (like me), ..." My girlfriend is actually a nurse, but I could ask for her opinion on case ranges if you want. :)

Odd, the exact same words read differently around midnight. :b
Jul 07 2009
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
BCS wrote:
 Hello Daniel,
 
 [1] like me. My girlfriend disagrees with me on this,

You have a girlfriend that even bothers to have an opinion on a programming issue, lucky bastard.

My understanding is that he's referring to a different issue.
 though. *I* think she's crazy, but I'm not exactly
 inclined to try and change her mind. :)

That reminds me of a quote: "If you assume a woman's mind is supposed to work like a man's, the only conclusion you can come to is they are *all* crazy."

To paraphrase: "If you assume a woman's mind is supposed to work like a man's, you won't get laid. Ever." Andrei
Jul 07 2009
parent Ary Borenszweig <ary esperanto.org.ar> writes:
Andrei Alexandrescu escribi:
 BCS wrote:
 Hello Daniel,

 [1] like me. My girlfriend disagrees with me on this,

You have a girlfriend that even bothers to have an opinion on a programming issue, lucky bastard.

My understanding is that he's referring to a different issue.
 though. *I* think she's crazy, but I'm not exactly
 inclined to try and change her mind. :)

That reminds me of a quote: "If you assume a woman's mind is supposed to work like a man's, the only conclusion you can come to is they are *all* crazy."

To paraphrase: "If you assume a woman's mind is supposed to work like a man's, you won't get laid. Ever."

lol :)
Jul 07 2009
prev sibling parent Leandro Lucarella <llucax gmail.com> writes:
Daniel Keep, el  7 de julio a las 15:40 me escribiste:
 
 
 Andrei Alexandrescu wrote:
 bearophile wrote:
 Jason House:
 Hardly. There seemed to mostly be complaints about it with Andrei
 saying things like "I can't believe you don't see the elegance of the
 syntax". In the end, Andrei commented that he shouldn't involve the
 community in such small changes and went silent.<

He was wrong. Even very intelligent people now and then do the wrong thing.

Of course the latter statement is true, but is in no way evidence supporting the former. About the former, in that particular case I was right. Andrei

Now, now. Let's all play nicely together... I don't like the `case a:..case b:` syntax. It doesn't matter. The functionality is in place and the syntax has a sane explanation and rationale. Unless there's some egregious problem aside from being a bit on the ugly side [1], it's just bike-shedding. And I'm so, SOOO sick of bike-shedding.

I think Walter is right, this syntax introduce an inconsistency in the ".." operator semantics, which is used with inclusive meaning sometimes (case) and with exclusive meaning other times (slices and foreach). -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ----------------------------------------------------------------------------
Jul 07 2009
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Jason House wrote:
 Walter Bright Wrote:
 
 のしいか (noshiika) wrote:
 Thank you for the great work, Walter and all the other contributors.

 But I am a bit disappointed with the CaseRangeStatement syntax.
 Why is it
    case 0: .. case 9:
 instead of
    case 0 .. 9:

 With the latter notation, ranges can be easily used together with 
 commas, for example:
    case 0, 2 .. 4, 6 .. 9:

 And CaseRangeStatement, being inconsistent with other syntaxes using the 
 .. operator, i.e. slicing and ForeachRangeStatement, includes the endpoint.
 Shouldn't D make use of another operator to express ranges that include 
 the endpoints as Ruby or Perl6 does?


Hardly. There seemed to mostly be complaints about it with Andrei saying things like "I can't believe you don't see the elegance of the syntax".

There's been also suggestions of inferior syntax, as are now. Andrei
Jul 06 2009
prev sibling next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
のしいか (noshiika) escribió:
 Thank you for the great work, Walter and all the other contributors.
 
 But I am a bit disappointed with the CaseRangeStatement syntax.
 Why is it
    case 0: .. case 9:
 instead of
    case 0 .. 9:
 
 With the latter notation, ranges can be easily used together with 
 commas, for example:
    case 0, 2 .. 4, 6 .. 9:
 
 And CaseRangeStatement, being inconsistent with other syntaxes using the 
 .. operator, i.e. slicing and ForeachRangeStatement, includes the endpoint.
 Shouldn't D make use of another operator to express ranges that include 
 the endpoints as Ruby or Perl6 does?

I agree. I think this syntax is yet another one of those things people looking at D will say "ugly" and turn their heads away.
Jul 06 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Ary Borenszweig wrote:
 のしいか (noshiika) escribió:
 Thank you for the great work, Walter and all the other contributors.

 But I am a bit disappointed with the CaseRangeStatement syntax.
 Why is it
    case 0: .. case 9:
 instead of
    case 0 .. 9:

 With the latter notation, ranges can be easily used together with 
 commas, for example:
    case 0, 2 .. 4, 6 .. 9:

 And CaseRangeStatement, being inconsistent with other syntaxes using 
 the .. operator, i.e. slicing and ForeachRangeStatement, includes the 
 endpoint.
 Shouldn't D make use of another operator to express ranges that 
 include the endpoints as Ruby or Perl6 does?

I agree. I think this syntax is yet another one of those things people looking at D will say "ugly" and turn their heads away.

And what did those people use when they wanted to express a range of case labels? In other words, where did those people turn their heads towards? Andrei
Jul 06 2009
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
Andrei Alexandrescu wrote:
 Ary Borenszweig wrote:
 のしいか (noshiika) escribió:
 Thank you for the great work, Walter and all the other contributors.

 But I am a bit disappointed with the CaseRangeStatement syntax.
 Why is it
    case 0: .. case 9:
 instead of
    case 0 .. 9:

 With the latter notation, ranges can be easily used together with 
 commas, for example:
    case 0, 2 .. 4, 6 .. 9:

 And CaseRangeStatement, being inconsistent with other syntaxes using 
 the .. operator, i.e. slicing and ForeachRangeStatement, includes the 
 endpoint.
 Shouldn't D make use of another operator to express ranges that 
 include the endpoints as Ruby or Perl6 does?

I agree. I think this syntax is yet another one of those things people looking at D will say "ugly" and turn their heads away.

And what did those people use when they wanted to express a range of case labels? In other words, where did those people turn their heads towards?

They probably used an if. But I think it's not about that. If D didn't have the possibility to define case range statements, it would be better. Now there's a possibility to do that, but with an ugly syntax (you'll find out when this newsgroup will receive about one or two complaints about this each month, not to mention there were already a lot of complaints). You can find other "ugly" things by looking at repetitive mails to this newsgroup. Also, there's a limitation of just 256 cases. What's that? Where that limitation come from? That looks week.
Jul 06 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Ary Borenszweig wrote:
 Andrei Alexandrescu wrote:
 Ary Borenszweig wrote:
 のしいか (noshiika) escribió:
 Thank you for the great work, Walter and all the other contributors.

 But I am a bit disappointed with the CaseRangeStatement syntax.
 Why is it
    case 0: .. case 9:
 instead of
    case 0 .. 9:

 With the latter notation, ranges can be easily used together with 
 commas, for example:
    case 0, 2 .. 4, 6 .. 9:

 And CaseRangeStatement, being inconsistent with other syntaxes using 
 the .. operator, i.e. slicing and ForeachRangeStatement, includes 
 the endpoint.
 Shouldn't D make use of another operator to express ranges that 
 include the endpoints as Ruby or Perl6 does?

I agree. I think this syntax is yet another one of those things people looking at D will say "ugly" and turn their heads away.

And what did those people use when they wanted to express a range of case labels? In other words, where did those people turn their heads towards?

They probably used an if.

So they used an inferior means to start with.
 But I think it's not about that. If D didn't have the possibility to 
 define case range statements, it would be better. Now there's a 
 possibility to do that, but with an ugly syntax (you'll find out when 
 this newsgroup will receive about one or two complaints about this each 
 month, not to mention there were already a lot of complaints).

This is speculation. And the complaints usually were accompanied with inferior suggestions for "improving" things. Everyone wanted to add some incomprehensible, inconsistent, or confusing syntax to do ranged cases, as long as it wasn't the one I'd chosen.
 You can 
 find other "ugly" things by looking at repetitive mails to this newsgroup.

I and others don't find the added syntax ugly in the least.
 Also, there's a limitation of just 256 cases. What's that? Where that 
 limitation come from? That looks week.

That's just an implementation limitation that future versions will eliminate. Andrei
Jul 06 2009
next sibling parent Chad J <chadjoan __spam.is.bad__gmail.com> writes:
Andrei Alexandrescu wrote:
 Ary Borenszweig wrote:
 Andrei Alexandrescu wrote:
 Ary Borenszweig wrote:
 のしいか (noshiika) escribió:
 Thank you for the great work, Walter and all the other contributors.

 But I am a bit disappointed with the CaseRangeStatement syntax.
 Why is it
    case 0: .. case 9:
 instead of
    case 0 .. 9:

 With the latter notation, ranges can be easily used together with
 commas, for example:
    case 0, 2 .. 4, 6 .. 9:

 And CaseRangeStatement, being inconsistent with other syntaxes
 using the .. operator, i.e. slicing and ForeachRangeStatement,
 includes the endpoint.
 Shouldn't D make use of another operator to express ranges that
 include the endpoints as Ruby or Perl6 does?

I agree. I think this syntax is yet another one of those things people looking at D will say "ugly" and turn their heads away.

And what did those people use when they wanted to express a range of case labels? In other words, where did those people turn their heads towards?

They probably used an if.

So they used an inferior means to start with.
 But I think it's not about that. If D didn't have the possibility to
 define case range statements, it would be better. Now there's a
 possibility to do that, but with an ugly syntax (you'll find out when
 this newsgroup will receive about one or two complaints about this
 each month, not to mention there were already a lot of complaints).

This is speculation. And the complaints usually were accompanied with inferior suggestions for "improving" things. Everyone wanted to add some incomprehensible, inconsistent, or confusing syntax to do ranged cases, as long as it wasn't the one I'd chosen.
 You can find other "ugly" things by looking at repetitive mails to
 this newsgroup.

I and others don't find the added syntax ugly in the least.
 Also, there's a limitation of just 256 cases. What's that? Where that
 limitation come from? That looks week.

That's just an implementation limitation that future versions will eliminate. Andrei

Shoving is the way. Pushing is inferior.
Jul 06 2009
prev sibling parent reply Leandro Lucarella <llucax gmail.com> writes:
Andrei Alexandrescu, el  6 de julio a las 10:44 me escribiste:
And what did those people use when they wanted to express a range of case 
labels? In other words, where did those people turn their heads towards?


So they used an inferior means to start with.

Yes, but when you try to make people move to a different language, you have to do considerably better. When I have to choose between something well know, well supported and mature and something that is, at least, unknown (even if it's mature and well supported, I won't know that until I use it a lot so is a risk), I want to be really good, not just barely good. Details as this one are not deal breaker on their own, but when they are a lot, it tends to make the language look ugly as a whole. What bugs me the most is there are a lot of new constructs in the language that are plain ugly, from the start. D is buying it's own baggage (__traits, enum for manifest constants, now the case range, and I'm sure I'm forgetting something else) with no reason... -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ----------------------------------------------------------------------------
Jul 06 2009
next sibling parent reply aarti_pl <aarti interia.pl> writes:
Leandro Lucarella pisze:
 Andrei Alexandrescu, el  6 de julio a las 10:44 me escribiste:
 And what did those people use when they wanted to express a range of case 
 labels? In other words, where did those people turn their heads towards?



Yes, but when you try to make people move to a different language, you have to do considerably better. When I have to choose between something well know, well supported and mature and something that is, at least, unknown (even if it's mature and well supported, I won't know that until I use it a lot so is a risk), I want to be really good, not just barely good. Details as this one are not deal breaker on their own, but when they are a lot, it tends to make the language look ugly as a whole. What bugs me the most is there are a lot of new constructs in the language that are plain ugly, from the start. D is buying it's own baggage (__traits, enum for manifest constants, now the case range, and I'm sure I'm forgetting something else) with no reason...

... * foreach_reverse * access to variadic function parameters with _argptr & _arguments * mess with compile time is expression (sorry, that's my favorite ugliness :-] ) I believe that this issues are greatly underestimated by D language designers... BR Marcin Kuszczak (aarti_pl)
Jul 06 2009
parent Leandro Lucarella <llucax gmail.com> writes:
aarti_pl, el  7 de julio a las 00:27 me escribiste:
 Leandro Lucarella pisze:
Andrei Alexandrescu, el  6 de julio a las 10:44 me escribiste:
And what did those people use when they wanted to express a range of case 
labels? In other words, where did those people turn their heads towards?



have to do considerably better. When I have to choose between something well know, well supported and mature and something that is, at least, unknown (even if it's mature and well supported, I won't know that until I use it a lot so is a risk), I want to be really good, not just barely good. Details as this one are not deal breaker on their own, but when they are a lot, it tends to make the language look ugly as a whole. What bugs me the most is there are a lot of new constructs in the language that are plain ugly, from the start. D is buying it's own baggage (__traits, enum for manifest constants, now the case range, and I'm sure I'm forgetting something else) with no reason...

... * foreach_reverse * access to variadic function parameters with _argptr & _arguments * mess with compile time is expression (sorry, that's my favorite ugliness :-] )

But these ones at least are not new (I'm sure they were new at some point, but now are baggage). The new constructs are future baggage. -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ----------------------------------------------------------------------------
Jul 07 2009
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Leandro Lucarella wrote:
 Andrei Alexandrescu, el  6 de julio a las 10:44 me escribiste:
 And what did those people use when they wanted to express a range of case 
 labels? In other words, where did those people turn their heads towards?



Yes, but when you try to make people move to a different language, you have to do considerably better. When I have to choose between something well know, well supported and mature and something that is, at least, unknown (even if it's mature and well supported, I won't know that until I use it a lot so is a risk), I want to be really good, not just barely good.

That goes without saying.
 Details as this one are not deal breaker on their own, but when they are
 a lot, it tends to make the language look ugly as a whole.

You are just saying it's ugly. I don't think it's ugly. Walter doesn't think it's ugly. Other people don't think it's ugly. Many of the people who said it's ugly actually came up with proposals that are arguably ugly, hopelessly confusing, or both. Look at only some of the rehashed proposals of today: the genial "case [0 .. 10]:" which is horribly inconsistent, and the awesome "case 0: ... case 10:", also inconsistent (and gratuitously so) because ellipses today only end lists without having something to their right. The authors claim those are better than the current syntax, and one even claimed "beauty", completely ignoring the utter lack of consistency with the rest of the language. I don't claim expertise in language design, so I wish there were a few good experts in this group.
 What bugs me the most is there are a lot of new constructs in the language
 that are plain ugly, from the start. D is buying it's own baggage
 (__traits, enum for manifest constants, now the case range, and I'm sure
 I'm forgetting something else) with no reason...

I agree there are ugly constructs in D, and is-expressions would near the top of the list (particularly the absolutely awful is(T : T[])), but you have no case (heh) with the switch statement. Andrei
Jul 06 2009
next sibling parent reply grauzone <none example.net> writes:
 You are just saying it's ugly. I don't think it's ugly. Walter doesn't 
 think it's ugly. Other people don't think it's ugly. Many of the people 
 who said it's ugly actually came up with proposals that are arguably 
 ugly, hopelessly confusing, or both. Look at only some of the rehashed 
 proposals of today: the genial "case [0 .. 10]:" which is horribly 
 inconsistent, and the awesome "case 0: ... case 10:", also inconsistent 
 (and gratuitously so) because ellipses today only end lists without 
 having something to their right. The authors claim those are better than 
 the current syntax, and one even claimed "beauty", completely ignoring 
 the utter lack of consistency with the rest of the language. I don't 

I oriented this on the syntax of array slices. Which work that way. Not inconsistent at all. It's also consistent with foreach(_; x..y). Other than that, I realize it's not that good of a choice and it's not elegant at all. But I think it's still better than some of your horrible language crimes (including yours) that are being forced into D. In any way, I think we should completely redesign the switch statement and give it a different syntax. No more C compatibility. No more Duff's device. We can keep the "old" switch statement for that.
Jul 06 2009
next sibling parent grauzone <none example.net> writes:
 In any way, I think we should completely redesign the switch statement 
 and give it a different syntax. No more C compatibility. No more Duff's 
 device. We can keep the "old" switch statement for that.

PS: we could add awesome stuff like pattern matching to this, which would make D much more functional language like, which seems to be the new cool thing to do. We can also omit case labels completely, which will reduce repeated typing of keywords.
Jul 06 2009
prev sibling next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
grauzone wrote:
 I oriented this on the syntax of array slices. Which work that way. Not 
 inconsistent at all. It's also consistent with foreach(_; x..y).

It would look consistent, but it would behave very differently. x..y for foreach and slices is exclusive of the y, while case x..y is inclusive. Creating such an inconsistency would sentence programmers to forever thinking "which way is it this time". To avoid such confusion an obviously different syntax is required.
Jul 06 2009
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:h2u735$sn8$1 digitalmars.com...
 grauzone wrote:
 I oriented this on the syntax of array slices. Which work that way. Not 
 inconsistent at all. It's also consistent with foreach(_; x..y).

It would look consistent, but it would behave very differently. x..y for foreach and slices is exclusive of the y, while case x..y is inclusive.

The current way has that inconsistency: variable .. variable // exclusive end caseLabel .. caseLabel // inclusive end And yes, I know that's not how it's actually parsed, but that's how people visually parse it. Ah the hell with it, I don't care any more: The *real* issue here is that the current switch, being based on C's, is horribly antiquated and what we really need is a comprehensive redesign incorporating some sort of generalized pattern matching. Like "case > 1, <= 10:" or something like Nemerle, or whatever. I don't care, as long as it doesn't continue to get trivialized as something that can be solved by tossing in a recycled ".." here, a recycled "final" there, etc.
Jul 06 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Nick Sabalausky wrote:
 "Walter Bright" <newshound1 digitalmars.com> wrote in message 
 news:h2u735$sn8$1 digitalmars.com...
 grauzone wrote:
 I oriented this on the syntax of array slices. Which work that way. Not 
 inconsistent at all. It's also consistent with foreach(_; x..y).

foreach and slices is exclusive of the y, while case x..y is inclusive.

The current way has that inconsistency: variable .. variable // exclusive end caseLabel .. caseLabel // inclusive end And yes, I know that's not how it's actually parsed, but that's how people visually parse it.

I don't think so at all. There's a lot of punctuation that has different roles depending on the context. For example, ":" means key/value separator or ternary operator participant; "*" means multiplication or pointer dereference; "&" means taking address or binary "and"... plenty of examples. So you can't center on ".." and claim that it visually means the same thing even though the surrounding is different. You really have no argument here.
 Ah the hell with it, I don't care any more: The *real* issue here is that 
 the current switch, being based on C's, is horribly antiquated and what we 
 really need is a comprehensive redesign incorporating some sort of 
 generalized pattern matching. Like "case > 1, <= 10:" or something like 
 Nemerle, or whatever. I don't care, as long as it doesn't continue to get 
 trivialized as something that can be solved by tossing in a recycled ".." 
 here, a recycled "final" there, etc. 

On the full side of the glass, with the latest dmd release, the language has acquired some useful feature improvements and the implementation has fixed many bugs. Why the crankiness? Andrei
Jul 06 2009
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:h2udmf$1b0c$1 digitalmars.com...
 Nick Sabalausky wrote:
 "Walter Bright" <newshound1 digitalmars.com> wrote in message 
 news:h2u735$sn8$1 digitalmars.com...
 grauzone wrote:
 I oriented this on the syntax of array slices. Which work that way. Not 
 inconsistent at all. It's also consistent with foreach(_; x..y).

foreach and slices is exclusive of the y, while case x..y is inclusive.

The current way has that inconsistency: variable .. variable // exclusive end caseLabel .. caseLabel // inclusive end And yes, I know that's not how it's actually parsed, but that's how people visually parse it.

I don't think so at all. There's a lot of punctuation that has different roles depending on the context. For example, ":" means key/value separator or ternary operator participant; "*" means multiplication or pointer dereference; "&" means taking address or binary "and"... plenty of examples. So you can't center on ".." and claim that it visually means the same thing even though the surrounding is different. You really have no argument here.

Those examples are all cases where the meaning and context are wildly different fbetween one use and the other. But with '..', both uses are very similar: "From xxx to (incl/excl) yyy". Big differences are ok, they stand out as obvious. Small differences can be more problematic. FWIW, Even though I dislike it, I don't think it's a sky-falling issue or anything. I just don't think it's so "obviously great" as you and Walter see it. Basically, I see it as a questionable *but* acceptable solution *provided that* it's just a stop-gap in the interim before finally getting a completely re-thought switch/pattern-matcher.
 Ah the hell with it, I don't care any more: The *real* issue here is that 
 the current switch, being based on C's, is horribly antiquated and what 
 we really need is a comprehensive redesign incorporating some sort of 
 generalized pattern matching. Like "case > 1, <= 10:" or something like 
 Nemerle, or whatever. I don't care, as long as it doesn't continue to get 
 trivialized as something that can be solved by tossing in a recycled ".." 
 here, a recycled "final" there, etc.

On the full side of the glass, with the latest dmd release, the language has acquired some useful feature improvements and the implementation has fixed many bugs. Why the crankiness?

Because it's really hot in this room right now... ;) But seriously though, it's just this issue I'm cranky about. I can absolutely agree there's been a lot of good changes. (Although I would really love to see my patch for #2567 incorporated...*squeak**squeak* says the wheel ;) )
Jul 06 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Nick Sabalausky wrote:
 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
 news:h2udmf$1b0c$1 digitalmars.com...
 Nick Sabalausky wrote:
 "Walter Bright" <newshound1 digitalmars.com> wrote in message 
 news:h2u735$sn8$1 digitalmars.com...
 grauzone wrote:
 I oriented this on the syntax of array slices. Which work that way. Not 
 inconsistent at all. It's also consistent with foreach(_; x..y).

foreach and slices is exclusive of the y, while case x..y is inclusive.

variable .. variable // exclusive end caseLabel .. caseLabel // inclusive end And yes, I know that's not how it's actually parsed, but that's how people visually parse it.

roles depending on the context. For example, ":" means key/value separator or ternary operator participant; "*" means multiplication or pointer dereference; "&" means taking address or binary "and"... plenty of examples. So you can't center on ".." and claim that it visually means the same thing even though the surrounding is different. You really have no argument here.

Those examples are all cases where the meaning and context are wildly different fbetween one use and the other. But with '..', both uses are very similar: "From xxx to (incl/excl) yyy". Big differences are ok, they stand out as obvious. Small differences can be more problematic.

You'd have an uphill battle using a counterfeit Swiss army knife against a battery of Gatling guns arguing that case 'a': .. case 'z': is very similar with 0 .. 10 That's actually much more different than e.g. a = b * c; versus b * c;
 FWIW, Even though I dislike it, I don't think it's a sky-falling issue or 
 anything. I just don't think it's so "obviously great" as you and Walter see 
 it.

I'm not claiming it's obviously great. I do claim it's highly appropriate.
 Basically, I see it as a questionable *but* acceptable solution 
 *provided that* it's just a stop-gap in the interim before finally getting a 
 completely re-thought switch/pattern-matcher.

What is the question you are asking in the "questionable" part? Andrei
Jul 06 2009
parent Michel Fortin <michel.fortin michelf.com> writes:
On 2009-07-07 01:12:12 -0400, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> said:

 Nick Sabalausky wrote:
 Those examples are all cases where the meaning and context are wildly 
 different fbetween one use and the other. But with '..', both uses are 
 very similar: "From xxx to (incl/excl) yyy". Big differences are ok, 
 they stand out as obvious. Small differences can be more problematic.

You'd have an uphill battle using a counterfeit Swiss army knife against a battery of Gatling guns

 arguing that
 
 case 'a': .. case 'z':
 
 is very similar with
 
 0 .. 10
 
 That's actually much more different than e.g.
 
 a = b * c;
 
 versus
 
 b * c;

They aren't so much different if you consider "case 'a':" and "case 'z':" as two items joined by a "..", which I believe is the expected way to read it. In the first case "case 'a':" and "case 'z':" joined by a ".." means an inclusive range, in the second case "0" and "10" joined by a ".." means an exclusive one. With "b * c", the meaning is completly different depending on whether b is a type or not. If "b" is a type, you can't reasonabily expect "b * c" to do a multiplication and you'll get an error about it if that's what you're trying to do. Wheras with "case 'a': .. case 'b':" you can reasonably expect an exclusive range if you aren't too familiar with the syntax (and that's a resonable expectation if you know about ranges), and you won't get an error of you mix things up; thus, clarity of the syntax becomes more important. I still think that having that syntax is better than nothing, but I do believe it's an inconsistency and that it may looks ambiguous to someone unfamiliar with it. But my worse grief about that new feature is the restriction about 256 values which is pretty limitating if you're writing a parser dealing with ranges of unicode characters. I guess I'll have to continue using ifs for that. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Jul 07 2009
prev sibling parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 06 Jul 2009 21:59:54 -0500, Andrei Alexandrescu wrote:

 There's a lot of punctuation that has different 
 roles depending on the context. 

Agreed. No argument here. The meaning of punctuation depends on its context. Got it. However, that aside, the syntax you have chosen will have a rational explanation for its superiority. So can you explain in simple terms why CaseLabelInt .. CaseLabelInt eg. case 1: .. case 9: is superior than case CaseRange: eg. case 1 .. 9: given that CaseLabelInt ==> case IntegerExpression : CaseRange ==> IntegerExpression .. IntegerExpression
 On the full side of the glass, with the latest dmd release, the language 
 has acquired some useful feature improvements and the implementation has 
 fixed many bugs.

Yes it truly has, and thank you very much to all contributors.
 Why the crankiness?

Because it is so demoralizing to point out 'warts' in D/DMD and be subsequently dismissed as ungrateful plebeians who are wasting the time of the patricians. Sorry, but you did ask. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Jul 06 2009
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Derek Parnell wrote:
 However, that aside, the syntax you have chosen will have a rational
 explanation for its superiority. So can you explain in simple terms why 
 
     CaseLabelInt .. CaseLabelInt  eg. case 1: .. case 9:
 
 is superior than
 
     case CaseRange:  eg. case 1 .. 9:
 
 given that
   CaseLabelInt ==> case IntegerExpression :
   CaseRange    ==> IntegerExpression .. IntegerExpression

Because 1. case X..Y: looks like 2. foreach(e; X..Y) 3. array[X..Y] yet the X..Y has a VERY DIFFERENT meaning. (1) is inclusive of Y, and (2) and (3) are exclusive of Y. Having a very different meaning means it should have a distinctly different syntax.
Jul 06 2009
parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 06 Jul 2009 21:29:43 -0700, Walter Bright wrote:

 Derek Parnell wrote:
 However, that aside, the syntax you have chosen will have a rational
 explanation for its superiority. So can you explain in simple terms why 
 
     CaseLabelInt .. CaseLabelInt  eg. case 1: .. case 9:
 
 is superior than
 
     case CaseRange:  eg. case 1 .. 9:
 
 given that
   CaseLabelInt ==> case IntegerExpression :
   CaseRange    ==> IntegerExpression .. IntegerExpression

Because 1. case X..Y: looks like 2. foreach(e; X..Y) 3. array[X..Y] yet the X..Y has a VERY DIFFERENT meaning. (1) is inclusive of Y, and (2) and (3) are exclusive of Y. Having a very different meaning means it should have a distinctly different syntax.

Thank you, but now I am confused ... Andrei just got through lecturing us that the meaning of punctuation is dependant upon context. So I think your example must be more like ... Because 1. case X..Y: looks like 2. foreach(e; X..Y) 3. array[X..Y] 4. case X:..caseY: yet the X..Y has a VERY DIFFERENT meaning. (1) is inclusive of Y, and (2) and (3) are exclusive of Y, and (4) is inclusive of Y ... oh, hang on... Sorry, but I'm just not getting the "VERY DIFFERENT" part yet. Right now, D has ".." meaning exclude-end value (2. and 3.) AND it also has ".." meaning include-end value (4.), depending on context. Ok, I admit that there is one subtle difference. Examples 2 and 3 are of the form IntExpression .. IntExpression and example 4 is CaseLabelInt .. CaseLabelInt but seriously, people are not going to notice that. We see double-dot and think "range". I know that this is not ever going to be changed so I'm not arguing that it should. (One of the most frequent bugs I have in my D programs is that I forget that X..Y excludes Y because it's not natural to me to see text that looks like "the range X to Y" but means "the range X to Y-1".) It seems that D would benefit from having a standard syntax format for expressing various range sets; a. Include begin Include end, i.e. [] b. Include begin Exclude end, i.e. [) c. Exclude begin Include end, i.e. (] d. Exclude begin Exclude end, i.e. () -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Jul 06 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Derek Parnell wrote:
  Because
  
  1.	case X..Y:
  
  looks like
  
  2.	foreach(e; X..Y)
  3.	array[X..Y]
  4.     case X:..caseY:
 
 
  yet the X..Y has a VERY DIFFERENT meaning. (1) is inclusive of Y, and 
  (2) and (3) are exclusive of Y, and (4) is inclusive of Y ... oh, hang
 on...
 
 Sorry, but I'm just not getting the "VERY DIFFERENT" part yet. Right now, D
 has ".." meaning exclude-end value (2. and 3.) AND it also has ".." meaning
 include-end value (4.), depending on context. 

I think here's the point where our thinking diverges. You say ".." has a meaning. No. It does not have any meaning. It's punctuation. Same way, "*", "&", ":", ",", etc. have no meaning in D all alone. They are tokens. They acquire a meaning by partaking in grammatical constructs. What does have arguably a meaning is "expression1 .. expression2". (Even that could be debatable because it's not a standalone expression). But anyway, the meaning that "expression1 .. expression2" acquires in array slices and foreach statements is uniform. Now we have the different construct "case expression1: .. case expression2:" That is evidently not "expression1 .. expression2", does not include it as a part, and shares essentially nothing except the ".." with it. That's my point.
 Ok, I admit that there is one subtle difference. Examples 2 and 3 are of
 the form 
 
   IntExpression .. IntExpression
 
 and example 4 is 
 
   CaseLabelInt .. CaseLabelInt
 
 but seriously, people are not going to notice that. We see double-dot and
 think "range". 

You should see "expression1 .. expression2" and think "range". There's very few tokens that make one think of only one thing when seeing them. One of them is "%" - makes one think of modulus, another is "^" meaning xor, another is "$" - array size... but that's about it.
 I know that this is not ever going to be changed so I'm not arguing that it
 should. 
 
 (One of the most frequent bugs I have in my D programs is that I forget
 that X..Y excludes Y because it's not natural to me to see text that looks
 like "the range X to Y" but means "the range X to Y-1".)
 
 It seems that D would benefit from having a standard syntax format for
 expressing various range sets;
  a. Include begin Include end, i.e. []
  b. Include begin Exclude end, i.e. [)
  c. Exclude begin Include end, i.e. (]
  d. Exclude begin Exclude end, i.e. ()

I'm afraid this would majorly mess with pairing of parens. Andrei
Jul 06 2009
parent reply =?ISO-8859-1?Q?=22J=E9r=F4me_M=2E_Berger=22?= <jeberger free.fr> writes:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Andrei Alexandrescu wrote:
 Derek Parnell wrote:
 It seems that D would benefit from having a standard syntax format for=


 expressing various range sets;
  a. Include begin Include end, i.e. []
  b. Include begin Exclude end, i.e. [)
  c. Exclude begin Include end, i.e. (]
  d. Exclude begin Exclude end, i.e. ()

I'm afraid this would majorly mess with pairing of parens. =20

necessarily the one he showed (which he showed because I believe=20 that's the "standard" mathematical way to express it for English=20 speakers). For example, we could say that [] is always inclusive and=20 have another character which makes it exclusive like: a. Include begin Include end, i.e. [ a .. b ] b. Include begin Exclude end, i.e. [ a .. b ^] c. Exclude begin Include end, i.e. [^ a .. b ] d. Exclude begin Exclude end, i.e. [^ a .. b ^] Jerome PS: If you *really* want messed parens pairing, try it with the=20 French convention: [] [[ ]] ][ ;) --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Jul 07 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Jrme M. Berger wrote:
 Andrei Alexandrescu wrote:
 Derek Parnell wrote:
 It seems that D would benefit from having a standard syntax format for
 expressing various range sets;
  a. Include begin Include end, i.e. []
  b. Include begin Exclude end, i.e. [)
  c. Exclude begin Include end, i.e. (]
  d. Exclude begin Exclude end, i.e. ()

I'm afraid this would majorly mess with pairing of parens.

necessarily the one he showed (which he showed because I believe that's the "standard" mathematical way to express it for English speakers). For example, we could say that [] is always inclusive and have another character which makes it exclusive like: a. Include begin Include end, i.e. [ a .. b ] b. Include begin Exclude end, i.e. [ a .. b ^] c. Exclude begin Include end, i.e. [^ a .. b ] d. Exclude begin Exclude end, i.e. [^ a .. b ^]

I think Walter's message really rendered the whole discussion moot. Post of the year: ========================= I like: a .. b+1 to mean inclusive range. ========================= Consider "+1]" a special symbol that means the range is to be closed to the right :o). Andrei
Jul 07 2009
next sibling parent reply =?ISO-8859-1?Q?=22J=E9r=F4me_M=2E_Berger=22?= <jeberger free.fr> writes:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Andrei Alexandrescu wrote:
 J=E9r=F4me M. Berger wrote:
 Andrei Alexandrescu wrote:
 Derek Parnell wrote:
 It seems that D would benefit from having a standard syntax format f=




 expressing various range sets;
  a. Include begin Include end, i.e. []
  b. Include begin Exclude end, i.e. [)
  c. Exclude begin Include end, i.e. (]
  d. Exclude begin Exclude end, i.e. ()

I'm afraid this would majorly mess with pairing of parens.



 necessarily the one he showed (which he showed because I believe=20
 that's the "standard" mathematical way to express it for English=20
 speakers). For example, we could say that [] is always inclusive and=20
 have another character which makes it exclusive like:
  a. Include begin Include end, i.e. [  a .. b  ]
  b. Include begin Exclude end, i.e. [  a .. b ^]
  c. Exclude begin Include end, i.e. [^ a .. b  ]
  d. Exclude begin Exclude end, i.e. [^ a .. b ^]

I think Walter's message really rendered the whole discussion moot. Pos=

 of the year:
=20
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

 I like:
=20
    a .. b+1
=20
 to mean inclusive range.
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

=20
 Consider "+1]" a special symbol that means the range is to be closed to=

 the right :o).
=20

- This is inconsistent between the left and right limit; - This only works for integers, not for floating point numbers. Jerome --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Jul 07 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Jrme M. Berger wrote:
 Andrei Alexandrescu wrote:
 Jrme M. Berger wrote:
 Andrei Alexandrescu wrote:
 Derek Parnell wrote:
 It seems that D would benefit from having a standard syntax format for
 expressing various range sets;
  a. Include begin Include end, i.e. []
  b. Include begin Exclude end, i.e. [)
  c. Exclude begin Include end, i.e. (]
  d. Exclude begin Exclude end, i.e. ()

I'm afraid this would majorly mess with pairing of parens.

necessarily the one he showed (which he showed because I believe that's the "standard" mathematical way to express it for English speakers). For example, we could say that [] is always inclusive and have another character which makes it exclusive like: a. Include begin Include end, i.e. [ a .. b ] b. Include begin Exclude end, i.e. [ a .. b ^] c. Exclude begin Include end, i.e. [^ a .. b ] d. Exclude begin Exclude end, i.e. [^ a .. b ^]

I think Walter's message really rendered the whole discussion moot. Post of the year: ========================= I like: a .. b+1 to mean inclusive range. ========================= Consider "+1]" a special symbol that means the range is to be closed to the right :o).

- This is inconsistent between the left and right limit; - This only works for integers, not for floating point numbers.

How does it not work for floating point numbers? Andrei
Jul 07 2009
parent reply =?ISO-8859-1?Q?=22J=E9r=F4me_M=2E_Berger=22?= <jeberger free.fr> writes:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Andrei Alexandrescu wrote:
 J=E9r=F4me M. Berger wrote:
 Andrei Alexandrescu wrote:
 J=E9r=F4me M. Berger wrote:
 Andrei Alexandrescu wrote:
 Derek Parnell wrote:
 It seems that D would benefit from having a standard syntax format=






 for
 expressing various range sets;
  a. Include begin Include end, i.e. []
  b. Include begin Exclude end, i.e. [)
  c. Exclude begin Include end, i.e. (]
  d. Exclude begin Exclude end, i.e. ()

I'm afraid this would majorly mess with pairing of parens.

not necessarily the one he showed (which he showed because I believe=




 that's the "standard" mathematical way to express it for English=20
 speakers). For example, we could say that [] is always inclusive and=




 have another character which makes it exclusive like:
  a. Include begin Include end, i.e. [  a .. b  ]
  b. Include begin Exclude end, i.e. [  a .. b ^]
  c. Exclude begin Include end, i.e. [^ a .. b  ]
  d. Exclude begin Exclude end, i.e. [^ a .. b ^]

I think Walter's message really rendered the whole discussion moot.=20 Post of the year: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=



 I like:

    a .. b+1

 to mean inclusive range.
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=



 Consider "+1]" a special symbol that means the range is to be closed =



 to the right :o).

- This is inconsistent between the left and right limit; - This only works for integers, not for floating point numbers.

How does it not work for floating point numbers? =20

might have b+1 =3D=3D b (if b is large enough). Conversely, range a ..=20 b+1 may contain a lot of extra numbers I may not want to include=20 (like b+0.5)... Jerome --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Jul 07 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Jrme M. Berger wrote:
 Andrei Alexandrescu wrote:
 Jrme M. Berger wrote:
 Andrei Alexandrescu wrote:
 Jrme M. Berger wrote:
 Andrei Alexandrescu wrote:
 Derek Parnell wrote:
 It seems that D would benefit from having a standard syntax 
 format for
 expressing various range sets;
  a. Include begin Include end, i.e. []
  b. Include begin Exclude end, i.e. [)
  c. Exclude begin Include end, i.e. (]
  d. Exclude begin Exclude end, i.e. ()

I'm afraid this would majorly mess with pairing of parens.

not necessarily the one he showed (which he showed because I believe that's the "standard" mathematical way to express it for English speakers). For example, we could say that [] is always inclusive and have another character which makes it exclusive like: a. Include begin Include end, i.e. [ a .. b ] b. Include begin Exclude end, i.e. [ a .. b ^] c. Exclude begin Include end, i.e. [^ a .. b ] d. Exclude begin Exclude end, i.e. [^ a .. b ^]

I think Walter's message really rendered the whole discussion moot. Post of the year: ========================= I like: a .. b+1 to mean inclusive range. ========================= Consider "+1]" a special symbol that means the range is to be closed to the right :o).

- This is inconsistent between the left and right limit; - This only works for integers, not for floating point numbers.

How does it not work for floating point numbers?

might have b+1 == b (if b is large enough). Conversely, range a .. b+1 may contain a lot of extra numbers I may not want to include (like b+0.5)...

It wasn't a trick question, or it was of sorts. If you iterate with e.g. foreach through a floating-point range that has b == b + 1, you're bound to get in a lot of trouble because the running variable will be incremented. Andrei
Jul 07 2009
parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Andrei Alexandrescu wrote:
 J=C3=A9r=C3=B4me M. Berger wrote:
 Andrei Alexandrescu wrote:
 J=C3=A9r=C3=B4me M. Berger wrote:
 Andrei Alexandrescu wrote:
 J=C3=A9r=C3=B4me M. Berger wrote:
 Andrei Alexandrescu wrote:
 Derek Parnell wrote:
 It seems that D would benefit from having a standard syntax=20
 format for
 expressing various range sets;
  a. Include begin Include end, i.e. []
  b. Include begin Exclude end, i.e. [)
  c. Exclude begin Include end, i.e. (]
  d. Exclude begin Exclude end, i.e. ()

I'm afraid this would majorly mess with pairing of parens.







 not necessarily the one he showed (which he showed because I=20
 believe that's the "standard" mathematical way to express it for=20
 English speakers). For example, we could say that [] is always=20
 inclusive and have another character which makes it exclusive like=






  a. Include begin Include end, i.e. [  a .. b  ]
  b. Include begin Exclude end, i.e. [  a .. b ^]
  c. Exclude begin Include end, i.e. [^ a .. b  ]
  d. Exclude begin Exclude end, i.e. [^ a .. b ^]

I think Walter's message really rendered the whole discussion moot.=





 Post of the year:

 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=





 I like:

    a .. b+1

 to mean inclusive range.
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=





 Consider "+1]" a special symbol that means the range is to be=20
 closed to the right :o).

- This is inconsistent between the left and right limit; - This only works for integers, not for floating point numbers.

How does it not work for floating point numbers?



 might have b+1 =3D=3D b (if b is large enough). Conversely, range a ..=


 may contain a lot of extra numbers I may not want to include (like=20
 b+0.5)...

It wasn't a trick question, or it was of sorts. If you iterate with e.g=

 foreach through a floating-point range that has b =3D=3D b + 1, you're =

 to get in a lot of trouble because the running variable will be=20
 incremented.
=20

- A floating point range should allow you to specify the iteration=20 step, or else it should allow you to iterate through all numbers=20 that can be represented with the corresponding precision; - The second issue remains: what if I want to include b but not=20 b+=CE=B5 for any =CE=B5>0? Jerome --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Jul 07 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Jérôme M. Berger wrote:
  - A floating point range should allow you to specify the iteration 
 step, or else it should allow you to iterate through all numbers that 
 can be represented with the corresponding precision;

We don't have that, so you'd need to use a straigh for statement.
  - The second issue remains: what if I want to include b but not b+ε for 
 any ε>0?

real a, b; ... for (real f = a; f <= b; update(f)) { } I'd find it questionable to use ranged for with floats anyway. Andrei
Jul 07 2009
parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Andrei Alexandrescu wrote:
 J=C3=A9r=C3=B4me M. Berger wrote:
  - A floating point range should allow you to specify the iteration=20
 step, or else it should allow you to iterate through all numbers that =


 can be represented with the corresponding precision;

We don't have that, so you'd need to use a straigh for statement. =20

struct FloatRange { float begin, end, step; bool includeBegin, includeEnd; int opApply (int delegate (ref float) dg) { whatever; } whatever; }
  - The second issue remains: what if I want to include b but not b+=CE=


 for any =CE=B5>0?

real a, b; ... for (real f =3D a; f <=3D b; update(f)) { } =20 I'd find it questionable to use ranged for with floats anyway. =20

over it. Think interval arithmetic for example. Jerome --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Jul 07 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Jérôme M. Berger wrote:
 Andrei Alexandrescu wrote:
 Jérôme M. Berger wrote:
  - A floating point range should allow you to specify the iteration 
 step, or else it should allow you to iterate through all numbers that 
 can be represented with the corresponding precision;

We don't have that, so you'd need to use a straigh for statement.

struct FloatRange { float begin, end, step; bool includeBegin, includeEnd; int opApply (int delegate (ref float) dg) { whatever; } whatever; }
  - The second issue remains: what if I want to include b but not b+ε 
 for any ε>0?

real a, b; ... for (real f = a; f <= b; update(f)) { } I'd find it questionable to use ranged for with floats anyway.

over it. Think interval arithmetic for example.

Cool. I'm positive that open ranges will not prevent you from implementing such a library (and from subsequently proposing it to Phobos :o)). Andrei
Jul 07 2009
prev sibling parent Charles Hixson <charleshixsn earthlink.net> writes:
Jérôme M. Berger wrote:
 Andrei Alexandrescu wrote:
 Jérôme M. Berger wrote:
 Andrei Alexandrescu wrote:
 Jérôme M. Berger wrote:
 Andrei Alexandrescu wrote:
 Jérôme M. Berger wrote:
 Andrei Alexandrescu wrote:
 Derek Parnell wrote:
 It seems that D would benefit from having a standard syntax 
 format for
 expressing various range sets;
  a. Include begin Include end, i.e. []
  b. Include begin Exclude end, i.e. [)
  c. Exclude begin Include end, i.e. (]
  d. Exclude begin Exclude end, i.e. ()

I'm afraid this would majorly mess with pairing of parens.

not necessarily the one he showed (which he showed because I believe that's the "standard" mathematical way to express it for English speakers). For example, we could say that [] is always inclusive and have another character which makes it exclusive like: a. Include begin Include end, i.e. [ a .. b ] b. Include begin Exclude end, i.e. [ a .. b ^] c. Exclude begin Include end, i.e. [^ a .. b ] d. Exclude begin Exclude end, i.e. [^ a .. b ^]

I think Walter's message really rendered the whole discussion moot. Post of the year: ========================= I like: a .. b+1 to mean inclusive range. ========================= Consider "+1]" a special symbol that means the range is to be closed to the right :o).

- This is inconsistent between the left and right limit; - This only works for integers, not for floating point numbers.

How does it not work for floating point numbers?

might have b+1 == b (if b is large enough). Conversely, range a .. b+1 may contain a lot of extra numbers I may not want to include (like b+0.5)...

It wasn't a trick question, or it was of sorts. If you iterate with e.g. foreach through a floating-point range that has b == b + 1, you're bound to get in a lot of trouble because the running variable will be incremented.

- A floating point range should allow you to specify the iteration step, or else it should allow you to iterate through all numbers that can be represented with the corresponding precision; - The second issue remains: what if I want to include b but not b+ε for any ε>0? Jerome

should only get evaluated on an as-needed basis. But clearly open, half-open, and closed intervals aren't the same kind of thing as ranges. They are more frequently used for making assertions about when something is true (or false). I.e., they're used as an integral part of standard mathematics, but not at all in computer science (except in VERY peculiar cases). In math one makes a assertion that, say, a particular equation holds for all members of an interval, and open or closed is only a statement about whether the end-points are included in the interval. Proof isn't usually be exhaustive calculation, but rather by more abstract reasoning. It would be nice to be able to express mathematical reasoning as parts of a computer program, but it's not something that's likely to be efficiently implementable, and certainly not executable. Mathematica can do that kind of thing, I believe, but it's a bit distant from a normal computer language.
Jul 08 2009
prev sibling parent Derek Parnell <derek psych.ward> writes:
On Tue, 07 Jul 2009 21:20:42 +0200, "Jérôme M. Berger" wrote:

 Andrei Alexandrescu wrote:
 Jérôme M. Berger wrote:
 Andrei Alexandrescu wrote:
 Jérôme M. Berger wrote:
 Andrei Alexandrescu wrote:
 Derek Parnell wrote:
 It seems that D would benefit from having a standard syntax format 
 for
 expressing various range sets;
  a. Include begin Include end, i.e. []
  b. Include begin Exclude end, i.e. [)
  c. Exclude begin Include end, i.e. (]
  d. Exclude begin Exclude end, i.e. ()

I'm afraid this would majorly mess with pairing of parens.

not necessarily the one he showed (which he showed because I believe that's the "standard" mathematical way to express it for English speakers). For example, we could say that [] is always inclusive and have another character which makes it exclusive like: a. Include begin Include end, i.e. [ a .. b ] b. Include begin Exclude end, i.e. [ a .. b ^] c. Exclude begin Include end, i.e. [^ a .. b ] d. Exclude begin Exclude end, i.e. [^ a .. b ^]

I think Walter's message really rendered the whole discussion moot. Post of the year: ========================= I like: a .. b+1 to mean inclusive range. ========================= Consider "+1]" a special symbol that means the range is to be closed to the right :o).

- This is inconsistent between the left and right limit; - This only works for integers, not for floating point numbers.

How does it not work for floating point numbers?

might have b+1 == b (if b is large enough). Conversely, range a .. b+1 may contain a lot of extra numbers I may not want to include (like b+0.5)... Jerome

If Andrei is not joking (the smiley notwithstanding) the "+1" doesn't mean add one to the previous expression, instead it means that the previous expression's value is the last value in the range set. Subtle, no? -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Jul 07 2009
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:
 I think Walter's message really rendered the whole discussion moot. Post 
 of the year:
 =========================
 I like:
     a .. b+1
 to mean inclusive range.

That was my preferred solution, starting from months ago. Bye, bearophile
Jul 07 2009
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:
 2009/7/7 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>:
 I think Walter's message really rendered the whole discussion moot. Post of
 the year:

 =========================
 I like:

   a .. b+1

 to mean inclusive range.
 =========================

Not everything is an integer.

Works with pointers too. Andrei
Jul 07 2009
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Andrei Alexandrescu wrote:
 Bill Baxter wrote:
 2009/7/7 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>:
 I think Walter's message really rendered the whole discussion moot. 
 Post of
 the year:

 =========================
 I like:

   a .. b+1

 to mean inclusive range.
 =========================

Not everything is an integer.

Works with pointers too.

It works for the cases where an inclusive range makes sense.
Jul 07 2009
parent =?ISO-8859-1?Q?=22J=E9r=F4me_M=2E_Berger=22?= <jeberger free.fr> writes:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Walter Bright wrote:
 Andrei Alexandrescu wrote:
 Bill Baxter wrote:
 2009/7/7 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>:
 I think Walter's message really rendered the whole discussion moot. =




 Post of
 the year:

 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=




 I like:

   a .. b+1

 to mean inclusive range.
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=




 Not everything is an integer.

Works with pointers too.

It works for the cases where an inclusive range makes sense.

Doesn't work with floats, which *do* make sense too... Jerome --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Jul 07 2009
prev sibling parent Derek Parnell <derek psych.ward> writes:
On Tue, 07 Jul 2009 14:16:12 -0500, Andrei Alexandrescu wrote:

 Bill Baxter wrote:
 2009/7/7 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>:
 I think Walter's message really rendered the whole discussion moot. Post of
 the year:

 =========================
 I like:

   a .. b+1

 to mean inclusive range.
 =========================

Not everything is an integer.

Works with pointers too.

A pointer is an integer because the byte it is referring to always has an integral address value. Pointers do not point to partial bytes. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Jul 07 2009
prev sibling parent reply Leandro Lucarella <llucax gmail.com> writes:
Andrei Alexandrescu, el  7 de julio a las 13:18 me escribiste:
 Jérôme M. Berger wrote:
Andrei Alexandrescu wrote:
Derek Parnell wrote:
It seems that D would benefit from having a standard syntax format for
expressing various range sets;
 a. Include begin Include end, i.e. []
 b. Include begin Exclude end, i.e. [)
 c. Exclude begin Include end, i.e. (]
 d. Exclude begin Exclude end, i.e. ()

I'm afraid this would majorly mess with pairing of parens.

necessarily the one he showed (which he showed because I believe that's the "standard" mathematical way to express it for English speakers). For example, we could say that [] is always inclusive and have another character which makes it exclusive like: a. Include begin Include end, i.e. [ a .. b ] b. Include begin Exclude end, i.e. [ a .. b ^] c. Exclude begin Include end, i.e. [^ a .. b ] d. Exclude begin Exclude end, i.e. [^ a .. b ^]

I think Walter's message really rendered the whole discussion moot. Post of the year: ========================= I like: a .. b+1 to mean inclusive range. ========================= Consider "+1]" a special symbol that means the range is to be closed to the right :o).

What about bearophile response: what about x..uint.max+1? -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- More than 50% of the people in the world have never made Or received a telephone call
Jul 07 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Leandro Lucarella wrote:
 Andrei Alexandrescu, el  7 de julio a las 13:18 me escribiste:
 Jérôme M. Berger wrote:
 Andrei Alexandrescu wrote:
 Derek Parnell wrote:
 It seems that D would benefit from having a standard syntax format for
 expressing various range sets;
 a. Include begin Include end, i.e. []
 b. Include begin Exclude end, i.e. [)
 c. Exclude begin Include end, i.e. (]
 d. Exclude begin Exclude end, i.e. ()


necessarily the one he showed (which he showed because I believe that's the "standard" mathematical way to express it for English speakers). For example, we could say that [] is always inclusive and have another character which makes it exclusive like: a. Include begin Include end, i.e. [ a .. b ] b. Include begin Exclude end, i.e. [ a .. b ^] c. Exclude begin Include end, i.e. [^ a .. b ] d. Exclude begin Exclude end, i.e. [^ a .. b ^]

year: ========================= I like: a .. b+1 to mean inclusive range. ========================= Consider "+1]" a special symbol that means the range is to be closed to the right :o).

What about bearophile response: what about x..uint.max+1?

How often did you encounter that issue? Andrei
Jul 07 2009
parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:
 How often did you encounter that issue?

Please, let's be serious, and let's stop adding special cases to D, or they will kill the language. Lately I have seen too many special cases. For example the current design of the rules of integral seems bad. It has bugs and special cases from the start. The .. used in case is another special case, even if Andrei is blind regarding that, and doesn't see its problem. Why for a change people here stop implementing things, and start implementing a feature only after 55-60+% of the people think it's a good idea? Languages like C# and Scala show several features good to be copied, let's copy them, and let's not add any more half-backed things. Before adding a feature X let's discuss them, let's create a forum or place to keep a thred for each feature plus a wiki-based text of the best solution found, etc. If not enough people like a solution then let's not add it. Better not having a feature than having a bad one, see Python that even today misses basic things like a switch/case. Bye, bearophile
Jul 07 2009
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
bearophile wrote:
 Andrei Alexandrescu:
 How often did you encounter that issue?

Please, let's be serious, and let's stop adding special cases to D, or they will kill the language.

Don't get me going about what could kill the language.
 Lately I have seen too many special
 cases. For example the current design of the rules of integral seems
 bad. It has bugs and special cases from the start.

Bugs don't imply that the feature is bad. The special cases are well understood and are present in all of C, C++, C#, and Java. Value range propagation as defined in D is principled and puts D on the right side of both safety and speed. It's better than all other languages mentioned above: safer than C and C++, and requiring much fewer casts than C# and Java. Andrei
Jul 07 2009
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"bearophile" <bearophileHUGS lycos.com> wrote in message 
news:h3093m$2mu6$1 digitalmars.com...
 Before adding a feature X let's discuss them, ... If not enough people 
 like a solution then let's not add it.

Something like that was attempted once before. Andrei didn't like what we had to say, got huffy, and withdrew from the discussion. Stay tuned for the exciting sequel where the feature goes ahead as planned anyway, and our protagonists get annoyed that people still have objections to it.
Jul 07 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Nick Sabalausky wrote:
 "bearophile" <bearophileHUGS lycos.com> wrote in message 
 news:h3093m$2mu6$1 digitalmars.com...
 Before adding a feature X let's discuss them, ... If not enough people 
 like a solution then let's not add it.

Something like that was attempted once before. Andrei didn't like what we had to say, got huffy, and withdrew from the discussion. Stay tuned for the exciting sequel where the feature goes ahead as planned anyway, and our protagonists get annoyed that people still have objections to it.

Put yourself in my place. What would you do? Honest. Sometimes I find it difficult to find the right mix of being honest, being technically accurate, being polite, and not wasting too much time explaining myself. Andrei
Jul 07 2009
parent Derek Parnell <derek psych.ward> writes:
On Tue, 07 Jul 2009 19:39:55 -0500, Andrei Alexandrescu wrote:

 Nick Sabalausky wrote:
 "bearophile" <bearophileHUGS lycos.com> wrote in message 
 news:h3093m$2mu6$1 digitalmars.com...
 Before adding a feature X let's discuss them, ... If not enough people 
 like a solution then let's not add it.

Something like that was attempted once before. Andrei didn't like what we had to say, got huffy, and withdrew from the discussion. Stay tuned for the exciting sequel where the feature goes ahead as planned anyway, and our protagonists get annoyed that people still have objections to it.

Put yourself in my place. What would you do? Honest. Sometimes I find it difficult to find the right mix of being honest, being technically accurate, being polite, and not wasting too much time explaining myself. Andrei

Ditto. We know that the development of the D language is not a democratic process, and that's fine. Really, it is. However, clear rationale for decisions made would go a long way to helping reduce dissent, as would some pre-announcements to avoid surprises. By the way, I appreciate that you guys are now closing off bugzilla issues before the release of their fix implementation. It a good heads-up and demonstrates activity in between releases. Well done. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Jul 07 2009
prev sibling parent Derek Parnell <derek psych.ward> writes:
On Tue, 07 Jul 2009 20:13:45 +0200, "Jérôme M. Berger" wrote:

 Andrei Alexandrescu wrote:
 Derek Parnell wrote:
 It seems that D would benefit from having a standard syntax format for
 expressing various range sets;
  a. Include begin Include end, i.e. []
  b. Include begin Exclude end, i.e. [)
  c. Exclude begin Include end, i.e. (]
  d. Exclude begin Exclude end, i.e. ()

I'm afraid this would majorly mess with pairing of parens.

necessarily the one he showed

Thank you, Jérôme. I got too frustrated to explain it well enough. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Jul 07 2009
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Derek Parnell wrote:
 On Mon, 06 Jul 2009 21:59:54 -0500, Andrei Alexandrescu wrote:
 
 There's a lot of punctuation that has different 
 roles depending on the context. 

Agreed. No argument here. The meaning of punctuation depends on its context. Got it. However, that aside, the syntax you have chosen will have a rational explanation for its superiority. So can you explain in simple terms why CaseLabelInt .. CaseLabelInt eg. case 1: .. case 9: is superior than case CaseRange: eg. case 1 .. 9:

It is superior because case 1 .. 9: raises the question on whether 9 is included or not. Consistency with a[1 .. 9] and foreach (x; 1 .. 9) suggests that 9 should not be included, common usage of case statements suggests that 9 should be included.
 given that
   CaseLabelInt ==> case IntegerExpression :
   CaseRange    ==> IntegerExpression .. IntegerExpression

What's this?
 On the full side of the glass, with the latest dmd release, the language 
 has acquired some useful feature improvements and the implementation has 
 fixed many bugs.

Yes it truly has, and thank you very much to all contributors.
 Why the crankiness?

Because it is so demoralizing to point out 'warts' in D/DMD and be subsequently dismissed as ungrateful plebeians who are wasting the time of the patricians. Sorry, but you did ask.

I understand. Sorry about that. I am certain there's a misreading of attitude, though I clearly see how you could acquire that impression. Andrei
Jul 06 2009
prev sibling next sibling parent Bill Baxter <wbaxter gmail.com> writes:
2009/7/7 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>:
 I think Walter's message really rendered the whole discussion moot. Post =

 the year:

 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

 I like:

 =A0 a .. b+1

 to mean inclusive range.
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

Not everything is an integer. --bb
Jul 07 2009
prev sibling parent Charles Hixson <charleshixsn earthlink.net> writes:
Walter Bright wrote:
 grauzone wrote:
 I oriented this on the syntax of array slices. Which work that way. 
 Not inconsistent at all. It's also consistent with foreach(_; x..y).

It would look consistent, but it would behave very differently. x..y for foreach and slices is exclusive of the y, while case x..y is inclusive. Creating such an inconsistency would sentence programmers to forever thinking "which way is it this time". To avoid such confusion an obviously different syntax is required.

This isn't a matter that's very important to me, as I rarely use case statements, but the suggestion made elsewhere of allowing restricted pattern matching of some sort, or concatenated logical tests, is appealing. Being able to test for (e.g.) case (< 5 & > j): would be very appealing. (I read that as case less than 5 and greater than j.) OTOH, I'm not at all sure that such a thing could be implemented efficiently. The places that I've usually found such things were in languages interpreted at run time.
Jul 08 2009
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
grauzone wrote:
 You are just saying it's ugly. I don't think it's ugly. Walter doesn't 
 think it's ugly. Other people don't think it's ugly. Many of the 
 people who said it's ugly actually came up with proposals that are 
 arguably ugly, hopelessly confusing, or both. Look at only some of the 
 rehashed proposals of today: the genial "case [0 .. 10]:" which is 
 horribly inconsistent, and the awesome "case 0: ... case 10:", also 
 inconsistent (and gratuitously so) because ellipses today only end 
 lists without having something to their right. The authors claim those 
 are better than the current syntax, and one even claimed "beauty", 
 completely ignoring the utter lack of consistency with the rest of the 
 language. I don't 

I oriented this on the syntax of array slices. Which work that way.

No, it works differently because the slice is open to the right, whereas with switch one seldom wants to specify an open range.
 Not 
 inconsistent at all. It's also consistent with foreach(_; x..y).

No, it isn't consistent. It's a lose-lose proposition. If you want to make it consistent you'd need to have ['a' .. 'z'] exclude the 'z'. That would confuse people who expect ['a' .. 'z'] to contain 'z'. On the other hand, if you choose to include 'z' you will confuse people who expect behavior to be similar with that in arrays. Going with a syntax that uses ".." just as punctuation but otherwise firmly departs from the slice notation eliminates expectation of semantic similarity. And the presence of the second "case" firmly clarifies that the last label is to be included in the range, even to the first-time reader. There would be seldom a need to check the manual for that.
 Other than that, I realize it's not that good of a choice and it's not 
 elegant at all. But I think it's still better than some of your horrible 
 language crimes (including yours) that are being forced into D.

Thanks for emphasizing twice that it's about me. Yep, they're my horrible language crimes - and those definitely include mine :o). I genuinely appreciate the honesty, and to reciprocate, I don't think very highly of your competence either (as every other post of yours makes some technical mistake), and I find your attitude corrosive. Andrei
Jul 06 2009
parent grauzone <none example.net> writes:
 Thanks for emphasizing twice that it's about me. Yep, they're my 
 horrible language crimes - and those definitely include mine :o). I 
 genuinely appreciate the honesty, and to reciprocate, I don't think very 
 highly of your competence either (as every other post of yours makes 
 some technical mistake), and I find your attitude corrosive.

It was a typo, I meant to diss you only once. There are plenty of language crimes not caused by you, as well as good features which were proposed by you. I hope this makes you happy.
Jul 06 2009
prev sibling next sibling parent reply The Anh Tran <trtheanh gmail.com> writes:
Andrei Alexandrescu wrote:
 I agree there are ugly constructs in D, and is-expressions would near 
 the top of the list (particularly the absolutely awful is(T : T[])), but 
 you have no case (heh) with the switch statement.
 
 
 Andrei

Just a funny suggestion: could we change the is() expression to imperative style? Now: template Something(T, U, V) if ( is(T : T[]) && is(...) ) { alias T blah1; U blah2; class C {}; struct S {}; } In mirror universe: template Something(T, U, V) in { static if ( T : T[] ) // static if here mean if (is (...)) { // may do something with T, make alias, change type // or check another constraint. } else { pragma(msg, "T must be Klingon"); static assert(false); // Or return false; ???? } static if ( U == int ) { V = float; // ????? } return true; } body { alias T blah1; U blah2; class C {}; struct S {}; }
Jul 06 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
The Anh Tran wrote:
 Andrei Alexandrescu wrote:
 I agree there are ugly constructs in D, and is-expressions would near 
 the top of the list (particularly the absolutely awful is(T : T[])), 
 but you have no case (heh) with the switch statement.


 Andrei

Just a funny suggestion: could we change the is() expression to imperative style? Now: template Something(T, U, V) if ( is(T : T[]) && is(...) ) { alias T blah1; U blah2; class C {}; struct S {}; } In mirror universe: template Something(T, U, V) in { static if ( T : T[] ) // static if here mean if (is (...)) { // may do something with T, make alias, change type // or check another constraint. } else { pragma(msg, "T must be Klingon"); static assert(false); // Or return false; ???? } static if ( U == int ) { V = float; // ????? } return true; } body { alias T blah1; U blah2; class C {}; struct S {}; }

I wished for the longest time to simplify the often-used if(is(...)) syntax, but Walter said there are too many ambiguities involved if "is" gets dropped. Andrei
Jul 06 2009
prev sibling parent Leandro Lucarella <llucax gmail.com> writes:
Andrei Alexandrescu, el  6 de julio a las 18:32 me escribiste:
 Leandro Lucarella wrote:
Andrei Alexandrescu, el  6 de julio a las 10:44 me escribiste:
And what did those people use when they wanted to express a range of case 
labels? In other words, where did those people turn their heads towards?



have to do considerably better. When I have to choose between something well know, well supported and mature and something that is, at least, unknown (even if it's mature and well supported, I won't know that until I use it a lot so is a risk), I want to be really good, not just barely good.

That goes without saying.
Details as this one are not deal breaker on their own, but when they are
a lot, it tends to make the language look ugly as a whole.

You are just saying it's ugly. I don't think it's ugly. Walter doesn't think it's ugly. Other people don't think it's ugly. Many of the people who said it's ugly actually came up with proposals that are arguably ugly, hopelessly confusing, or both. Look at only some of the rehashed proposals of today: the genial "case [0 .. 10]:" which is horribly inconsistent, and the awesome "case 0: ... case 10:", also inconsistent (and gratuitously so) because ellipses today only end lists without having something to their right. The authors claim those are better than the current syntax, and one even claimed "beauty", completely ignoring the utter lack of consistency with the rest of the language. I don't claim expertise in language design, so I wish there were a few good experts in this group.

Please read the thread at D NG, the current syntax *is* inconsistent too. -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ----------------------------------------------------------------------------
Jul 07 2009
prev sibling parent "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
Ary Borenszweig wrote:
 のしいか (noshiika) escribió:
 Thank you for the great work, Walter and all the other contributors.

 But I am a bit disappointed with the CaseRangeStatement syntax.
 Why is it
    case 0: .. case 9:
 instead of
    case 0 .. 9:

 With the latter notation, ranges can be easily used together with 
 commas, for example:
    case 0, 2 .. 4, 6 .. 9:

 And CaseRangeStatement, being inconsistent with other syntaxes using 
 the .. operator, i.e. slicing and ForeachRangeStatement, includes the 
 endpoint.
 Shouldn't D make use of another operator to express ranges that 
 include the endpoints as Ruby or Perl6 does?

I agree. I think this syntax is yet another one of those things people looking at D will say "ugly" and turn their heads away.

When the discussion first came up in the NG, I was a bit sceptical about Andrei's suggestion for the case range statement as well. Now, I definitely think it's the best choice, and it's only because I realised it can be written like this: case 1: .. case 4: // do stuff Even though it's the same as case 1: .. case 4:, and even though adding those two newlines is just a visual change, it leaves (to me, at least) no doubt that this is an inclusive range even though the .. operator is used, simply because what I would otherwise write is: case 1: case 2: case 3: case 4: // do stuff Also: Thanks for a great release, Walter, Andrei, Don, Sean and everyone else! (Who else are involved in core development of D2, by the way?) I am liking this language better and better the more I use it. And now, to convince the rest of the scientific community that FORTRAN must go... -Lars
Jul 06 2009
prev sibling next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Mon, 06 Jul 2009 22:48:07 +0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 Chad J wrote:
 Walter Bright wrote:
 grauzone wrote:
 No. Also, this final switch feature seems to be only marginally
 useful, and normal switch statements do the same, just at runtime. So
 much for "more pressing issues" but it's his language and not mine so
 I'll shut up.

one file and then have to find and update every switch statement that uses that enum. There's no straightforward way to find them to ensure the case gets added to each switch. It's solving a similar problem that symbolic constants do. The fall-through thing, though, is purely local and so much less of an issue.

These bugs always take me no less than 2 hours to find, unless I am specifically looking for fall-through bugs.

I agree. Probably a good option would be to keep on requiring break, but also requiring the user to explicitly specify they want fallthrough in the rare case when they do want it. I'd love to use "continue" for that but it's already "occupied" by cases like while (...) switch (...). Requiring !break or ~break would work but is a bit too cute. Adding a new keyword or a whole new switch statement is too much aggravation. I guess we'll have to live with it... Andrei

Reuse goto?
Jul 06 2009
prev sibling next sibling parent Jesse Phillips <jessekphillips gmail.com> writes:
On Mon, 06 Jul 2009 14:38:53 -0500, Andrei Alexandrescu wrote:

 Denis Koroskin wrote:
 Reuse goto?

So any case-labeled code should end either with a control flow statement that transfers control elswhere? That sounds like a great idea. Fall-through is so rare and so rarely intended, it makes sense to require the programmer to state the intent explicitly via a goto case. Andrei

The goto method already works, the only change needed would be to not have fallthru default. http://digitalmars.com/d/2.0/statement.html#GotoStatement
Jul 06 2009
prev sibling next sibling parent Moritz Warning <moritzwarning web.de> writes:
On Tue, 07 Jul 2009 08:53:49 +0200, Lars T. Kyllingstad wrote:

 Ary Borenszweig wrote:
 のしいか (noshiika) escribió:
 Thank you for the great work, Walter and all the other contributors.

 But I am a bit disappointed with the CaseRangeStatement syntax. Why is
 it
    case 0: .. case 9:
 instead of
    case 0 .. 9:

 With the latter notation, ranges can be easily used together with
 commas, for example:
    case 0, 2 .. 4, 6 .. 9:

 And CaseRangeStatement, being inconsistent with other syntaxes using
 the .. operator, i.e. slicing and ForeachRangeStatement, includes the
 endpoint.
 Shouldn't D make use of another operator to express ranges that
 include the endpoints as Ruby or Perl6 does?

I agree. I think this syntax is yet another one of those things people looking at D will say "ugly" and turn their heads away.

When the discussion first came up in the NG, I was a bit sceptical about Andrei's suggestion for the case range statement as well. Now, I definitely think it's the best choice, and it's only because I realised it can be written like this: case 1: .. case 4: // do stuff

I think it looks much better that way and users are more likely to be comfortable with the syntax. I hope it will be displayed in the examples that way. Still, the syntax at all looks a bit alien because it's a syntax addition.
Jul 07 2009
prev sibling parent Jesse Phillips <jessekphillips gmail.com> writes:
On Tue, 07 Jul 2009 11:05:31 -0400, bearophile wrote:

 KennyTM~ Wrote:
 Maybe http://msdn.microsoft.com/en-us/vcsharp/aa336815.aspx .

That compromise design looks good to be adopted by D too :-) Bye, bearophile

For which we have, case 1, 2, 3: writeln("I believe");
Jul 07 2009
prev sibling next sibling parent Lutger <lutger.blijdestijn gmail.com> writes:
Thanks everybody!
Jul 06 2009
prev sibling next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Mon, 06 Jul 2009 09:05:10 +0400, Walter Bright  
<newshound1 digitalmars.com> wrote:

 Something for everyone here.


 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.046.zip


 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.031.zip

Someone's clock must have stopped at May, 14 - that's what being show as a D2.031 release date (although "Last update Sun Jul 5 01:18:49 2009") You may want to check D1.046 released date, too.
Jul 06 2009
prev sibling next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Walter Bright wrote:
 Something for everyone here.
 
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.046.zip
 
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.031.zip

The dmd2 phobos seem to have a directory replaced with a file, for std.c.osx.socket ? std/socket.d(79): Error: module socket cannot read file 'std/c/osx/socket.d' std/c/osx -> std/c/osx/socket.d Ran into some Makefile issues as well, reported as bugzilla #3140 and #3141. --anders
Jul 06 2009
prev sibling next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Mon, 06 Jul 2009 14:13:45 +0400, Walter Bright  
<newshound1 digitalmars.com> wrote:

 Derek Parnell wrote:
 On Mon, 06 Jul 2009 00:11:26 -0700, Walter Bright wrote:

 Derek Parnell wrote:
 I'm struggling to see why the compiler cannot just disallow any
 signed<->unsigned implicit conversion? Is it a matter of backward
 compatibility again?


size issue.

It can also be an unsigned.
 What's the problem that I'm obviously missing?

 When you index a pointer, is the index signed or unsigned?


auto x = p1 - p2; What's the type of x?

ptrdiff_t, signed counterpart of size_t
Jul 06 2009
prev sibling next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Mon, 06 Jul 2009 14:28:38 +0400, Walter Bright  
<newshound1 digitalmars.com> wrote:

 Denis Koroskin wrote:
 auto x = p1 - p2;

 What's the type of x?


Do you really want an error if you go: size_t y = p1 - p2; ?

Of course, what sense does it make when p2 > p1? I'd put an assert and mad a case explicit, if there is a size_t is so badly needed for ptr difference: assert(p1 >= p2); size_t y = cast(size_t)p1 - p2;
Jul 06 2009
prev sibling next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Mon, 06 Jul 2009 14:28:38 +0400, Walter Bright
<newshound1 digitalmars.com> wrote:

 Denis Koroskin wrote:
 auto x = p1 - p2;

 What's the type of x?


Do you really want an error if you go: size_t y = p1 - p2; ?

Of course, what sense does it make when p2 > p1? I'd put an assert and made a cast explicit, if a size_t is so badly needed for ptr difference: assert(p1 >= p2); size_t y = cast(size_t)p1 - p2;
Jul 06 2009
prev sibling next sibling parent reply "Robert Jacques" <sandford jhu.edu> writes:
On Mon, 06 Jul 2009 01:05:10 -0400, Walter Bright  
<newshound1 digitalmars.com> wrote:

 Something for everyone here.


 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.046.zip


 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.031.zip

Thanks for another great release. Also, I'm not sure if this is a bug or a feature with regard to the new integer rules: byte x,y,z; z = x+y; // Error: cannot implicitly convert expression (cast(int)x + cast(int)y) of type int to byte which makes sense, in that a byte can overflow, but also doesn't make sense, since integer behaviour is different. BTW: The fact that in my original code base DMD gave me the line, inside the string, inside the mixin, inside the template, inside the mixin, inside the struct was just awesome. P.S. There's a bunch of functions in phobos (like std.math.lrint) which return a long and should also have (at least) an integer version as well. (Maybe rndto!T() ?)
Jul 06 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Robert Jacques wrote:
 On Mon, 06 Jul 2009 01:05:10 -0400, Walter Bright 
 <newshound1 digitalmars.com> wrote:
 
 Something for everyone here.


 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.046.zip


 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.031.zip

Thanks for another great release. Also, I'm not sure if this is a bug or a feature with regard to the new integer rules: byte x,y,z; z = x+y; // Error: cannot implicitly convert expression (cast(int)x + cast(int)y) of type int to byte which makes sense, in that a byte can overflow, but also doesn't make sense, since integer behaviour is different.

Walter has implemented an ingenious scheme for disallowing narrowing conversions while at the same time minimizing the number of casts required. He hasn't explained it, so I'll sketch an explanation here. The basic approach is "value range propagation": each expression is associated with a minimum possible value and a maximum possible value. As complex expressions are assembled out of simpler expressions, the ranges are computed and propagated. For example, this code compiles: int x = whatever(); bool y = x & 1; The compiler figures that the range of x is int.min to int.max, the range of 1 is 1 to 1, and (here's the interesting part), the range of x & 1 is 0 to 1. So it lets the code go through. However, it won't allow this: int x = whatever(); bool y = x & 2; because x & 2 has range between 0 and 2, which won't fit in a bool. The approach generalizes to arbitrary complex expressions. Now here's the trick though: the value range propagation is local, i.e. all ranges are forgotten beyond one expression. So as soon as you move on to the next statement, the ranges have been forgotten. Why? Simply put, increased implementation difficulties and increased compiler memory footprint for diminishing returns. Both Walter and I noticed that expression-level value range propagation gets rid of all dangerous cases and the vast majority of required casts. Indeed, his test suite, Phobos, and my own codebase required surprisingly few changes with the new scheme. Moreover, we both discovered bugs due to the new feature, so we're happy with the status quo. Now consider your code: byte x,y,z; z = x+y; The first line initializes all values to zero. In an intra-procedural value range propagation, these zeros would be propagated to the next statement, which would range-check. However, in the current approach, the ranges of x, y, and z are forgotten at the first semicolon. Then, x+y has range -byte.min-byte.min up to byte.max+byte.max as far as the type checker knows. That would fit in a short (and by the way I just found a bug with that occasion) but not in a byte.
 BTW: The fact that in my original code base DMD gave me the line, inside 
 the string, inside the mixin, inside the template, inside the mixin, 
 inside the struct was just awesome.
 
 P.S. There's a bunch of functions in phobos (like std.math.lrint) which 
 return a long and should also have (at least) an integer version as 
 well. (Maybe rndto!T() ?)

Sounds like Don's area. Don? Andrei
Jul 06 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Robert Jacques wrote:
 On Tue, 07 Jul 2009 01:48:41 -0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:
 
 Robert Jacques wrote:
 On Mon, 06 Jul 2009 01:05:10 -0400, Walter Bright 
 <newshound1 digitalmars.com> wrote:

 Something for everyone here.


 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.046.zip


 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.031.zip

Also, I'm not sure if this is a bug or a feature with regard to the new integer rules: byte x,y,z; z = x+y; // Error: cannot implicitly convert expression (cast(int)x + cast(int)y) of type int to byte which makes sense, in that a byte can overflow, but also doesn't make sense, since integer behaviour is different.

Walter has implemented an ingenious scheme for disallowing narrowing conversions while at the same time minimizing the number of casts required. He hasn't explained it, so I'll sketch an explanation here. The basic approach is "value range propagation": each expression is associated with a minimum possible value and a maximum possible value. As complex expressions are assembled out of simpler expressions, the ranges are computed and propagated. For example, this code compiles: int x = whatever(); bool y = x & 1; The compiler figures that the range of x is int.min to int.max, the range of 1 is 1 to 1, and (here's the interesting part), the range of x & 1 is 0 to 1. So it lets the code go through. However, it won't allow this: int x = whatever(); bool y = x & 2; because x & 2 has range between 0 and 2, which won't fit in a bool. The approach generalizes to arbitrary complex expressions. Now here's the trick though: the value range propagation is local, i.e. all ranges are forgotten beyond one expression. So as soon as you move on to the next statement, the ranges have been forgotten. Why? Simply put, increased implementation difficulties and increased compiler memory footprint for diminishing returns. Both Walter and I noticed that expression-level value range propagation gets rid of all dangerous cases and the vast majority of required casts. Indeed, his test suite, Phobos, and my own codebase required surprisingly few changes with the new scheme. Moreover, we both discovered bugs due to the new feature, so we're happy with the status quo. Now consider your code: byte x,y,z; z = x+y; The first line initializes all values to zero. In an intra-procedural value range propagation, these zeros would be propagated to the next statement, which would range-check. However, in the current approach, the ranges of x, y, and z are forgotten at the first semicolon. Then, x+y has range -byte.min-byte.min up to byte.max+byte.max as far as the type checker knows. That would fit in a short (and by the way I just found a bug with that occasion) but not in a byte.

That's really cool. But I don't think that's actually happening (Or are these the bugs you're talking about?): byte x,y; short z; z = x+y; // Error: cannot implicitly convert expression (cast(int)x + cast(int)y) of type int to short // Repeat for ubyte, bool, char, wchar and *, -, /

http://d.puremagic.com/issues/show_bug.cgi?id=3147 You may want to add to it.
 And by that logic shouldn't the following happen?
 
     int x,y;
     int z;
     z = x+y;  // Error: cannot implicitly convert expression 
 (cast(long)x + cast(long)y) of type long to int

No. Int remains "special", i.e. arithmetic operations on it don't automatically grow to become long.
 i.e. why the massive inconsistency between byte/short and int/long? 
 (This is particularly a pain for generic i.e. templated code)

I don't find it a pain. It's a practical decision.
 BTW: this means byte and short are not closed under arithmetic 
 operations, which drastically limit their usefulness.

I think they shouldn't be closed because they overflow for relatively small values. Andrei
Jul 07 2009
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Brad Roberts wrote:
 That's really cool. But I don't think that's actually happening (Or
 are these the bugs you're talking about?):

     byte x,y;
     short z;
     z = x+y;  // Error: cannot implicitly convert expression
 (cast(int)x + cast(int)y) of type int to short

     // Repeat for ubyte, bool, char, wchar and *, -, /

to it.

Before going too far, consider: byte x, y, z; short a; a = x + y + z; How far should the logic go?

Arbitrarily far for any given expression, which is the beauty of it all. In the case above, the expression is evaluated as (x + y) + z, yielding a range of -byte.min-byte.min to byte.max+byte.max for the parenthesized part. Then that range is propagated to the second addition yielding a final range of -byte.min-byte.min-byte.min to byte.max+byte.max+byte.max for the entire expression. That still fits in a short, so the expression is valid. Now, if you add more than 255 bytes, things won't compile anymore ;o). Andrei
Jul 07 2009
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Robert Jacques wrote:
 On Tue, 07 Jul 2009 03:33:24 -0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:
 Robert Jacques wrote:
  That's really cool. But I don't think that's actually happening (Or 
 are these the bugs you're talking about?):
      byte x,y;
     short z;
     z = x+y;  // Error: cannot implicitly convert expression 
 (cast(int)x + cast(int)y) of type int to short
      // Repeat for ubyte, bool, char, wchar and *, -, /

http://d.puremagic.com/issues/show_bug.cgi?id=3147 You may want to add to it.

Added. In summary, + * - / % >> >>> don't work for types 8-bits and under. << is inconsistent (x<<1 errors, but x<<y compiles). All the op assigns (+= *= -= /= %= >>= <<= >>>=) and pre/post increments (++ --) compile which is maddeningly inconsistent, particularly when the spec defines ++x as sugar for x = x + 1, which doesn't compile.
 And by that logic shouldn't the following happen?
      int x,y;
     int z;
     z = x+y;  // Error: cannot implicitly convert expression 
 (cast(long)x + cast(long)y) of type long to int

No. Int remains "special", i.e. arithmetic operations on it don't automatically grow to become long.
 i.e. why the massive inconsistency between byte/short and int/long? 
 (This is particularly a pain for generic i.e. templated code)

I don't find it a pain. It's a practical decision.

Andrei, I have a short vector template (think vec!(byte,3), etc) where I've had to wrap the majority lines of code in cast(T)( ... ), because I support bytes and shorts. I find that both a kludge and a pain.

Well suggestions for improving things are welcome. But I don't think it will fly to make int+int yield a long.
 BTW: this means byte and short are not closed under arithmetic 
 operations, which drastically limit their usefulness.

I think they shouldn't be closed because they overflow for relatively small values.

Andrei, consider anyone who want to do image manipulation (or computer vision, video, etc). Since images are one of the few areas that use bytes extensively, and have to map back into themselves, they are basically sorry out of luck.

I understand, but also keep in mind that making small integers closed is the less safe option. So we'd be hurting everyone for the sake of the image manipulation folks. Andrei
Jul 07 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Robert Jacques wrote:
 On Tue, 07 Jul 2009 11:36:26 -0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:
 Robert Jacques wrote:
  Andrei, I have a short vector template (think vec!(byte,3), etc) 
 where I've had to wrap the majority lines of code in cast(T)( ... ), 
 because I support bytes and shorts. I find that both a kludge and a 
 pain.

Well suggestions for improving things are welcome. But I don't think it will fly to make int+int yield a long.

Suggestion 1: Loft the right hand of the expression (when lofting is valid) to the size of the left hand. i.e.

What does loft mean in this context?
 byte a,b,c;
 c = a + b;  => c = a + b;

Unsafe.
 short d;
 d = a + b;  => d = cast(short) a + cast(short) b;

Should work today modulo bugs.
 int e, f;
 e = a + b;  => e = cast(short) a + cast(short) b;

Why cast to short? e has type int.
 e = a + b + d; => e = cast(int)(cast(short) a + cast(short) b) + 
 cast(int) d; Or e = cast(int) a + (cast(int) b + cast(int)d);

I don't understand this.
 long g;
 g = e + f;  => d = cast(long) e + cast(long) f;

Works today.
 When choosing operator overloads or auto, prefer the ideal lofted 
 interpretation (as per the new rules, but without the exception for 
 int/long), over truncated variants. i.e.
 auto h = a + b; => short h = cast(short) a + cast(short) b;

This would yield semantics incompatible with C expressions.
 This would also properly handled some of the corner/inconsistent cases 
 with the current rules:
 ubyte  i;
 ushort j;
 j = -i;    => j = -cast(short)i; (This currently evaluates to j = 
 cast(short)(-i);

That should not compile, sigh. Walter wouldn't listen...
 And
 a += a;
 is equivalent to
 a = a + a;

Well not quite equivalent. In D2 they aren't. The former clarifies that you want to reassign the expression to a, and no cast is necessary. The latter would not compile if a is shorter than int.
 and is logically consistent with
 byte[] k,l,m;
 m[] = k[] + l[];
 
 Essentially, instead of trying to prevent overflows, except for those 
 from int and long, this scheme attempts to minimize the risk of 
 overflows, including those from int (and long, once cent exists. Maybe 
 long+long=>bigInt?)

But if you close operations for types smaller than int, you end up with a scheme even more error-prone that C!
 Suggestion 2:
 Enable the full rules as part of SafeD and allow non-promotion in 
 un-safe D. Note this could be synergistically combined with Suggestion 1.

Safe D is concerned with memory safety only. Andrei
Jul 07 2009
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:
 Safe D is concerned with memory safety only.

And hopefully you will understand that is wrong :-) Bye, bearophile
Jul 07 2009
prev sibling next sibling parent Derek Parnell <derek psych.ward> writes:
On Tue, 07 Jul 2009 13:16:14 -0500, Andrei Alexandrescu wrote:


 Safe D is concerned with memory safety only.

That's a pity. Maybe it should be renamed to Partially-Safe D, or Safe-ish D, Memory-Safe D, or ... well you get the point. Could be misleading for the great unwashed. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Jul 07 2009
prev sibling next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Robert Jacques wrote:
 The new rules are definitely an improvement over C, but they make 
 byte/ubyte/short/ushort second class citizens, because practically every 
 assignment requires a cast:
 byte a,b,c;
 c = cast(byte) a + b;

They've always been second class citizens, as their types keep getting promoted to int. They've been second class on the x86 CPUs, too, as short operations tend to be markedly slower than the corresponding int operations.
 And if it weren't for compatibility issues, it would almost be worth it 
 to remove them completely.

Shorts and bytes are very useful in arrays and data structures, but aren't worth much as local variables. If I see a: short s; as a local, it always raises an eyebrow with me that there's a lurking bug.
Jul 07 2009
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Robert Jacques wrote:
 long g;
 g = e + f;  => d = cast(long) e + cast(long) f;

Works today.

Wrong. I just tested this and what happens today is: g = cast(long)(e+f); And this is (I think) correct behavior according to the new rules and not a bug. In the new rules int is special, in this suggestion, it's not.

I think this is a good idea that would improve things. I think, however, it would be troublesome to implement because expressions are typed bottom-up. The need here is to "teleport" type information from the assignment node to the addition node, which is downwards. And I'm not sure how this would generalize to other operators beyond "=". Andrei
Jul 07 2009
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Andrei Alexandrescu wrote:
 Robert Jacques wrote:
 long g;
 g = e + f;  => d = cast(long) e + cast(long) f;

Works today.

Wrong. I just tested this and what happens today is: g = cast(long)(e+f); And this is (I think) correct behavior according to the new rules and not a bug. In the new rules int is special, in this suggestion, it's not.

I think this is a good idea that would improve things. I think, however, it would be troublesome to implement because expressions are typed bottom-up. The need here is to "teleport" type information from the assignment node to the addition node, which is downwards. And I'm not sure how this would generalize to other operators beyond "=".

It's also troublesome because it would silently produce different answers than C would.
Jul 07 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Robert Jacques wrote:
 So by the spec   (and please correct me if I'm reading this wrong)
 g = e + f => g = cast(long)(  cast(integer)e + cast(integer)f  );
 where integer is unbounded in bits (and therefore has no overflow)
 therefore
 g = e + f;  => d = cast(long) e + cast(long) f;
 is more in keeping with the spec than
 g = cast(long)(e+f);
 in terms of a practical implementation, since there's less possibility 
 for overflow error.

The spec leaves a lot of room for implementation defined behavior. But still, there are common definitions for those implementation defined behaviors, and C programs routinely rely on them. Just like the C standard supports 32 bit "bytes", but essentially zero C programs will port to such a platform without major rewrites. Silently changing the expected results is a significant problem. The guy who does the translation is hardly likely to be the guy who wrote the program. When he notices the program failing, I guarantee he'll write it off as "D sux". He doesn't have the time to debug what looks like a fault in D, and frankly I would agree with him. I have a lot of experience with people porting C/C++ programs to Digital Mars compilers. They run into some implementation-defined issue, or rely on some bug in B/M/X compilers, and yet it's always DM's problem, not B/M/X or the code. There's no point in fighting that, it's just the way it is, and to deal with reality means that DM must follow the same implementation-defined behavior and bugs as B/M/X compilers do. For a C integer expression, D must either refuse to compile it or produce the same results.
 (Caveat: most 32-bit compilers probably defaulted integer to int, though 
 64-bit compilers are probably defaulting integer to long.)

All 32 bit C compilers defaulted int to 32 bits. 64 bit C compilers are setting int at 32 bits for sensible compatibility reasons.
Jul 07 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
Robert Jacques wrote:
 On Tue, 07 Jul 2009 23:01:58 -0400, Walter Bright 
 <newshound1 digitalmars.com> wrote:
 Robert Jacques wrote:
 (Caveat: most 32-bit compilers probably defaulted integer to int, 
 though 64-bit compilers are probably defaulting integer to long.)

All 32 bit C compilers defaulted int to 32 bits. 64 bit C compilers are setting int at 32 bits for sensible compatibility reasons.

But are the 64-bit compilers setting the internal "integer" type to 32 or 64 bits? (I'm not running any 64-bit OSes at the moment to test this)

Not that I've seen. I'd be very surprised if any did.
Jul 07 2009
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Robert Jacques wrote:
 On Tue, 07 Jul 2009 20:48:50 -0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:
 
 Robert Jacques wrote:
 long g;
 g = e + f;  => d = cast(long) e + cast(long) f;

Works today.

g = cast(long)(e+f); And this is (I think) correct behavior according to the new rules and not a bug. In the new rules int is special, in this suggestion, it's not.

I think this is a good idea that would improve things. I think, however, it would be troublesome to implement because expressions are typed bottom-up. The need here is to "teleport" type information from the assignment node to the addition node, which is downwards. And I'm not sure how this would generalize to other operators beyond "=". Andrei

Hmm... why can't multiple expressions be built simultaneously and then the best chosen once the assignment/function call/etc is reached? This would also have the benifet of paving the way for polysemous values & expressions.

Anything can be done... in infinite time with infinite resources. :o) Andrei
Jul 07 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Robert Jacques wrote:
 On Tue, 07 Jul 2009 21:21:47 -0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:
 
 Robert Jacques wrote:
 On Tue, 07 Jul 2009 20:48:50 -0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:

 Robert Jacques wrote:
 long g;
 g = e + f;  => d = cast(long) e + cast(long) f;

Works today.

g = cast(long)(e+f); And this is (I think) correct behavior according to the new rules and not a bug. In the new rules int is special, in this suggestion, it's not.

I think this is a good idea that would improve things. I think, however, it would be troublesome to implement because expressions are typed bottom-up. The need here is to "teleport" type information from the assignment node to the addition node, which is downwards. And I'm not sure how this would generalize to other operators beyond "=". Andrei

then the best chosen once the assignment/function call/etc is reached? This would also have the benifet of paving the way for polysemous values & expressions.

Anything can be done... in infinite time with infinite resources. :o) Andrei

:) Well, weren't polysemous expressions already in the pipeline somewhere?

I'm afraid they didn't get wings. We have incidentally found different ways to address the issues they were supposed to address. Andrei
Jul 07 2009
prev sibling parent Brad Roberts <braddr puremagic.com> writes:
Walter Bright wrote:
 Robert Jacques wrote:
 On Tue, 07 Jul 2009 23:01:58 -0400, Walter Bright
 <newshound1 digitalmars.com> wrote:
 Robert Jacques wrote:
 (Caveat: most 32-bit compilers probably defaulted integer to int,
 though 64-bit compilers are probably defaulting integer to long.)

All 32 bit C compilers defaulted int to 32 bits. 64 bit C compilers are setting int at 32 bits for sensible compatibility reasons.

But are the 64-bit compilers setting the internal "integer" type to 32 or 64 bits? (I'm not running any 64-bit OSes at the moment to test this)

Not that I've seen. I'd be very surprised if any did.

From wikipedia: http://en.wikipedia.org/wiki/64-bit

model short int long llong ptrs Sample operating systems LLP64 16 32 32 64 64 Microsoft Win64 (X64/IA64) LP64 16 32 64 64 64 Most UNIX and UNIX-like systems (Solaris, Linux, etc) ILP64 16 64 64 64 64 HAL SILP64 64 64 64 64 64 ?
Jul 07 2009
prev sibling next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Tue, 07 Jul 2009 14:05:33 -0400, Robert Jacques wrote:


 Well, how often does everyone else use bytes?

Cryptography, in my case. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Jul 07 2009
parent reply Derek Parnell <derek psych.ward> writes:
On Tue, 07 Jul 2009 18:10:24 -0400, Robert Jacques wrote:

 On Tue, 07 Jul 2009 18:05:26 -0400, Derek Parnell <derek psych.ward> wrote:
 
 On Tue, 07 Jul 2009 14:05:33 -0400, Robert Jacques wrote:


 Well, how often does everyone else use bytes?

Cryptography, in my case.

Cool. If you don't mind, what's you're take new rules? (As different use cases and points of view are very valuable)

By new rules you mean the ones implemented in D 2.031? I'm not sure yet. I need to use them more in practice to see how they sort themselves out. It seems that what they are trying to do is predict runtime behaviour at compile time and make the appropriate (as defined by Walter) steps to avoid runtime errors. Anyhow, and be warned that I'm just thinking out loud here, we could have a scheme where the coder explicitly tells the compiler that, in certain specific sections of code, the coder would like to have runtime checking of overflow situations added by the compiler. Something like ... byte a,b,c; try { a = b + c; } catch (OverflowException e) { ... } and in this situation the compiler would not give a message, because I've instructed the compiler to generate runtime checking. The problem we would now have though is balancing the issuing-of-messages with the ease-of-coding. It seems that the most common kind of assignment is where the LHS type is the same as the RHS type(s), so we don't want to make that any harder to code. But clearly, this is also the most common source of potential overflows. Ok, let's assume that we don't want the D compiler to be our nanny; that we are adults and understand stuff. This now leads me to think that unless the coder says differently, the compiler should be silent about potential overflows. The "try .. catch" example above is verbose, however it does scream "run-time checking" to me so it is probably worth the effort. The only remaining issue for me is how to catch accidental overflows in the special cases where I, as a responsible coder, knowingly wish to avoid. Here is where I propose having a signal to the compiler about which specific variables I'm worried about, and if I code an assignment to one of these that can potentially overflow, then the compiler must issue a message. NOTE BENE: For the purposes of these examples, I use the word "guard" as the signal for the compiler to guard against overflows. I don't care so much about which specific signalling method could be adopted. This is still conceptual stuff, okay? guard byte a; // I want this byte guarded. byte b,c; // I don't care about these bytes. a = 3 + 29; // No message 'cos 32 fits into a byte. a = b + c; // Message 'cos it could overflow. a = cast(byte)(b + c); // No message 'cos cast overrides messages. a++; // Message - overflow is possible. a += 1; // Message - overflow is possible. a = a + 1 // Message - overflow is possible. a = cast(byte)a + 1; // No message 'cos cast overrides messages. And for a really smart compiler ... a = 0; a++; // No message as it can determine that the run time value // at this point in time is okay. for (a = 'a'; a <= 'z'; a++) // Still no message. Additionally, I'm pretty certain that I think ... auto x = y + z; should ensure that 'x' is a type that will always be able to hold any value from (y.min + z.min) to (y.max + z.max) inclusive. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Jul 07 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Derek Parnell wrote:
 Here is where I propose having a signal to the compiler about which
 specific variables I'm worried about, and if I code an assignment to one of
 these that can potentially overflow, then the compiler must issue a
 message. 

You can implement that as a library. In fact I wanted to do it for Phobos for a long time. I've discussed it in this group too (to an unusual consensus), but I forgot the thread's title and stupid Thunderbird "download 500 headers at a time forever even long after have changed that idiotic default option" won't let me find it. Andrei
Jul 07 2009
next sibling parent Derek Parnell <derek psych.ward> writes:
On Tue, 07 Jul 2009 20:13:40 -0500, Andrei Alexandrescu wrote:

 Derek Parnell wrote:
 Here is where I propose having a signal to the compiler about which
 specific variables I'm worried about, and if I code an assignment to one of
 these that can potentially overflow, then the compiler must issue a
 message. 

You can implement that as a library. In fact I wanted to do it for Phobos for a long time.

What does "implement that as a library" actually mean? Does it mean that a Phobos module could be written that defines a struct template (presumably) that holds the data and implements opAssign, etc... to issue a message if required. I assume it could do some limited compile-time value tests so it doesn't always have to issue a message. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Jul 07 2009
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Andrei Alexandrescu wrote:
 You can implement that as a library. In fact I wanted to do it for 
 Phobos for a long time. I've discussed it in this group too (to an 
 unusual consensus), but I forgot the thread's title and stupid 
 Thunderbird "download 500 headers at a time forever even long after have 
 changed that idiotic default option" won't let me find it.

All the messages from the dawn of time are online and available at http://www.digitalmars.com/d/archives/digitalmars/D/ and are searchable from the search box in the upper left.
Jul 07 2009
parent Derek Parnell <derek psych.ward> writes:
On Tue, 07 Jul 2009 18:26:36 -0700, Walter Bright wrote:


 All the messages from the dawn of time are online and available at 
 http://www.digitalmars.com/d/archives/digitalmars/D/ and are searchable 
 from the search box in the upper left.

Okaaayy ... I see that this (checking for integer overflow) has been an issue since at least 2003. http://www.digitalmars.com/d/archives/19850.html At this rate, D v2 will be released some time after C++0X :-) -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Jul 07 2009
prev sibling parent Charles Hixson <charleshixsn earthlink.net> writes:
Andrei Alexandrescu wrote:
 Robert Jacques wrote:
 On Tue, 07 Jul 2009 03:33:24 -0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:
 Robert Jacques wrote:
  That's really cool. But I don't think that's actually happening (Or 
 are these the bugs you're talking about?):
      byte x,y;
     short z;
     z = x+y;  // Error: cannot implicitly convert expression 
 (cast(int)x + cast(int)y) of type int to short
      // Repeat for ubyte, bool, char, wchar and *, -, /

http://d.puremagic.com/issues/show_bug.cgi?id=3147 You may want to add to it.

Added. In summary, + * - / % >> >>> don't work for types 8-bits and under. << is inconsistent (x<<1 errors, but x<<y compiles). All the op assigns (+= *= -= /= %= >>= <<= >>>=) and pre/post increments (++ --) compile which is maddeningly inconsistent, particularly when the spec defines ++x as sugar for x = x + 1, which doesn't compile.
 And by that logic shouldn't the following happen?
      int x,y;
     int z;
     z = x+y;  // Error: cannot implicitly convert expression 
 (cast(long)x + cast(long)y) of type long to int

No. Int remains "special", i.e. arithmetic operations on it don't automatically grow to become long.
 i.e. why the massive inconsistency between byte/short and int/long? 
 (This is particularly a pain for generic i.e. templated code)

I don't find it a pain. It's a practical decision.

Andrei, I have a short vector template (think vec!(byte,3), etc) where I've had to wrap the majority lines of code in cast(T)( ... ), because I support bytes and shorts. I find that both a kludge and a pain.

Well suggestions for improving things are welcome. But I don't think it will fly to make int+int yield a long.
 BTW: this means byte and short are not closed under arithmetic 
 operations, which drastically limit their usefulness.

I think they shouldn't be closed because they overflow for relatively small values.

Andrei, consider anyone who want to do image manipulation (or computer vision, video, etc). Since images are one of the few areas that use bytes extensively, and have to map back into themselves, they are basically sorry out of luck.

I understand, but also keep in mind that making small integers closed is the less safe option. So we'd be hurting everyone for the sake of the image manipulation folks. Andrei

useful...though I admit that of the common 2^n basis bytes are the most useful, I've often needed base three or other. (Probably not worth the effort, but modular arithmetic on 2^n for n from 1 to, say 64 would be reasonably easy.
Jul 08 2009
prev sibling parent =?ISO-8859-15?Q?=22J=E9r=F4me_M=2E_Berger=22?= <jeberger free.fr> writes:
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: quoted-printable

Robert Jacques wrote:
 On Tue, 07 Jul 2009 03:33:24 -0400, Andrei Alexandrescu=20
 <SeeWebsiteForEmail erdani.org> wrote:
 Robert Jacques wrote:
 BTW: this means byte and short are not closed under arithmetic=20
 operations, which drastically limit their usefulness.

I think they shouldn't be closed because they overflow for relatively =


 small values.

Andrei, consider anyone who want to do image manipulation (or computer =

 vision, video, etc). Since images are one of the few areas that use=20
 bytes extensively, and have to map back into themselves, they are=20
 basically sorry out of luck.
=20

don't want the overflow to wrap but instead to be clipped. Having=20 the compiler notify you when there is a risk of an overflow and=20 require you to be explicit in how you want it to be handled is=20 actually a good thing IMO. Jerome --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Jul 07 2009
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Robert Jacques wrote:
 Another inconsistency:
 
     byte[] x,y,z;
     z[] = x[]*y[]; // Compiles

Bugzilla is its name. Andrei
Jul 07 2009
prev sibling next sibling parent Brad Roberts <braddr puremagic.com> writes:
 That's really cool. But I don't think that's actually happening (Or
 are these the bugs you're talking about?):

     byte x,y;
     short z;
     z = x+y;  // Error: cannot implicitly convert expression
 (cast(int)x + cast(int)y) of type int to short

     // Repeat for ubyte, bool, char, wchar and *, -, /

http://d.puremagic.com/issues/show_bug.cgi?id=3147 You may want to add to it.

Before going too far, consider: byte x, y, z; short a; a = x + y + z; How far should the logic go?
Jul 07 2009
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Jarrett Billingsley wrote:
 The only thing is: why doesn't _this_ fail, then?
 
 int x, y, z;
 z = x + y;
 
 I'm sure it's out of convenience, but what about in ten, fifteen years
 when 32-bit architectures are a historical relic and there's still
 this hole in the type system?

Well 32-bit architectures may be a historical relic but I don't think 32-bit integers are. And I think it would be too disruptive a change to promote results of arithmetic operation between integers to long.
 The same argument applies for the implicit conversions between int and
 uint.  If you're going to do that, why not have implicit conversions
 between long and ulong on 64-bit platforms?

This is a different beast. We simply couldn't devise a satisfactory scheme within the constraints we have. No simple solution we could think of has worked, nor have a number of sophisticated solutions. Ideas would be welcome, though I need to warn you that the devil is in the details so the ideas must be fully baked; too many good sounding high-level ideas fail when analyzed in detail. Andrei
Jul 07 2009
parent reply "Nick Sabalausky" <a a.a> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:h2vprn$1t77$1 digitalmars.com...
 This is a different beast. We simply couldn't devise a satisfactory scheme 
 within the constraints we have. No simple solution we could think of has 
 worked, nor have a number of sophisticated solutions. Ideas would be 
 welcome, though I need to warn you that the devil is in the details so the 
 ideas must be fully baked; too many good sounding high-level ideas fail 
 when analyzed in detail.

I assume then that you've looked at something lke C#'s checked/unchecked scheme and someone's (I forget who) idea of expanding that to something like unchecked(overflow, sign)? What was wrong with those sorts of things?
Jul 07 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Nick Sabalausky wrote:
 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
 news:h2vprn$1t77$1 digitalmars.com...
 This is a different beast. We simply couldn't devise a satisfactory scheme 
 within the constraints we have. No simple solution we could think of has 
 worked, nor have a number of sophisticated solutions. Ideas would be 
 welcome, though I need to warn you that the devil is in the details so the 
 ideas must be fully baked; too many good sounding high-level ideas fail 
 when analyzed in detail.

I assume then that you've looked at something lke C#'s checked/unchecked scheme and someone's (I forget who) idea of expanding that to something like unchecked(overflow, sign)? What was wrong with those sorts of things?

An unchecked-based approach was not on the table. Our focus was more on checking things properly, instead of over-checking and then relying on "unchecked" to disable that. Andrei
Jul 07 2009
next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Andrei Alexandrescu wrote:
 Nick Sabalausky wrote:
 I assume then that you've looked at something lke C#'s 
 checked/unchecked scheme and someone's (I forget who) idea of 
 expanding that to something like unchecked(overflow, sign)? What was 
 wrong with those sorts of things? 

An unchecked-based approach was not on the table. Our focus was more on checking things properly, instead of over-checking and then relying on "unchecked" to disable that.

We also should be careful not to turn D into a "bondage and discipline" language that nobody will use unless contractually forced to.
Jul 07 2009
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:h30907$2lk0$3 digitalmars.com...
 Nick Sabalausky wrote:
 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
 news:h2vprn$1t77$1 digitalmars.com...
 This is a different beast. We simply couldn't devise a satisfactory 
 scheme within the constraints we have. No simple solution we could think 
 of has worked, nor have a number of sophisticated solutions. Ideas would 
 be welcome, though I need to warn you that the devil is in the details 
 so the ideas must be fully baked; too many good sounding high-level 
 ideas fail when analyzed in detail.

I assume then that you've looked at something lke C#'s checked/unchecked scheme and someone's (I forget who) idea of expanding that to something like unchecked(overflow, sign)? What was wrong with those sorts of things?

An unchecked-based approach was not on the table. Our focus was more on checking things properly, instead of over-checking and then relying on "unchecked" to disable that.

C#'s scheme supports the opposite as well. Not checking for the stuff where you mostly don't care, and then "checked" to enable the checks in the spots where you do care. And then there's been the suggestions for finer-graned control for whevever that's needed.
Jul 07 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Nick Sabalausky wrote:
 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
 news:h30907$2lk0$3 digitalmars.com...
 Nick Sabalausky wrote:
 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
 news:h2vprn$1t77$1 digitalmars.com...
 This is a different beast. We simply couldn't devise a satisfactory 
 scheme within the constraints we have. No simple solution we could think 
 of has worked, nor have a number of sophisticated solutions. Ideas would 
 be welcome, though I need to warn you that the devil is in the details 
 so the ideas must be fully baked; too many good sounding high-level 
 ideas fail when analyzed in detail.

scheme and someone's (I forget who) idea of expanding that to something like unchecked(overflow, sign)? What was wrong with those sorts of things?

checking things properly, instead of over-checking and then relying on "unchecked" to disable that.

C#'s scheme supports the opposite as well. Not checking for the stuff where you mostly don't care, and then "checked" to enable the checks in the spots where you do care. And then there's been the suggestions for finer-graned control for whevever that's needed.

Well unfortunately that all wasn't considered. If properly championed, it would. I personally consider the current approach superior because it's safe and unobtrusive. Andrei
Jul 07 2009
prev sibling parent reply Leandro Lucarella <llucax gmail.com> writes:
Andrei Alexandrescu, el  7 de julio a las 00:48 me escribiste:
 Robert Jacques wrote:
On Mon, 06 Jul 2009 01:05:10 -0400, Walter Bright <newshound1 digitalmars.com> 
wrote:
Something for everyone here.


http://www.digitalmars.com/d/1.0/changelog.html
http://ftp.digitalmars.com/dmd.1.046.zip


http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.031.zip

Also, I'm not sure if this is a bug or a feature with regard to the new integer rules: byte x,y,z; z = x+y; // Error: cannot implicitly convert expression (cast(int)x + cast(int)y) of type int to byte which makes sense, in that a byte can overflow, but also doesn't make sense, since integer behaviour is different.

Walter has implemented an ingenious scheme for disallowing narrowing conversions while at the same time minimizing the number of casts required. He hasn't explained it, so I'll sketch an explanation here. The basic approach is "value range propagation": each expression is associated with a minimum possible value and a maximum possible value. As complex expressions are assembled out of simpler expressions, the ranges are computed and propagated. For example, this code compiles: int x = whatever(); bool y = x & 1; The compiler figures that the range of x is int.min to int.max, the range of 1 is 1 to 1, and (here's the interesting part), the range of x & 1 is 0 to 1. So it lets the code go through. However, it won't allow this: int x = whatever(); bool y = x & 2; because x & 2 has range between 0 and 2, which won't fit in a bool. The approach generalizes to arbitrary complex expressions. Now here's the trick though: the value range propagation is local, i.e. all ranges are forgotten beyond one expression. So as soon as you move on to the next statement, the ranges have been forgotten. Why? Simply put, increased implementation difficulties and increased compiler memory footprint for diminishing returns. Both Walter and I noticed that expression-level value range propagation gets rid of all dangerous cases and the vast majority of required casts. Indeed, his test suite, Phobos, and my own codebase required surprisingly few changes with the new scheme. Moreover, we both discovered bugs due to the new feature, so we're happy with the status quo. Now consider your code: byte x,y,z; z = x+y; The first line initializes all values to zero. In an intra-procedural value range propagation, these zeros would be propagated to the next statement, which would range-check. However, in the current approach, the ranges of x, y, and z are forgotten at the first semicolon. Then, x+y has range -byte.min-byte.min up to byte.max+byte.max as far as the type checker knows. That would fit in a short (and by the way I just found a bug with that occasion) but not in a byte.

This seems nice. I think it would be nice if this kind of things are commented in the NG before a compiler release, to allow community input and discussion. I think this kind of things are the ones that deserves some kind of RFC (like Python PEPs) like someone suggested a couple of days ago. -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ----------------------------------------------------------------------------
Jul 07 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Leandro Lucarella wrote:
 This seems nice. I think it would be nice if this kind of things are
 commented in the NG before a compiler release, to allow community input
 and discussion.

Yup, that's what happened to case :o).
 I think this kind of things are the ones that deserves some kind of RFC
 (like Python PEPs) like someone suggested a couple of days ago.

I think that's a good idea. Who has the time and resources to set that up? Andrei
Jul 07 2009
parent reply Leandro Lucarella <llucax gmail.com> writes:
Andrei Alexandrescu, el  7 de julio a las 10:56 me escribiste:
 Leandro Lucarella wrote:
This seems nice. I think it would be nice if this kind of things are
commented in the NG before a compiler release, to allow community input
and discussion.

Yup, that's what happened to case :o).
I think this kind of things are the ones that deserves some kind of RFC
(like Python PEPs) like someone suggested a couple of days ago.

I think that's a good idea. Who has the time and resources to set that up?

What's wrong with the Wiki? -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- He andáu muchos caminos, muchos caminos he andáu, Chile tiene el buen vino y Suecia, el bacalao. Esta'o Unido tiene el hot do', Cuba tiene el mojito, Guatemala, el cornalito y Brasil la feishoada.
Jul 07 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Leandro Lucarella wrote:
 Andrei Alexandrescu, el  7 de julio a las 10:56 me escribiste:
 Leandro Lucarella wrote:
 This seems nice. I think it would be nice if this kind of things are
 commented in the NG before a compiler release, to allow community input
 and discussion.

 I think this kind of things are the ones that deserves some kind of RFC
 (like Python PEPs) like someone suggested a couple of days ago.


What's wrong with the Wiki?

Where's the link? Andrei
Jul 07 2009
parent reply Leandro Lucarella <llucax gmail.com> writes:
Andrei Alexandrescu, el  7 de julio a las 15:12 me escribiste:
 Leandro Lucarella wrote:
Andrei Alexandrescu, el  7 de julio a las 10:56 me escribiste:
Leandro Lucarella wrote:
This seems nice. I think it would be nice if this kind of things are
commented in the NG before a compiler release, to allow community input
and discussion.

I think this kind of things are the ones that deserves some kind of RFC
(like Python PEPs) like someone suggested a couple of days ago.



Where's the link?

I mean the D Wiki! http://prowiki.org/wiki4d/wiki.cgi (BTW, nice job with the Wiki for whoever did it, I don't remember who was putting a lot of work on improving the Wiki, but it's really much better organized now) I think we can add a DIP (D Improvement Proposal =) section in the "Language Development" section: http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- Ya ni el cielo me quiere, ya ni la muerte me visita Ya ni el sol me calienta, ya ni el viento me acaricia
Jul 07 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Leandro Lucarella wrote:
 Andrei Alexandrescu, el  7 de julio a las 15:12 me escribiste:
 Leandro Lucarella wrote:
 Andrei Alexandrescu, el  7 de julio a las 10:56 me escribiste:
 Leandro Lucarella wrote:
 This seems nice. I think it would be nice if this kind of things are
 commented in the NG before a compiler release, to allow community input
 and discussion.

 I think this kind of things are the ones that deserves some kind of RFC
 (like Python PEPs) like someone suggested a couple of days ago.




I mean the D Wiki! http://prowiki.org/wiki4d/wiki.cgi (BTW, nice job with the Wiki for whoever did it, I don't remember who was putting a lot of work on improving the Wiki, but it's really much better organized now) I think we can add a DIP (D Improvement Proposal =) section in the "Language Development" section: http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel

Great idea. I can only hope the technical level will be much higher than the two threads related to switch. Andrei
Jul 07 2009
parent Leandro Lucarella <llucax gmail.com> writes:
Andrei Alexandrescu, el  7 de julio a las 16:54 me escribiste:
 Leandro Lucarella wrote:
Andrei Alexandrescu, el  7 de julio a las 15:12 me escribiste:
Leandro Lucarella wrote:
Andrei Alexandrescu, el  7 de julio a las 10:56 me escribiste:
Leandro Lucarella wrote:
This seems nice. I think it would be nice if this kind of things are
commented in the NG before a compiler release, to allow community input
and discussion.

I think this kind of things are the ones that deserves some kind of RFC
(like Python PEPs) like someone suggested a couple of days ago.




http://prowiki.org/wiki4d/wiki.cgi (BTW, nice job with the Wiki for whoever did it, I don't remember who was putting a lot of work on improving the Wiki, but it's really much better organized now) I think we can add a DIP (D Improvement Proposal =) section in the "Language Development" section: http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel

Great idea. I can only hope the technical level will be much higher than the two threads related to switch.

I think proposals should be published there but discussed here, so be ready for all kind of discussions (the ones you like and the ones you don't =). From time to time, when there is some kind of agreement, the proposal should be updated (with a new "revision number"). I just went wild and added a DIP index[1] and the first DIP (DIP1), a template for creating new DIPs[2]. This are just rought drafts, but I think they are good enought to start with. Comments are apreciated. I will post a "formal" announcement too. [1] http://www.prowiki.org/wiki4d/wiki.cgi?DiPs [2] http://www.prowiki.org/wiki4d/wiki.cgi?DiP1 -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- "The Guinness Book of Records" holds the record for being the most stolen book in public libraries
Jul 07 2009
prev sibling parent Leandro Lucarella <llucax gmail.com> writes:
Jesse Phillips, el  8 de julio a las 01:27 me escribiste:
 On Tue, 07 Jul 2009 18:43:41 -0300, Leandro Lucarella wrote:
 
 
 (BTW, nice job with the Wiki for whoever did it, I don't remember who
 was putting a lot of work on improving the Wiki, but it's really much
 better organized now)

Hi, thanks.
 I think we can add a DIP (D Improvement Proposal =) section in the
 "Language Development" section:
 http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel

I was reusing the Discussion and Ideas for these things, but DIP could be for those brought forward by the involved few of accepting ideas, since Ideas and Discussion will likely end up with a lot of old or less thought out ideas. http://www.prowiki.org/wiki4d/wiki.cgi?IdeaDiscussion

Oops! I'm sorry I missed that. =/ Anyways I think that page serves as a way to index interesting discussions in the NG. The idea of DIPs is to be the other way around. You first present the idea as a DIP, the it's discussed. When you get sufficient input, you update the DIP with a new revision number, then you put it for discussion again in the NG. You repeat that until it's Accepted or Rejected (or you give up and Withdrawn it =). -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- Pitzulino! Pitzulino! Todos a cantar por el tubo! Pitzulino! Pitzulino! Todos a cantar por el codo!
Jul 08 2009
prev sibling next sibling parent "Robert Jacques" <sandford jhu.edu> writes:
On Tue, 07 Jul 2009 01:48:41 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 Robert Jacques wrote:
 On Mon, 06 Jul 2009 01:05:10 -0400, Walter Bright  
 <newshound1 digitalmars.com> wrote:

 Something for everyone here.


 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.046.zip


 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.031.zip

Also, I'm not sure if this is a bug or a feature with regard to the new integer rules: byte x,y,z; z = x+y; // Error: cannot implicitly convert expression (cast(int)x + cast(int)y) of type int to byte which makes sense, in that a byte can overflow, but also doesn't make sense, since integer behaviour is different.

Walter has implemented an ingenious scheme for disallowing narrowing conversions while at the same time minimizing the number of casts required. He hasn't explained it, so I'll sketch an explanation here. The basic approach is "value range propagation": each expression is associated with a minimum possible value and a maximum possible value. As complex expressions are assembled out of simpler expressions, the ranges are computed and propagated. For example, this code compiles: int x = whatever(); bool y = x & 1; The compiler figures that the range of x is int.min to int.max, the range of 1 is 1 to 1, and (here's the interesting part), the range of x & 1 is 0 to 1. So it lets the code go through. However, it won't allow this: int x = whatever(); bool y = x & 2; because x & 2 has range between 0 and 2, which won't fit in a bool. The approach generalizes to arbitrary complex expressions. Now here's the trick though: the value range propagation is local, i.e. all ranges are forgotten beyond one expression. So as soon as you move on to the next statement, the ranges have been forgotten. Why? Simply put, increased implementation difficulties and increased compiler memory footprint for diminishing returns. Both Walter and I noticed that expression-level value range propagation gets rid of all dangerous cases and the vast majority of required casts. Indeed, his test suite, Phobos, and my own codebase required surprisingly few changes with the new scheme. Moreover, we both discovered bugs due to the new feature, so we're happy with the status quo. Now consider your code: byte x,y,z; z = x+y; The first line initializes all values to zero. In an intra-procedural value range propagation, these zeros would be propagated to the next statement, which would range-check. However, in the current approach, the ranges of x, y, and z are forgotten at the first semicolon. Then, x+y has range -byte.min-byte.min up to byte.max+byte.max as far as the type checker knows. That would fit in a short (and by the way I just found a bug with that occasion) but not in a byte.

That's really cool. But I don't think that's actually happening (Or are these the bugs you're talking about?): byte x,y; short z; z = x+y; // Error: cannot implicitly convert expression (cast(int)x + cast(int)y) of type int to short // Repeat for ubyte, bool, char, wchar and *, -, / And by that logic shouldn't the following happen? int x,y; int z; z = x+y; // Error: cannot implicitly convert expression (cast(long)x + cast(long)y) of type long to int i.e. why the massive inconsistency between byte/short and int/long? (This is particularly a pain for generic i.e. templated code) BTW: this means byte and short are not closed under arithmetic operations, which drastically limit their usefulness.
Jul 06 2009
prev sibling next sibling parent "Robert Jacques" <sandford jhu.edu> writes:
On Tue, 07 Jul 2009 02:35:44 -0400, Robert Jacques <sandford jhu.edu>  
wrote:

 On Tue, 07 Jul 2009 01:48:41 -0400, Andrei Alexandrescu  
 <SeeWebsiteForEmail erdani.org> wrote:

 Robert Jacques wrote:
 On Mon, 06 Jul 2009 01:05:10 -0400, Walter Bright  
 <newshound1 digitalmars.com> wrote:

 Something for everyone here.


 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.046.zip


 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.031.zip

Also, I'm not sure if this is a bug or a feature with regard to the new integer rules: byte x,y,z; z = x+y; // Error: cannot implicitly convert expression (cast(int)x + cast(int)y) of type int to byte which makes sense, in that a byte can overflow, but also doesn't make sense, since integer behaviour is different.

Walter has implemented an ingenious scheme for disallowing narrowing conversions while at the same time minimizing the number of casts required. He hasn't explained it, so I'll sketch an explanation here. The basic approach is "value range propagation": each expression is associated with a minimum possible value and a maximum possible value. As complex expressions are assembled out of simpler expressions, the ranges are computed and propagated. For example, this code compiles: int x = whatever(); bool y = x & 1; The compiler figures that the range of x is int.min to int.max, the range of 1 is 1 to 1, and (here's the interesting part), the range of x & 1 is 0 to 1. So it lets the code go through. However, it won't allow this: int x = whatever(); bool y = x & 2; because x & 2 has range between 0 and 2, which won't fit in a bool. The approach generalizes to arbitrary complex expressions. Now here's the trick though: the value range propagation is local, i.e. all ranges are forgotten beyond one expression. So as soon as you move on to the next statement, the ranges have been forgotten. Why? Simply put, increased implementation difficulties and increased compiler memory footprint for diminishing returns. Both Walter and I noticed that expression-level value range propagation gets rid of all dangerous cases and the vast majority of required casts. Indeed, his test suite, Phobos, and my own codebase required surprisingly few changes with the new scheme. Moreover, we both discovered bugs due to the new feature, so we're happy with the status quo. Now consider your code: byte x,y,z; z = x+y; The first line initializes all values to zero. In an intra-procedural value range propagation, these zeros would be propagated to the next statement, which would range-check. However, in the current approach, the ranges of x, y, and z are forgotten at the first semicolon. Then, x+y has range -byte.min-byte.min up to byte.max+byte.max as far as the type checker knows. That would fit in a short (and by the way I just found a bug with that occasion) but not in a byte.

That's really cool. But I don't think that's actually happening (Or are these the bugs you're talking about?): byte x,y; short z; z = x+y; // Error: cannot implicitly convert expression (cast(int)x + cast(int)y) of type int to short // Repeat for ubyte, bool, char, wchar and *, -, / And by that logic shouldn't the following happen? int x,y; int z; z = x+y; // Error: cannot implicitly convert expression (cast(long)x + cast(long)y) of type long to int i.e. why the massive inconsistency between byte/short and int/long? (This is particularly a pain for generic i.e. templated code) BTW: this means byte and short are not closed under arithmetic operations, which drastically limit their usefulness.

Another inconsistency: byte[] x,y,z; z[] = x[]*y[]; // Compiles
Jul 07 2009
prev sibling next sibling parent Don <nospam nospam.com> writes:
Walter Bright wrote:
 Something for everyone here.
 
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.046.zip
 
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.031.zip

Why is 'final switch' required? Another possible way of dealing with the same issue would be: switch(e) { case E.A: blah; break; case E.B: blah; break; ... default: assert(0); } Ie, if switch is over an enum type, and the 'default' clause consists only of assert(0), the compiler could generate a warning if some of the possible enum values never appear in a case statement. It's not quite the same as 'final switch', but I think it captures most of the use cases.
Jul 07 2009
prev sibling next sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Tue, Jul 7, 2009 at 11:15 AM, Jarrett
Billingsley<jarrett.billingsley gmail.com> wrote:
 On Tue, Jul 7, 2009 at 1:48 AM, Andrei
 Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:
 Walter has implemented an ingenious scheme for disallowing narrowing
 conversions while at the same time minimizing the number of casts requir=


 He hasn't explained it, so I'll sketch an explanation here.

 The basic approach is "value range propagation": each expression is
 associated with a minimum possible value and a maximum possible value. A=


 complex expressions are assembled out of simpler expressions, the ranges=


 computed and propagated.

 For example, this code compiles:

 int x =3D whatever();
 bool y =3D x & 1;

 The compiler figures that the range of x is int.min to int.max, the rang=


 1 is 1 to 1, and (here's the interesting part), the range of x & 1 is 0 =


 1. So it lets the code go through. However, it won't allow this:

 int x =3D whatever();
 bool y =3D x & 2;

 because x & 2 has range between 0 and 2, which won't fit in a bool.

Very cool. =A0:)
 The approach generalizes to arbitrary complex expressions. Now here's th=


 trick though: the value range propagation is local, i.e. all ranges are
 forgotten beyond one expression. So as soon as you move on to the next
 statement, the ranges have been forgotten.

 Why? Simply put, increased implementation difficulties and increased
 compiler memory footprint for diminishing returns. Both Walter and I not=


 that expression-level value range propagation gets rid of all dangerous
 cases and the vast majority of required casts. Indeed, his test suite,
 Phobos, and my own codebase required surprisingly few changes with the n=


 scheme. Moreover, we both discovered bugs due to the new feature, so we'=


 happy with the status quo.

Sounds fairly reasonable.
 Now consider your code:

 byte x,y,z;
 z =3D x+y;

 The first line initializes all values to zero. In an intra-procedural va=


 range propagation, these zeros would be propagated to the next statement=


 which would range-check. However, in the current approach, the ranges of=


 y, and z are forgotten at the first semicolon. Then, x+y has range
 -byte.min-byte.min up to byte.max+byte.max as far as the type checker kn=


 That would fit in a short (and by the way I just found a bug with that
 occasion) but not in a byte.

The only thing is: why doesn't _this_ fail, then? int x, y, z; z =3D x + y; I'm sure it's out of convenience, but what about in ten, fifteen years when 32-bit architectures are a historical relic and there's still this hole in the type system? The same argument applies for the implicit conversions between int and uint. =A0If you're going to do that, why not have implicit conversions between long and ulong on 64-bit platforms?

I think I've confused the mailing list's threading algorithm.
Jul 07 2009
prev sibling next sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Tue, Jul 7, 2009 at 1:48 AM, Andrei
Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:
 Walter has implemented an ingenious scheme for disallowing narrowing
 conversions while at the same time minimizing the number of casts required.
 He hasn't explained it, so I'll sketch an explanation here.

 The basic approach is "value range propagation": each expression is
 associated with a minimum possible value and a maximum possible value. As
 complex expressions are assembled out of simpler expressions, the ranges are
 computed and propagated.

 For example, this code compiles:

 int x = whatever();
 bool y = x & 1;

 The compiler figures that the range of x is int.min to int.max, the range of
 1 is 1 to 1, and (here's the interesting part), the range of x & 1 is 0 to
 1. So it lets the code go through. However, it won't allow this:

 int x = whatever();
 bool y = x & 2;

 because x & 2 has range between 0 and 2, which won't fit in a bool.

Very cool. :)
 The approach generalizes to arbitrary complex expressions. Now here's the
 trick though: the value range propagation is local, i.e. all ranges are
 forgotten beyond one expression. So as soon as you move on to the next
 statement, the ranges have been forgotten.

 Why? Simply put, increased implementation difficulties and increased
 compiler memory footprint for diminishing returns. Both Walter and I noticed
 that expression-level value range propagation gets rid of all dangerous
 cases and the vast majority of required casts. Indeed, his test suite,
 Phobos, and my own codebase required surprisingly few changes with the new
 scheme. Moreover, we both discovered bugs due to the new feature, so we're
 happy with the status quo.

Sounds fairly reasonable.
 Now consider your code:

 byte x,y,z;
 z = x+y;

 The first line initializes all values to zero. In an intra-procedural value
 range propagation, these zeros would be propagated to the next statement,
 which would range-check. However, in the current approach, the ranges of x,
 y, and z are forgotten at the first semicolon. Then, x+y has range
 -byte.min-byte.min up to byte.max+byte.max as far as the type checker knows.
 That would fit in a short (and by the way I just found a bug with that
 occasion) but not in a byte.

The only thing is: why doesn't _this_ fail, then? int x, y, z; z = x + y; I'm sure it's out of convenience, but what about in ten, fifteen years when 32-bit architectures are a historical relic and there's still this hole in the type system? The same argument applies for the implicit conversions between int and uint. If you're going to do that, why not have implicit conversions between long and ulong on 64-bit platforms?
Jul 07 2009
prev sibling next sibling parent "Robert Jacques" <sandford jhu.edu> writes:
On Tue, 07 Jul 2009 03:33:24 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:
 Robert Jacques wrote:
  That's really cool. But I don't think that's actually happening (Or  
 are these the bugs you're talking about?):
      byte x,y;
     short z;
     z = x+y;  // Error: cannot implicitly convert expression  
 (cast(int)x + cast(int)y) of type int to short
      // Repeat for ubyte, bool, char, wchar and *, -, /

http://d.puremagic.com/issues/show_bug.cgi?id=3147 You may want to add to it.

Added. In summary, + * - / % >> >>> don't work for types 8-bits and under. << is inconsistent (x<<1 errors, but x<<y compiles). All the op assigns (+= *= -= /= %= >>= <<= >>>=) and pre/post increments (++ --) compile which is maddeningly inconsistent, particularly when the spec defines ++x as sugar for x = x + 1, which doesn't compile.
 And by that logic shouldn't the following happen?
      int x,y;
     int z;
     z = x+y;  // Error: cannot implicitly convert expression  
 (cast(long)x + cast(long)y) of type long to int

No. Int remains "special", i.e. arithmetic operations on it don't automatically grow to become long.
 i.e. why the massive inconsistency between byte/short and int/long?  
 (This is particularly a pain for generic i.e. templated code)

I don't find it a pain. It's a practical decision.

Andrei, I have a short vector template (think vec!(byte,3), etc) where I've had to wrap the majority lines of code in cast(T)( ... ), because I support bytes and shorts. I find that both a kludge and a pain.
 BTW: this means byte and short are not closed under arithmetic  
 operations, which drastically limit their usefulness.

I think they shouldn't be closed because they overflow for relatively small values.

Andrei, consider anyone who want to do image manipulation (or computer vision, video, etc). Since images are one of the few areas that use bytes extensively, and have to map back into themselves, they are basically sorry out of luck.
Jul 07 2009
prev sibling next sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Tue, Jul 7, 2009 at 11:33 AM, Andrei
Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:
 Well 32-bit architectures may be a historical relic but I don't think 32-bit
 integers are. And I think it would be too disruptive a change to promote
 results of arithmetic operation between integers to long.

 ...

 This is a different beast. We simply couldn't devise a satisfactory scheme
 within the constraints we have. No simple solution we could think of has
 worked, nor have a number of sophisticated solutions. Ideas would be
 welcome, though I need to warn you that the devil is in the details so the
 ideas must be fully baked; too many good sounding high-level ideas fail when
 analyzed in detail.

Hm. Just throwing this out there, as a possible solution for both problems. Suppose you kept the current set of integer types, but made all of them "open" (i.e. byte+byte=short, int+int=long etc.). Furthermore, you made it impossible to implicitly convert between the signed and unsigned types of the same size (the int<>uint hole disappears). But then you introduce two new native-size integer types. Well, we already have them - ptrdiff_t and size_t - but give them nicer names, like word and uword. Unlike the other integer types, these would be implicitly convertible to one another. They'd more or less take the place of 'int' and 'uint' in most code, since most of the time, the size of the integer isn't that important.
Jul 07 2009
prev sibling next sibling parent "Robert Jacques" <sandford jhu.edu> writes:
On Tue, 07 Jul 2009 11:36:26 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:
 Robert Jacques wrote:
  Andrei, I have a short vector template (think vec!(byte,3), etc) where  
 I've had to wrap the majority lines of code in cast(T)( ... ), because  
 I support bytes and shorts. I find that both a kludge and a pain.

Well suggestions for improving things are welcome. But I don't think it will fly to make int+int yield a long.

Suggestion 1: Loft the right hand of the expression (when lofting is valid) to the size of the left hand. i.e. byte a,b,c; c = a + b; => c = a + b; short d; d = a + b; => d = cast(short) a + cast(short) b; int e, f; e = a + b; => e = cast(short) a + cast(short) b; e = a + b + d; => e = cast(int)(cast(short) a + cast(short) b) + cast(int) d; Or e = cast(int) a + (cast(int) b + cast(int)d); long g; g = e + f; => d = cast(long) e + cast(long) f; When choosing operator overloads or auto, prefer the ideal lofted interpretation (as per the new rules, but without the exception for int/long), over truncated variants. i.e. auto h = a + b; => short h = cast(short) a + cast(short) b; This would also properly handled some of the corner/inconsistent cases with the current rules: ubyte i; ushort j; j = -i; => j = -cast(short)i; (This currently evaluates to j = cast(short)(-i); And a += a; is equivalent to a = a + a; and is logically consistent with byte[] k,l,m; m[] = k[] + l[]; Essentially, instead of trying to prevent overflows, except for those from int and long, this scheme attempts to minimize the risk of overflows, including those from int (and long, once cent exists. Maybe long+long=>bigInt?) Suggestion 2: Enable the full rules as part of SafeD and allow non-promotion in un-safe D. Note this could be synergistically combined with Suggestion 1.
 BTW: this means byte and short are not closed under arithmetic  
 operations, which drastically limit their usefulness.

I think they shouldn't be closed because they overflow for relatively small values.

vision, video, etc). Since images are one of the few areas that use bytes extensively, and have to map back into themselves, they are basically sorry out of luck.

I understand, but also keep in mind that making small integers closed is the less safe option. So we'd be hurting everyone for the sake of the image manipulation folks. Andrei

Well, how often does everyone else use bytes?
Jul 07 2009
prev sibling next sibling parent "Robert Jacques" <sandford jhu.edu> writes:
On Tue, 07 Jul 2009 14:16:14 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 Robert Jacques wrote:
 On Tue, 07 Jul 2009 11:36:26 -0400, Andrei Alexandrescu  
 <SeeWebsiteForEmail erdani.org> wrote:
 Robert Jacques wrote:
  Andrei, I have a short vector template (think vec!(byte,3), etc)  
 where I've had to wrap the majority lines of code in cast(T)( ... ),  
 because I support bytes and shorts. I find that both a kludge and a  
 pain.

Well suggestions for improving things are welcome. But I don't think it will fly to make int+int yield a long.

Loft the right hand of the expression (when lofting is valid) to the size of the left hand. i.e.

What does loft mean in this context?

Sorry. loft <=> up-casting. i.e. byte => short => int => long => cent? => bigInt?
 byte a,b,c;
 c = a + b;  => c = a + b;

Unsafe.

So is int + int or long + long. Or float + float for that matter. My point is that if a programmer is assigning a value to a byte (or short or int or long) then they are willing to accept the accociated over/under flow errors of that type.
 short d;
 d = a + b;  => d = cast(short) a + cast(short) b;

Should work today modulo bugs.
 int e, f;
 e = a + b;  => e = cast(short) a + cast(short) b;

Why cast to short? e has type int.

Opps. You're right. (I was thinking of the new rules, not my suggestion) Should be: e = a + b; => e = cast(int) a + cast(int) b;
 e = a + b + d; => e = cast(int)(cast(short) a + cast(short) b) +  
 cast(int) d; Or e = cast(int) a + (cast(int) b + cast(int)d);

I don't understand this.

Same "Opps. You're right." as above. e = a + b + d; => e = cast(int) a + cast(int) b + cast(int) d;
 long g;
 g = e + f;  => d = cast(long) e + cast(long) f;

Works today.

Wrong. I just tested this and what happens today is: g = cast(long)(e+f); And this is (I think) correct behavior according to the new rules and not a bug. In the new rules int is special, in this suggestion, it's not.
 When choosing operator overloads or auto, prefer the ideal lofted  
 interpretation (as per the new rules, but without the exception for  
 int/long), over truncated variants. i.e.
 auto h = a + b; => short h = cast(short) a + cast(short) b;

This would yield semantics incompatible with C expressions.

How so? The auto rule is identical to the "new rules". The overload rule is identical to the "new rules", except when no match can be found, in which case it tries to "relax" the expression to a smaller number of bits.
 This would also properly handled some of the corner/inconsistent cases  
 with the current rules:
 ubyte  i;
 ushort j;
 j = -i;    => j = -cast(short)i; (This currently evaluates to j =  
 cast(short)(-i);

That should not compile, sigh. Walter wouldn't listen...
 And
 a += a;
 is equivalent to
 a = a + a;

Well not quite equivalent. In D2 they aren't. The former clarifies that you want to reassign the expression to a, and no cast is necessary. The latter would not compile if a is shorter than int.

I understand, but that dichotomy increases the cognitive load on the programmer. Also, there's the issue of byte x; ++x; which is defined in the spec as being equvilent to x = x + 1;
 and is logically consistent with
 byte[] k,l,m;
 m[] = k[] + l[];
  Essentially, instead of trying to prevent overflows, except for those  
 from int and long, this scheme attempts to minimize the risk of  
 overflows, including those from int (and long, once cent exists. Maybe  
 long+long=>bigInt?)

But if you close operations for types smaller than int, you end up with a scheme even more error-prone that C!

Since C (IIRC) always evaluates "x+x" in the manner most prone to causing overflows, no matter the type, a scheme can't be more error-prone than C (at the instruction level). However, it can be less consistent, which I grant can lead to higher level logic errors. (BTW, operations for types smaller than int are closed (by my non-mathy definition) in C) The new rules are definitely an improvement over C, but they make byte/ubyte/short/ushort second class citizens, because practically every assignment requires a cast: byte a,b,c; c = cast(byte) a + b; And if it weren't for compatibility issues, it would almost be worth it to remove them completely.
Jul 07 2009
prev sibling next sibling parent "Robert Jacques" <sandford jhu.edu> writes:
On Tue, 07 Jul 2009 18:05:26 -0400, Derek Parnell <derek psych.ward> wrote:

 On Tue, 07 Jul 2009 14:05:33 -0400, Robert Jacques wrote:


 Well, how often does everyone else use bytes?

Cryptography, in my case.

Cool. If you don't mind, what's you're take new rules? (As different use cases and points of view are very valuable)
Jul 07 2009
prev sibling next sibling parent "Robert Jacques" <sandford jhu.edu> writes:
On Tue, 07 Jul 2009 20:48:50 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 Robert Jacques wrote:
 long g;
 g = e + f;  => d = cast(long) e + cast(long) f;

Works today.

g = cast(long)(e+f); And this is (I think) correct behavior according to the new rules and not a bug. In the new rules int is special, in this suggestion, it's not.

I think this is a good idea that would improve things. I think, however, it would be troublesome to implement because expressions are typed bottom-up. The need here is to "teleport" type information from the assignment node to the addition node, which is downwards. And I'm not sure how this would generalize to other operators beyond "=". Andrei

Hmm... why can't multiple expressions be built simultaneously and then the best chosen once the assignment/function call/etc is reached? This would also have the benifet of paving the way for polysemous values & expressions.
Jul 07 2009
prev sibling next sibling parent Jesse Phillips <jessekphillips gmail.com> writes:
On Tue, 07 Jul 2009 18:43:41 -0300, Leandro Lucarella wrote:

 
 (BTW, nice job with the Wiki for whoever did it, I don't remember who
 was putting a lot of work on improving the Wiki, but it's really much
 better organized now)

Hi, thanks.
 I think we can add a DIP (D Improvement Proposal =) section in the
 "Language Development" section:
 http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel

I was reusing the Discussion and Ideas for these things, but DIP could be for those brought forward by the involved few of accepting ideas, since Ideas and Discussion will likely end up with a lot of old or less thought out ideas. http://www.prowiki.org/wiki4d/wiki.cgi?IdeaDiscussion
Jul 07 2009
prev sibling next sibling parent "Robert Jacques" <sandford jhu.edu> writes:
On Tue, 07 Jul 2009 21:21:47 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 Robert Jacques wrote:
 On Tue, 07 Jul 2009 20:48:50 -0400, Andrei Alexandrescu  
 <SeeWebsiteForEmail erdani.org> wrote:

 Robert Jacques wrote:
 long g;
 g = e + f;  => d = cast(long) e + cast(long) f;

Works today.

g = cast(long)(e+f); And this is (I think) correct behavior according to the new rules and not a bug. In the new rules int is special, in this suggestion, it's not.

I think this is a good idea that would improve things. I think, however, it would be troublesome to implement because expressions are typed bottom-up. The need here is to "teleport" type information from the assignment node to the addition node, which is downwards. And I'm not sure how this would generalize to other operators beyond "=". Andrei

the best chosen once the assignment/function call/etc is reached? This would also have the benifet of paving the way for polysemous values & expressions.

Anything can be done... in infinite time with infinite resources. :o) Andrei

:) Well, weren't polysemous expressions already in the pipeline somewhere?
Jul 07 2009
prev sibling next sibling parent "Robert Jacques" <sandford jhu.edu> writes:
On Tue, 07 Jul 2009 21:05:45 -0400, Walter Bright  =

<newshound1 digitalmars.com> wrote:

 Andrei Alexandrescu wrote:
 Robert Jacques wrote:
 long g;
 g =3D e + f;  =3D> d =3D cast(long) e + cast(long) f;

Works today.

Wrong. I just tested this and what happens today is: g =3D cast(long)(e+f); And this is (I think) correct behavior according to the new rules an=



 not a bug. In the new rules int is special, in this suggestion, it's=



 not.



 however, it would be troublesome to implement because expressions are=


 typed bottom-up. The need here is to "teleport" type information from=


 the assignment node to the addition node, which is downwards. And I'm=


 not sure how this would generalize to other operators beyond "=3D".

It's also troublesome because it would silently produce different =

 answers than C would.

Please, correct me if I'm wrong, but it seems C works by promoting = byte/short/etc to int and then casting back down if need be. (Something = = tells me this wasn't always true) So (I think) the differences would be = = limited to integer expressions assigned to longs. Also, doing this 'righ= t' = might be important to 64-bit platforms. Actually, after finding and skiming the C spec (from = http://frama-c.cea.fr/download/acsl_1.4.pdf via wikipedia) " 2.2.3 Typing The language of logic expressions is typed (as in multi-sorted first-ord= er = logic). Types are either C types or logic types defined as follows: =0F ?mathematical? types: integer for unbounded, mathematical integers, = real = for real numbers, boolean for booleans (with values written \true and \false); =0F logic types introduced by the specification writer (see Section 2.6)= . There are implicit coercions for numeric types: =0F C integral types char, short, int and long, signed or unsigned, are = all = subtypes of type integer; =0F integer is itself a subtype of type real; =0F C types float and double are subtypes of type real. ... 2.2.4 Integer arithmetic and machine integers The following integer arithmetic operations apply to mathematical = integers: addition, subtraction, multiplication, unary minus. The value of a C variable of an integral type is promoted t= o = a mathematical integer. As a consequence, there is no such thing as "arithmetic overflo= w" = in logic expressions. Division and modulo are also mathematical operations, which coincide wit= h = the corresponding C operations on C machine integers, thus following the ANSI C99 convention= s. = In particular, these are not the usual mathematical Euclidean division and remainder. Generally = speaking, division rounds the result towards zero. The results are not specified if divisor is zero; otherwis= e = if q and r are the quotient and the remainder of n divided by d then:" " So by the spec (and please correct me if I'm reading this wrong) g =3D e + f =3D> g =3D cast(long)( cast(integer)e + cast(integer)f ); where integer is unbounded in bits (and therefore has no overflow) therefore g =3D e + f; =3D> d =3D cast(long) e + cast(long) f; is more in keeping with the spec than g =3D cast(long)(e+f); in terms of a practical implementation, since there's less possibility f= or = overflow error. (Caveat: most 32-bit compilers probably defaulted integer to int, though= = 64-bit compilers are probably defaulting integer to long.)
Jul 07 2009
prev sibling next sibling parent reply "Lionello Lunesu" <lionello lunesu.remove.com> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:h2s0me$30f2$1 digitalmars.com...
 Something for everyone here.


 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.046.zip


 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.031.zip

Great release, thanks to all those that have contributed to it! Walter, since the lib/include folders were split according to OS, the dmd2 zip consistently has an extensionless "lib" file in the dmd2 folder. This is because of the 'install' target in win32.mak that would previously copy phobos.lib and gcstub.obj to the lib folder, but now copies their contents to a file called "lib" instead. I've made a patch and attached it to http://d.puremagic.com/issues/show_bug.cgi?id=3153 L.
Jul 07 2009
next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Thanks.
Jul 07 2009
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"Lionello Lunesu" <lionello lunesu.remove.com> wrote in message 
news:h30vss$pmo$1 digitalmars.com...
 Walter, since the lib/include folders were split according to OS, the dmd2 
 zip consistently has an extensionless "lib" file in the dmd2 folder.

It's also in D1.
Jul 07 2009
prev sibling next sibling parent "Robert Jacques" <sandford jhu.edu> writes:
On Tue, 07 Jul 2009 23:01:58 -0400, Walter Bright  
<newshound1 digitalmars.com> wrote:
 Robert Jacques wrote:
 (Caveat: most 32-bit compilers probably defaulted integer to int,  
 though 64-bit compilers are probably defaulting integer to long.)

All 32 bit C compilers defaulted int to 32 bits. 64 bit C compilers are setting int at 32 bits for sensible compatibility reasons.

But are the 64-bit compilers setting the internal "integer" type to 32 or 64 bits? (I'm not running any 64-bit OSes at the moment to test this)
Jul 07 2009
prev sibling next sibling parent "Robert Jacques" <sandford jhu.edu> writes:
On Wed, 08 Jul 2009 00:08:13 -0400, Brad Roberts <braddr puremagic.com>  
wrote:

 Walter Bright wrote:
 Robert Jacques wrote:
 On Tue, 07 Jul 2009 23:01:58 -0400, Walter Bright
 <newshound1 digitalmars.com> wrote:
 Robert Jacques wrote:
 (Caveat: most 32-bit compilers probably defaulted integer to int,
 though 64-bit compilers are probably defaulting integer to long.)

All 32 bit C compilers defaulted int to 32 bits. 64 bit C compilers are setting int at 32 bits for sensible compatibility reasons.

But are the 64-bit compilers setting the internal "integer" type to 32 or 64 bits? (I'm not running any 64-bit OSes at the moment to test this)

Not that I've seen. I'd be very surprised if any did.

 From wikipedia: http://en.wikipedia.org/wiki/64-bit

model short int long llong ptrs Sample operating systems LLP64 16 32 32 64 64 Microsoft Win64 (X64/IA64) LP64 16 32 64 64 64 Most UNIX and UNIX-like systems (Solaris, Linux, etc) ILP64 16 64 64 64 64 HAL SILP64 64 64 64 64 64 ?

Thanks, but what we're looking for is is what format the data is in in register. For example, in 32-bit C, bytes/shorts are computed as ints and truncated back down. I've found some references to 64-bit native integers in the CLI spec, but nothing definative. The question boils down to is b == 0 or not: int a = 2147483647; long b = a+a+2; // or long long depending on platform
Jul 07 2009
prev sibling next sibling parent reply Leandro Lucarella <llucax gmail.com> writes:
Walter Bright, el  5 de julio a las 22:05 me escribiste:
 Something for everyone here.
 
 
 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.046.zip
 
 
 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.031.zip

I incidentally went through all the D2 bug reports that had being fixed in this release and I was really surprised about how much of them had patches by Don (the vast majority!). Thanks Don! I think it's great that more people are becoming major D contributors. -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- MP: Cómo está, estimado Bellini? B: Muy bien, Mario, astrologando. MP: Qué tengo? B: Un balcón-terraza. MP: No, en mi mano, Bellini... B: Un secarropas! MP: No, escuche bien, eh. Tiene B: El circo de Moscú. números. MP: No Bellini. Toma medidas. B: Un ministro. MP: No Bellini, eh! Algunas son B: Una modelo, Mario! de plástico y otras de madera. MP: No, Bellini, no y no! -- El Gran Bellini (Mario Podestá con una regla)
Jul 08 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Leandro Lucarella wrote:
 Walter Bright, el  5 de julio a las 22:05 me escribiste:
 Something for everyone here.


 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.046.zip


 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.031.zip

I incidentally went through all the D2 bug reports that had being fixed in this release and I was really surprised about how much of them had patches by Don (the vast majority!). Thanks Don! I think it's great that more people are becoming major D contributors.

Don is awesome and a good example to follow! Andrei P.S. With the help of a dictionary I think I figured most of this joke: MP: Cómo está, estimado Bellini? B: Muy bien, Mario, astrologando. MP: Qué tengo? B: Un balcón-terraza. MP: No, en mi mano, Bellini... B: Un secarropas! MP: No, escuche bien, eh. Tiene B: El circo de Moscú. números. MP: No Bellini. Toma medidas. B: Un ministro. MP: No Bellini, eh! Algunas son B: Una modelo, Mario! de plástico y otras de madera. MP: No, Bellini, no y no! -- El Gran Bellini (Mario Podestá con una regla) It's about wild and funny semantic confusions made by Bellini in attempting to guess with hints, due to homonymy and, heck, polysemy I guess :o). But what does the secarropas (tumble-dryer according to http://www.spanishdict.com/translate/secarropas) have to do with anything?
Jul 08 2009
next sibling parent Leandro Lucarella <llucax gmail.com> writes:
Andrei Alexandrescu, el  8 de julio a las 11:46 me escribiste:

I'm sorry about the spanish taglines, they are selected randomly =)

And most (in spanish) are pretty local (argentine) jokes.

 P.S. With the help of a dictionary I think I figured most of this joke:
 
 MP: Cómo está, estimado Bellini?   B: Muy bien, Mario, astrologando.
 MP: Qué tengo?                     B: Un balcón-terraza.
 MP: No, en mi mano, Bellini...     B: Un secarropas!
 MP: No, escuche bien, eh. Tiene    B: El circo de Moscú.
     números.
 MP: No Bellini. Toma medidas.      B: Un ministro.
 MP: No Bellini, eh! Algunas son    B: Una modelo, Mario!
     de plástico y otras de madera.
 MP: No, Bellini, no y no!
 	-- El Gran Bellini (Mario Podestá con una regla)
 
 It's about wild and funny semantic confusions made by Bellini in
 attempting to guess with hints, due to homonymy and, heck, polysemy
 I guess :o). But what does the secarropas (tumble-dryer according to
 http://www.spanishdict.com/translate/secarropas) have to do with
 anything?

It doesn't, it's just absurd to have a tumble-dryer in your hand. This quote is a sketch from a cable (cult) tv show from Argentina calle "Magazine For Fai". It was mostly sketch-based absurd humor (format similar to Monty Python Flying Circus) with the particularity of being interpreted by children (except for the creator). This sketch is about a not-so-good mentalist ("El Gran Bellini" or "The Great Bellini"), who tries to guess what it's in the hand of Mario Podestá (the creator) with his eyes covered. If you manage to understand spoken spanish, you can see this sketch video in YouTube: http://www.youtube.com/watch?v=dANeOdBX6QM or read the Wikipedia article about the show: http://es.wikipedia.org/wiki/Magazine_For_Fai -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- Que importante, entonces en estos días de globalización refregar nuestras almas, pasarle el lampazo a nuestros corazones para alcanzar un verdadero estado de babia peperianal. -- Peperino Pómoro
Jul 08 2009
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Andrei Alexandrescu wrote:
 P.S. With the help of a dictionary I think I figured most of this joke:
 
 MP: Cómo está, estimado Bellini?   B: Muy bien, Mario, astrologando.
 MP: Qué tengo?                     B: Un balcón-terraza.
 MP: No, en mi mano, Bellini...     B: Un secarropas!
 MP: No, escuche bien, eh. Tiene    B: El circo de Moscú.
     números.
 MP: No Bellini. Toma medidas.      B: Un ministro.
 MP: No Bellini, eh! Algunas son    B: Una modelo, Mario!
     de plástico y otras de madera.
 MP: No, Bellini, no y no!
     -- El Gran Bellini (Mario Podestá con una regla)

Translation for the lazy: A donkey, a horse, and a fish walk into a bar.
Jul 08 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Walter Bright wrote:
 Andrei Alexandrescu wrote:
 P.S. With the help of a dictionary I think I figured most of this joke:

 MP: Cómo está, estimado Bellini?   B: Muy bien, Mario, astrologando.
 MP: Qué tengo?                     B: Un balcón-terraza.
 MP: No, en mi mano, Bellini...     B: Un secarropas!
 MP: No, escuche bien, eh. Tiene    B: El circo de Moscú.
     números.
 MP: No Bellini. Toma medidas.      B: Un ministro.
 MP: No Bellini, eh! Algunas son    B: Una modelo, Mario!
     de plástico y otras de madera.
 MP: No, Bellini, no y no!
     -- El Gran Bellini (Mario Podestá con una regla)

Translation for the lazy: A donkey, a horse, and a fish walk into a bar.

And the bartender asks the horse: "Why the long face?" Andrei
Jul 08 2009
parent Ary Borenszweig <ary esperanto.org.ar> writes:
Andrei Alexandrescu wrote:
 Walter Bright wrote:
 Andrei Alexandrescu wrote:
 P.S. With the help of a dictionary I think I figured most of this joke:

 MP: Cómo está, estimado Bellini?   B: Muy bien, Mario, astrologando.
 MP: Qué tengo?                     B: Un balcón-terraza.
 MP: No, en mi mano, Bellini...     B: Un secarropas!
 MP: No, escuche bien, eh. Tiene    B: El circo de Moscú.
     números.
 MP: No Bellini. Toma medidas.      B: Un ministro.
 MP: No Bellini, eh! Algunas son    B: Una modelo, Mario!
     de plástico y otras de madera.
 MP: No, Bellini, no y no!
     -- El Gran Bellini (Mario Podestá con una regla)

Translation for the lazy: A donkey, a horse, and a fish walk into a bar.

And the bartender asks the horse: "Why the long face?"

http://www.youtube.com/watch?v=KZ-Okkpgeh4
Jul 08 2009
prev sibling next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Leandro Lucarella wrote:
 I incidentally went through all the D2 bug reports that had being fixed in
 this release and I was really surprised about how much of them had patches
 by Don (the vast majority!).

Don's an awesome contributor. I and the rest of the D community are very much indebted to him.
 Thanks Don! I think it's great that more people are becoming major
 D contributors.
 

Jul 08 2009
prev sibling parent Don <nospam nospam.com> writes:
Leandro Lucarella wrote:
 Walter Bright, el  5 de julio a las 22:05 me escribiste:
 Something for everyone here.


 http://www.digitalmars.com/d/1.0/changelog.html
 http://ftp.digitalmars.com/dmd.1.046.zip


 http://www.digitalmars.com/d/2.0/changelog.html
 http://ftp.digitalmars.com/dmd.2.031.zip

I incidentally went through all the D2 bug reports that had being fixed in this release and I was really surprised about how much of them had patches by Don (the vast majority!). Thanks Don! I think it's great that more people are becoming major D contributors.

Thanks! Yeah, I did a major assault on the segfault/internal compiler error bugs. I figured that right now, the most useful thing I could do was to make the compiler stable. I have few more to give to Walter, but in general it should be quite difficult to crash the compiler now. A couple of my other bug patches -- 1994 and 3010 -- appear to be fixed in this release, though they are not in the changelog. Also the ICE from 339 is fixed.
Jul 09 2009
prev sibling parent Max Samukha <spambox d-coding.com> writes:
On Sun, 05 Jul 2009 22:05:10 -0700, Walter Bright
<newshound1 digitalmars.com> wrote:

Something for everyone here.


http://www.digitalmars.com/d/1.0/changelog.html
http://ftp.digitalmars.com/dmd.1.046.zip


http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.031.zip

Nice release. Thanks! I wonder if expression tuples had been considered for use in the multiple case statement? And if yes, what was the reason they were discarded? Some examples: case InclusiveRange!('a', 'z'): case StaticTuple!(1, 2, 5, 6): case AnEnum.tupleof[1..3]:
Jul 13 2009