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
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
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
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
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
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?
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?
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: //
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
MIURA Masahiro wrote:
Thanks for the new release! Are case ranges limited to 256 cases?
Yes.
のしいか (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
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
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.
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
Thanks everybody!
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
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
On Mon, 06 Jul 2009 12:19:47 +0400, Walter Bright
newshou...@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?
On Mon, 06 Jul 2009 09:05:10 +0400, Walter Bright
newshou...@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
On Mon, 06 Jul 2009 14:13:45 +0400, Walter Bright
newshou...@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
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.
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,
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?
What's the signed-ness of 5?
Positive. A
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;
?
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
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
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
I have just started trying the latest D1 compiler; if I try to compile my dlibs
DMD stops with this error:
Assertion failure: '0' on line 136 in file 'statement.c'
I'll try to locate the trouble better.
I can see a very large amount of bug fixes.
Use of with symbols that
randomSample is in the changelig, but not documented
http://www.digitalmars.com/d/2.0/phobos/std_random.html
Walter Bright Wrote:
Something for everyone here.
http://www.digitalmars.com/d/1.0/changelog.html
http://ftp.digitalmars.com/dmd.1.046.zip
bearophile wrote:
...
D does introduce another operator, the :..case operator g.
Unfortunately the brain of all people will see just .. as the operator
there, and it has a different semantics there, it's a special case. I am
not going to like this.
I don't think that will happen. After
のしいか (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,
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,
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-
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,
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
bearophile wrote:
Regarding switch(), can be a static switch useful?
To solve the semantic special case of .. in switch cases D2 may use a
compromise, keep the case-case syntax of Andrei, but use three points:
case 0: ... case 10:
Why?
Andrei
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:
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
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.
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
Ary Borenszweig wrote:
Walter Bright escribio':
MIURA Masahiro wrote:
Thanks for the new release! Are case ranges limited to 256 cases?
Yes.
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 :-)
On Mon, 06 Jul 2009 14:12:40 +0400, Walter Bright
newshou...@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:
..
Denis Koroskin wrote:
On Mon, 06 Jul 2009 14:12:40 +0400, Walter Bright
newshou...@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) {
Reply to Walter,
Ary Borenszweig wrote:
Walter Bright escribio':
MIURA Masahiro wrote:
Thanks for the new release! Are case ranges limited to 256 cases?
Yes.
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
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
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
On Mon, 6 Jul 2009 15:03:20 + (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
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.
The final switch deals
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
On Mon, 06 Jul 2009 22:48:07 +0400, Andrei Alexandrescu
seewebsiteforem...@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
Reply to Chad,
Walter Bright wrote:
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
Denis Koroskin wrote:
On Mon, 06 Jul 2009 22:48:07 +0400, Andrei Alexandrescu
seewebsiteforem...@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
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
Andrei Alexandrescu:
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
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
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
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
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.
I agree. Probably a good option would be to keep on requiring break, but
also requiring the user to explicitly specify they
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.
I agree. Probably a good option would be to keep on requiring break, but
also requiring the user to explicitly specify they
Andrei Alexandrescu wrote:
[awesome stuff]
Andrei
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
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
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
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
Walter Bright newshou...@digitalmars.com wrote in message
news:h2u735$sn...@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
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
Hello Ary,
But that's kind of redundant:
case 1: goto case 11:
case 11: goto case 111:
case 111: goto case :
case :
doIt();
don't you think?
case 1, 11, 111, :
doIt();
If you change the case expression, you must change it twice.
Why not:
case 1: continue case;
case 11:
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
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
Nick Sabalausky wrote:
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote in message
news:h2udmf$1b0...@digitalmars.com...
Nick Sabalausky wrote:
Walter Bright newshou...@digitalmars.com wrote in message
news:h2u735$sn...@digitalmars.com...
grauzone wrote:
I oriented this on the syntax
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
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
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
73 matches
Mail list logo
