Regan Heath:
> > http://d-programming-language.org/expression.html#AssertExpression
>
> I found that :p .. but nothing about behaviour in release/debug/etc.
It's a known little wart of D2. We discussed about it some time ago. I have
asked for a specific and clean way to do it, but D designers
On Fri, 09 Dec 2011 15:39:09 -, Timon Gehr wrote:
On 12/09/2011 04:37 PM, Regan Heath wrote:
On Fri, 09 Dec 2011 14:54:16 -, Timon Gehr
wrote:
What you might be missing is that assert(false) is not compiled out in
release mode. It emits a 'hlt' instruction which kills your program.
H
On Sun, 11 Dec 2011 20:25:07 -0500, Jonathan M Davis
wrote:
On Sunday, December 11, 2011 20:19:11 Robert Jacques wrote:
A lot (all?) of for loop use cases seem to actually work in tuple form. For
instance,
for(; cond; tuple(++x, y *= 2) ) {}
Will behave as expected, although there might be
On Sunday, December 11, 2011 20:19:11 Robert Jacques wrote:
> A lot (all?) of for loop use cases seem to actually work in tuple form. For
> instance,
>
> for(; cond; tuple(++x, y *= 2) ) {}
>
> Will behave as expected, although there might be a performance issue.
What if one of the expression's
On Sun, 11 Dec 2011 06:21:51 -0500, Alex Rønne Petersen
wrote:
On 10-12-2011 02:39, Jonathan M Davis wrote:
On Friday, December 09, 2011 20:18:36 Robert Jacques wrote:
On Fri, 09 Dec 2011 01:20:45 -0500, Kagamin wrote:
On Thursday, 8 December 2011 at 17:18:57 UTC, Joshua Reusch wrote:
Ahe
On 10-12-2011 02:39, Jonathan M Davis wrote:
On Friday, December 09, 2011 20:18:36 Robert Jacques wrote:
On Fri, 09 Dec 2011 01:20:45 -0500, Kagamin wrote:
On Thursday, 8 December 2011 at 17:18:57 UTC, Joshua Reusch wrote:
Ahem. So are you suggesting that (a,b) means a tuple
everywhere but in
On Friday, December 09, 2011 20:18:36 Robert Jacques wrote:
> On Fri, 09 Dec 2011 01:20:45 -0500, Kagamin wrote:
> > On Thursday, 8 December 2011 at 17:18:57 UTC, Joshua Reusch wrote:
> >>> Ahem. So are you suggesting that (a,b) means a tuple
> >>> everywhere but in a
> >>> for loop, where it is u
On Fri, 09 Dec 2011 00:27:39 -0500, so wrote:
On Fri, 09 Dec 2011 06:26:27 +0200, Robert Jacques
wrote:
So it clashes with another thing about D, pragmatism.
I'm not sure what you mean by that.
It was/is one of the defining points of D AFAIK.
More than being theoretical it chose to be prag
On Fri, 09 Dec 2011 01:20:45 -0500, Kagamin wrote:
On Thursday, 8 December 2011 at 17:18:57 UTC, Joshua Reusch wrote:
Ahem. So are you suggesting that (a,b) means a tuple
everywhere but in a
for loop, where it is used to separate two statements?
If we use the comma operator only for tuples
On Friday, December 09, 2011 12:36:25 Regan Heath wrote:
> On Fri, 09 Dec 2011 11:39:55 -, Timon Gehr wrote:
> > These are the occurences of the comma operator in directory 'std':
> Here is my /very/ quick re-write of each without looking at the context of
> each snippet. There may be much bet
On Friday, December 09, 2011 13:00:57 Timon Gehr wrote:
> On 12/09/2011 10:26 AM, Jonathan M Davis wrote:
> > On Friday, December 09, 2011 10:19:18 Don wrote:
> >> Are there any cases where you're using comma outside of for loops?
> >> I wonder how much would break if were made illegal everywhere e
On Fri, 09 Dec 2011 14:54:16 -, Timon Gehr wrote:
10)
return
c <= 0x7F ? 1
: c <= 0x7FF ? 2
: c <= 0x ? 3
: c <= 0x10 ? 4
: (assert(false), 6);
*Much* clearer with the rewrite..
assert(c <= 0x10);
return
c <= 0x7F ? 1
: c <= 0x7FF ? 2
: c <= 0x ? 3
: c <= 0x10 ? 4
:
On 12/09/2011 04:37 PM, Regan Heath wrote:
On Fri, 09 Dec 2011 14:54:16 -, Timon Gehr wrote:
10)
return
c <= 0x7F ? 1
: c <= 0x7FF ? 2
: c <= 0x ? 3
: c <= 0x10 ? 4
: (assert(false), 6);
*Much* clearer with the rewrite..
assert(c <= 0x10);
return
c <= 0x7F ? 1
: c <= 0x7FF
On Fri, 09 Dec 2011 09:25:34 -0500, Regan Heath
wrote:
On Fri, 09 Dec 2011 13:42:34 -, Timon Gehr wrote:
On 12/09/2011 02:28 PM, Regan Heath wrote:
On Fri, 09 Dec 2011 13:15:47 -, Timon Gehr
wrote:
On 12/09/2011 01:36 PM, Regan Heath wrote:
4)
if (std.ascii.toLower(p.front) =
I didn't notice the other parts of your post before.
On 12/09/2011 03:25 PM, Regan Heath wrote:
On Fri, 09 Dec 2011 13:42:34 -, Timon Gehr wrote:
On 12/09/2011 02:28 PM, Regan Heath wrote:
On Fri, 09 Dec 2011 13:15:47 -, Timon Gehr
wrote:
On 12/09/2011 01:36 PM, Regan Heath wrote:
On 12/09/2011 03:25 PM, Regan Heath wrote:
On Fri, 09 Dec 2011 13:42:34 -, Timon Gehr wrote:
On 12/09/2011 02:28 PM, Regan Heath wrote:
On Fri, 09 Dec 2011 13:15:47 -, Timon Gehr
wrote:
On 12/09/2011 01:36 PM, Regan Heath wrote:
4)
if (std.ascii.toLower(p.front) == 'n' &&
(p.popFr
On Fri, 09 Dec 2011 13:42:34 -, Timon Gehr wrote:
On 12/09/2011 02:28 PM, Regan Heath wrote:
On Fri, 09 Dec 2011 13:15:47 -, Timon Gehr
wrote:
On 12/09/2011 01:36 PM, Regan Heath wrote:
4)
if (std.ascii.toLower(p.front) == 'n' &&
(p.popFront(), std.ascii.toLower(p.front) == 'f') &
On Fri, 09 Dec 2011 13:47:14 -, Timon Gehr wrote:
I don't want to make your life harder but I think this
change would make life easier for a large number of people, a small
amount of the time. The equation is unbalanced in favour of it's
removal, IMO.
This part of your post is somewhat co
On 12/09/2011 02:38 PM, Tobias Pankrath wrote:
Timon Gehr wrote:
It is confusing to people who don't know the language. It is a simple
construct. In my experience, it is certainly not error prone. If you are
aware that such an operator exists.
It may not be error prone to write, but it is err
On 12/09/2011 02:33 PM, Regan Heath wrote:
On Fri, 09 Dec 2011 13:01:12 -, Timon Gehr wrote:
On 12/09/2011 01:11 PM, Regan Heath wrote:
On Fri, 09 Dec 2011 12:00:57 -, Timon Gehr
wrote:
On 12/09/2011 10:26 AM, Jonathan M Davis wrote:
On Friday, December 09, 2011 10:19:18 Don wrote:
On 12/09/2011 02:28 PM, Regan Heath wrote:
On Fri, 09 Dec 2011 13:15:47 -, Timon Gehr wrote:
On 12/09/2011 01:36 PM, Regan Heath wrote:
4)
if (std.ascii.toLower(p.front) == 'n' &&
(p.popFront(), std.ascii.toLower(p.front) == 'f') &&
(p.popFront(), p.empty))
'if' statements with side ef
Timon Gehr wrote:
> It is confusing to people who don't know the language. It is a simple
> construct. In my experience, it is certainly not error prone. If you are
> aware that such an operator exists.
It may not be error prone to write, but it is error prone to read, because
the comma-operator
On Fri, 09 Dec 2011 13:01:12 -, Timon Gehr wrote:
On 12/09/2011 01:11 PM, Regan Heath wrote:
On Fri, 09 Dec 2011 12:00:57 -, Timon Gehr
wrote:
On 12/09/2011 10:26 AM, Jonathan M Davis wrote:
On Friday, December 09, 2011 10:19:18 Don wrote:
Are there any cases where you're using com
On Fri, 09 Dec 2011 13:15:22 -, Piotr Szturmaj
wrote:
Regan Heath wrote:
On Fri, 09 Dec 2011 12:00:57 -, Timon Gehr
wrote:
On 12/09/2011 10:26 AM, Jonathan M Davis wrote:
And unless you're dealing with a programmer who
uses it uncommonly often, not much code is going to break.
On Fri, 09 Dec 2011 13:15:47 -, Timon Gehr wrote:
On 12/09/2011 01:36 PM, Regan Heath wrote:
4)
if (std.ascii.toLower(p.front) == 'n' &&
(p.popFront(), std.ascii.toLower(p.front) == 'f') &&
(p.popFront(), p.empty))
'if' statements with side effects are yuck. I prefer the check for error
On 12/09/2011 01:56 PM, Derek wrote:
On Fri, 09 Dec 2011 22:39:55 +1100, Timon Gehr wrote:
These are the occurences of the comma operator in directory 'std': ...
OMG! What ever happened to the idea that source code is meant to AID
reading programs and not making it obscured.
These are examp
Regan Heath wrote:
On Fri, 09 Dec 2011 12:00:57 -, Timon Gehr wrote:
On 12/09/2011 10:26 AM, Jonathan M Davis wrote:
And unless you're dealing with a programmer who
uses it uncommonly often, not much code is going to break.
I _am_ such a programmer.
So it seems :) I don't want to make
On 12/09/2011 01:36 PM, Regan Heath wrote:
4)
if (std.ascii.toLower(p.front) == 'n' &&
(p.popFront(), std.ascii.toLower(p.front) == 'f') &&
(p.popFront(), p.empty))
'if' statements with side effects are yuck. I prefer the check for error
and bail style but you could use multiple layers of 'if
On 12/09/2011 01:11 PM, Regan Heath wrote:
On Fri, 09 Dec 2011 12:00:57 -, Timon Gehr wrote:
On 12/09/2011 10:26 AM, Jonathan M Davis wrote:
On Friday, December 09, 2011 10:19:18 Don wrote:
Are there any cases where you're using comma outside of for loops?
I wonder how much would break if
On Fri, 09 Dec 2011 22:39:55 +1100, Timon Gehr wrote:
These are the occurences of the comma operator in directory 'std': ...
OMG! What ever happened to the idea that source code is meant to AID
reading programs and not making it obscured.
These are examples for a 'shame' file, or "how not
On Fri, 09 Dec 2011 11:39:55 -, Timon Gehr wrote:
These are the occurences of the comma operator in directory 'std':
Here is my /very/ quick re-write of each without looking at the context of
each snippet. There may be much better re-writes in context. Re-writing
this was problematic
On Fri, 09 Dec 2011 12:00:57 -, Timon Gehr wrote:
On 12/09/2011 10:26 AM, Jonathan M Davis wrote:
On Friday, December 09, 2011 10:19:18 Don wrote:
Are there any cases where you're using comma outside of for loops?
I wonder how much would break if were made illegal everywhere else.
I'm su
Timon Gehr:
> These are the occurences of the comma operator in directory 'std':
>
> return r2.empty ? (r1 = r, true) : false;
> return binaryFun!pred(r.front, e) ? (r.popFront(), true) : false;
>
> if (f.flPlus)
> signChar = '+', ++minw;
> else if (f.flSpace)
> signChar = ' ', ++minw;
On Fri, 09 Dec 2011 11:39:55 -, Timon Gehr wrote:
On 12/09/2011 10:19 AM, Don wrote:
On 08.12.2011 20:22, Timon Gehr wrote:
Phobos would break, for example. And some of my code too.
Are there any cases where you're using comma outside of for loops?
Yes, one for every 65 LOC.
I wonder
On 12/09/2011 10:26 AM, Jonathan M Davis wrote:
On Friday, December 09, 2011 10:19:18 Don wrote:
Are there any cases where you're using comma outside of for loops?
I wonder how much would break if were made illegal everywhere else.
I'm sure that it would break code, but most people consider it
On 12/09/2011 10:19 AM, Don wrote:
On 08.12.2011 20:22, Timon Gehr wrote:
On 12/08/2011 05:02 PM, Regan Heath wrote:
On Thu, 08 Dec 2011 12:17:20 -, so wrote:
On Thu, 08 Dec 2011 11:17:48 +0200, Dejan Lekic
wrote:
Why is this operator still kept around?
No offense, but I find it
On Friday, December 09, 2011 10:19:18 Don wrote:
> Are there any cases where you're using comma outside of for loops?
> I wonder how much would break if were made illegal everywhere else.
I'm sure that it would break code, but most people consider it bad practice to
use the comma operator for muc
On 08.12.2011 20:22, Timon Gehr wrote:
On 12/08/2011 05:02 PM, Regan Heath wrote:
On Thu, 08 Dec 2011 12:17:20 -, so wrote:
On Thu, 08 Dec 2011 11:17:48 +0200, Dejan Lekic
wrote:
Why is this operator still kept around?
No offense, but I find it strange/funny that you even ask why!
On Thursday, 8 December 2011 at 17:18:57 UTC, Joshua Reusch wrote:
Ahem. So are you suggesting that (a,b) means a tuple
everywhere but in a
for loop, where it is used to separate two statements?
If we use the comma operator only for tuples, there needn't to
be a special case for loops:
fo
On Fri, 09 Dec 2011 06:26:27 +0200, Robert Jacques
wrote:
So it clashes with another thing about D, pragmatism.
I'm not sure what you mean by that.
It was/is one of the defining points of D AFAIK.
More than being theoretical it chose to be pragmatic, to solve the
problems we face day to
On Thu, 08 Dec 2011 21:23:11 -0500, so wrote:
On Fri, 09 Dec 2011 03:19:34 +0200, Robert Jacques
wrote:
On Thu, 08 Dec 2011 13:17:44 -0500, so wrote:
On Thu, 08 Dec 2011 19:25:10 +0200, Dejan Lekic
wrote:
type a = a + 2; // compiles with no errors, no warnings, no explosions
(that i kn
On Fri, 09 Dec 2011 03:19:34 +0200, Robert Jacques
wrote:
On Thu, 08 Dec 2011 13:17:44 -0500, so wrote:
On Thu, 08 Dec 2011 19:25:10 +0200, Dejan Lekic
wrote:
type a = a + 2; // compiles with no errors, no warnings, no explosions
(that i know of)
If "type" has the default initialiser,
On Thu, 08 Dec 2011 13:17:44 -0500, so wrote:
On Thu, 08 Dec 2011 19:25:10 +0200, Dejan Lekic
wrote:
type a = a + 2; // compiles with no errors, no warnings, no explosions
(that i know of)
If "type" has the default initialiser, then what is the problem?
What does it do in both C and D c
On Thu, 08 Dec 2011 12:18:56 -0500, Joshua Reusch wrote:>
Ahem. So are you suggesting that (a,b) means a tuple everywhere but in a
for loop, where it is used to separate two statements?
If we use the comma operator only for tuples, there needn't to be a
special case for loops:
for(x, y = 0 ,
On 12/08/2011 05:02 PM, Regan Heath wrote:
On Thu, 08 Dec 2011 12:17:20 -, so wrote:
On Thu, 08 Dec 2011 11:17:48 +0200, Dejan Lekic
wrote:
Why is this operator still kept around?
No offense, but I find it strange/funny that you even ask why! :)
Have you never used comma in for lo
On Thu, 08 Dec 2011 19:25:10 +0200, Dejan Lekic
wrote:
type a = a + 2; // compiles with no errors, no warnings, no explosions
(that i know of)
If "type" has the default initialiser, then what is the problem?
What does it do in both C and D context?
1. It does different things.
2. C ver
type a = a + 2; // compiles with no errors, no warnings, no
explosions (that i know of)
If "type" has the default initialiser, then what is the problem?
Ahem. So are you suggesting that (a,b) means a tuple everywhere but in a
for loop, where it is used to separate two statements?
If we use the comma operator only for tuples, there needn't to be a
special case for loops:
for(x, y = 0 , 100; x < y ; x, y += 1,-1) { ... }
On Thu, 08 Dec 2011 18:02:11 +0200, Regan Heath
wrote:
When I pointed this out, he said "how does that even compile" and was
completely unaware of the existence of the comma operator, nor (once I
explained it) did he realise it was in any way related to the comma used
in for loops. Peop
On Thu, 08 Dec 2011 12:17:20 -, so wrote:
On Thu, 08 Dec 2011 11:17:48 +0200, Dejan Lekic
wrote:
Why is this operator still kept around?
No offense, but I find it strange/funny that you even ask why! :)
Have you never used comma in for loops???
Not sure if it is that relevant
On Thu, 08 Dec 2011 11:17:48 +0200, Dejan Lekic
wrote:
Why is this operator still kept around?
No offense, but I find it strange/funny that you even ask why! :)
Have you never used comma in for loops???
Not sure if it is that relevant for D, but good point.
for(auto i=beg(), e=end()
On 08.12.2011 05:52, bcs wrote:
On 12/07/2011 08:49 AM, Alex Rønne Petersen wrote:
I really do not see the value in allowing such syntax in the first
place. I've been told that one argument was that generated code might
use it, but I have no idea why it would be needed. Furthermore, this
operato
This is, honestly, ridiculous. On most European keyboard
layouts, comma is on the same key as semicolon.
Modern shells usually allow to use several keyboard layouts,
switching between them as you need. You may want to add US
keyboard layout (selected layout is maintained per-window).
>
> Why is this operator still kept around?
No offense, but I find it strange/funny that you even ask why! :)
Have you never used comma in for loops???
On 12/07/2011 08:49 AM, Alex Rønne Petersen wrote:
I really do not see the value in allowing such syntax in the first
place. I've been told that one argument was that generated code might
use it, but I have no idea why it would be needed. Furthermore, this
operator makes it very hard to introduce
On Wed, 07 Dec 2011 13:19:31 -0500, Nick Sabalausky wrote:
"Robert Jacques" wrote in message
news:op.v54q04vd26s...@sandford.myhome.westell.com...
On Wed, 07 Dec 2011 11:49:33 -0500, Alex Rønne Petersen
wrote:
Why is this operator still kept around?
Take your pick:
1) So that legacy B/C/
On Wednesday, December 07, 2011 23:10:53 Timon Gehr wrote:
> On 12/07/2011 07:02 PM, Nick Sabalausky wrote:
> > "Adam Ruppe" wrote in message
> > news:jbo8rr$rhh$1...@digitalmars.com...
> >
> >> Alex Rønne Petersen Wrote:
> >>> I really do not see the value in allowing such syntax in the first
> >
On 12/07/2011 07:02 PM, Nick Sabalausky wrote:
"Adam Ruppe" wrote in message
news:jbo8rr$rhh$1...@digitalmars.com...
Alex Rønne Petersen Wrote:
I really do not see the value in allowing such syntax in the first
place. I've been told that one argument was that generated code might
use it, but I
"Robert Jacques" wrote in message
news:op.v54q04vd26s...@sandford.myhome.westell.com...
> On Wed, 07 Dec 2011 11:49:33 -0500, Alex Rønne Petersen
> wrote:
>>
>> Why is this operator still kept around?
>
> Take your pick:
> 1) So that legacy B/C/C++/D1/etc code can be trivially ported to D1/D2.
"Adam Ruppe" wrote in message
news:jbo8rr$rhh$1...@digitalmars.com...
> Alex Rønne Petersen Wrote:
>> I really do not see the value in allowing such syntax in the first
>> place. I've been told that one argument was that generated code might
>> use it, but I have no idea why it would be needed.
>
Alex Rønne Petersen Wrote:
> I really do not see the value in allowing such syntax in the first
> place. I've been told that one argument was that generated code might
> use it, but I have no idea why it would be needed.
Aside from the compiler's implementation, one possible use
is something I
On Wed, 07 Dec 2011 11:49:33 -0500, Alex Rønne Petersen
wrote:
Hi,
Consider this code:
if (condition)
foo();
else
bar(),
baz();
Notice the comma in the bar call. This will actually compile. Why?
Because the program is really interpreted as:
if (condition)
{
foo();
}
else
{
It could be moved to use either the section character or one of the
application-specific unicode points reserved for internal use by whatever an
application wants. This would eliminate confusing typing and, if using this
for generated code, the generator can easily reference it by unicode ID w
Hi,
Consider this code:
if (condition)
foo();
else
bar(),
baz();
Notice the comma in the bar call. This will actually compile. Why?
Because the program is really interpreted as:
if (condition)
{
foo();
}
else
{
bar();
baz();
}
This is, honestly, ridiculous. On most Euro
64 matches
Mail list logo
