http://d.puremagic.com/issues/show_bug.cgi?id=11213
monarchdo...@gmail.com changed:
What|Removed |Added
CC||monarchdo...@gmail.com
---
http://d.puremagic.com/issues/show_bug.cgi?id=11213
bearophile_h...@eml.cc changed:
What|Removed |Added
CC||bearophile_h...@eml.cc
---
http://d.puremagic.com/issues/show_bug.cgi?id=11213
Andrej Mitrovic andrej.mitrov...@gmail.com changed:
What|Removed |Added
Resolution|INVALID |WONTFIX
http://d.puremagic.com/issues/show_bug.cgi?id=11213
Summary: Simplify switch case-range statement
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
http://d.puremagic.com/issues/show_bug.cgi?id=11213
rswhi...@googlemail.com changed:
What|Removed |Added
CC||rswhi...@googlemail.com
---
http://d.puremagic.com/issues/show_bug.cgi?id=11213
Kenji Hara k.hara...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
http://d.puremagic.com/issues/show_bug.cgi?id=7275
Summary: Cannot use property function call in case/case range
statement
Product: D
Version: D2
Platform: Other
OS/Version: Windows
Status: NEW
Keywords
http://d.puremagic.com/issues/show_bug.cgi?id=7275
Kenji Hara k.hara...@gmail.com changed:
What|Removed |Added
Keywords||patch
Michiel Helvensteijn wrote:
Andrei Alexandrescu wrote:
void main()
{
foreach_reverse (i; 0.7 .. 100.7)
{
write(i, );
}
}
The last number printed is -0.3.
A question if I may.
Why does D allow iteration over an interval of floats? A floating point
number has no
Don wrote:
Michiel Helvensteijn wrote:
Andrei Alexandrescu wrote:
void main()
{
foreach_reverse (i; 0.7 .. 100.7)
{
write(i, );
}
}
The last number printed is -0.3.
A question if I may.
Why does D allow iteration over an interval of floats? A floating point
number
On Mon, Jul 13, 2009 at 2:59 AM, Donnos...@nospam.com wrote:
Michiel Helvensteijn wrote:
Andrei Alexandrescu wrote:
void main()
{
foreach_reverse (i; 0.7 .. 100.7)
{
write(i, );
}
}
The last number printed is -0.3.
A question if I may.
Why does D allow
Andrei Alexandrescu wrote:
Benji Smith wrote:
Andrei Alexandrescu wrote:
Anyhow... it would be a bummer if the negative atmosphere as of late
in the group would cause people like you just lose interest. I can't
understand what's going on.
I think it would help if you weren't so
Andrei Alexandrescu wrote:
Anyhow... it would be a bummer if the negative atmosphere as of late in
the group would cause people like you just lose interest. I can't
understand what's going on.
I think it would help if you weren't so condescending to people all the
time. People don't like
Andrei Alexandrescu Wrote:
Anyhow... it would be a bummer if the negative atmosphere as of late in
the group would cause people like you just lose interest. I can't
understand what's going on. It starts looking like a disfunctional
relationship: the more Walter and others do, the less
Benji Smith wrote:
Andrei Alexandrescu wrote:
Anyhow... it would be a bummer if the negative atmosphere as of late
in the group would cause people like you just lose interest. I can't
understand what's going on.
I think it would help if you weren't so condescending to people all the
time.
Yigal Chripun wrote:
Let's compare:
Bartosz took upon himself the task of designing concurrency for D. For that he put forth a lot of effort to explain the design and the rational behind it, he also encouraged discussion of the subject in the NG and answered questions.
You've re-implemented
I think that inclusive ranges more intuitive for beginner programmers because
statements:
case 1..10,
array [1..10],
foreach (int item; 1..10),
foreach_reverse (int item; 1..10) (now foreach_reverse range is too dificult
to understand it: item begins with 10 or 9, ends 1 or 2?)
will
Lutger wrote:
Daniel Keep wrote:
Valery wrote:
I think that inclusive ranges more intuitive for beginner programmers
because statements:
case 1..10,
array [1..10],
foreach (int item; 1..10),
foreach_reverse (int item; 1..10) (now foreach_reverse range is too
dificult to understand
I have not read this entire topic, but what about the following:
case 5, .., 9:
Or even:
case 5.., 9:
This actually can be very logical, IMHO, because it's saying that 9 is
included very specifically.
Other possibilities that could be explored:
case for 5, 9:
case somekindofrange!(5, 9):
On Sat, Jul 11, 2009 at 4:37 PM, Unknown W.
Bracketsunkn...@simplemachines.org wrote:
I have not read this entire topic, but what about the following:
case 5, .., 9:
I don't have a problem with the current syntax, but the mathematical
side of my brain squealed with fanboyish glee when it saw
Andrei Alexandrescu wrote:
By the way, it seems that Walter hasn't regenerated the documentation
when releasing 2.031, for example search this page for enum
http://www.dsource.org/projects/phobos/browser/trunk/phobos/std/conv.d
vs. this page:
Jarrett Billingsley wrote:
On Sat, Jul 11, 2009 at 4:37 PM, Unknown W.
Bracketsunkn...@simplemachines.org wrote:
I have not read this entire topic, but what about the following:
case 5, .., 9:
I don't have a problem with the current syntax, but the mathematical
side of my brain squealed with
On Sat, Jul 11, 2009 at 4:59 PM, Walter
Brightnewshou...@digitalmars.com wrote:
Jarrett Billingsley wrote:
On Sat, Jul 11, 2009 at 4:37 PM, Unknown W.
Bracketsunkn...@simplemachines.org wrote:
I have not read this entire topic, but what about the following:
case 5, .., 9:
I don't have a
On Fri, Jul 10, 2009 at 1:50 AM, Walter
Brightnewshou...@digitalmars.com wrote:
Without any way to sequence expressions in place, a lot of manipulation
becomes much more complicated. Comma expressions have been around a long
time, they work well, and are often used.
Then why not, as someone
On Thu, Jul 9, 2009 at 9:09 PM, Walter Brightnewshou...@digitalmars.com wrote:
Bill Baxter wrote:
If it's internal to the parse tree can't you make the syntax whatever you
want?
Something like (expr1 __exprSequencer expr2) should do just fine, right?
No reason it has to be a precious
Walter Bright wrote:
Having a step size requires, of course, a third operand. This doesn't
work too well with infix operator notation (the only 3 operand infix
operator is ?:).
Having such a third operand, however, should mesh quite well with
Andrei's range library construct.
In the
Jarrett Billingsley wrote:
On Fri, Jul 10, 2009 at 1:50 AM, Walter
Brightnewshou...@digitalmars.com wrote:
Without any way to sequence expressions in place, a lot of manipulation
becomes much more complicated. Comma expressions have been around a long
time, they work well, and are often used.
Bill Baxter wrote:
On Thu, Jul 9, 2009 at 9:09 PM, Walter Brightnewshou...@digitalmars.com wrote:
Bill Baxter wrote:
If it's internal to the parse tree can't you make the syntax whatever you
want?
Something like (expr1 __exprSequencer expr2) should do just fine, right?
No reason it has to be a
Walter Bright wrote:
Bill Baxter wrote:
On Thu, Jul 9, 2009 at 9:09 PM, Walter
Brightnewshou...@digitalmars.com wrote:
Bill Baxter wrote:
If it's internal to the parse tree can't you make the syntax
whatever you
want?
Something like (expr1 __exprSequencer expr2) should do just fine,
right?
Walter Bright wrote:
Jérôme M. Berger wrote:
I've always felt they were useless and confusing. What's the
advantage of y = (foo(), x + 3); over foo(); y = x+3;?
When you only see the x+3 because you're recursively walking the tree
generating code.
It's handy for things like rewriting
On Fri, Jul 10, 2009 at 12:24 PM, Walter
Brightnewshou...@digitalmars.com wrote:
Bill Baxter wrote:
On Thu, Jul 9, 2009 at 9:09 PM, Walter Brightnewshou...@digitalmars.com
wrote:
Bill Baxter wrote:
If it's internal to the parse tree can't you make the syntax whatever
you
want?
Something
Bill Baxter wrote:
P.P.S. on the other hand, Python uses double underscores all over the
place and people call it a beautiful language. Go figure. I guess
it's only ugly till you have a few dozen of them. Then it's a
pattern.
Maybe Python has a community that knows better what to worry
Hello Bill,
P.P.S. on the other hand, Python uses double underscores all over the
place and people call it a beautiful language. Go figure. I guess
it's only ugly till you have a few dozen of them. Then it's a
pattern.
--bb
A single double underscore is a tragedy; a million double
BCS wrote:
I think this strand of the thread (and what I was talking about) was not
about octal but about complexity in the lexical design. That bugzilla
issue was brought up as an issue and IS the first point that comes to my
mind in that direction. disallowing leading or trailing decimal
On Wed, Jul 8, 2009 at 8:26 PM, Walter Brightnewshou...@digitalmars.com wrote:
Bill Baxter wrote:
I think what Jerome is getting at is that we could be getting more
mileage out of the xpr1..xpr2 syntax. It would be useful syntax for
more than just integral, dense ranges in foreach and
Bill Baxter:
Python's are a little annoying in that, like D, you can't use
them outside of indexing expressions. Can't even use them in loops.
In NumPy, the numerical library for Python, they've invented some
quirky objects like numpy.r_ which you index to create a range
literal. Like
Bill Baxter wrote:
On Wed, Jul 8, 2009 at 8:26 PM, Walter Brightnewshou...@digitalmars.com wrote:
Bill Baxter wrote:
I think what Jerome is getting at is that we could be getting more
mileage out of the xpr1..xpr2 syntax. It would be useful syntax for
more than just integral, dense ranges in
Bill Baxter wrote:
Not every one of those has every feature you could imagine. But nice
things about Python's slices include:
* optional step size,
* step size can be negative.
* nice compact notation
* And the a:b syntax maps to a slice object so that you can manipulate
them and pass them
Walter Bright wrote:
Nick Sabalausky wrote:
Walter Bright newshou...@digitalmars.com wrote in message
It's handy when you want to prefix one expression to another, as in:
(foo(), x + 3)
I guess I'm not familiar with that syntax. What does that do and for
what purpose?
They're called
Bill Baxter wrote:
On Wed, Jul 8, 2009 at 4:12 PM, Andrei
Alexandrescuseewebsiteforem...@erdani.org wrote:
Jérôme M. Berger wrote:
So, the correct way to define an inclusive range is with +1 except
when it's with nextUp, unless you're talking about the right end of the
range where it is
Walter Bright:
Having such a third operand, however, should mesh quite well with
Andrei's range library construct.
In normal usage slices are sometimes useful, but slicing is mostly useful when
you work with rectangular matrices, so you can slice and dice them in many
ways, across axes, etc.
Andrei Alexandrescu wrote:
Jérôme M. Berger wrote:
So, the correct way to define an inclusive range is with +1
except when it's with nextUp, unless you're talking about the right
end of the range where it is inclusive by default and the right way to
make it exclusive is with +1 except
Jérôme M. Berger wrote:
Walter Bright wrote:
Nick Sabalausky wrote:
Walter Bright newshou...@digitalmars.com wrote in message
It's handy when you want to prefix one expression to another, as in:
(foo(), x + 3)
I guess I'm not familiar with that syntax. What does that do and for
what
Hello Walter,
It's handy for things like rewriting ++e so it can be used more than
once but is only evaluated once:
(tmp = ++e, tmp)
Uh? How is that different from ++e
You can then use tmp more than once with only one increment of e.
how does that differ from using ++e the first time
BCS wrote:
Hello Walter,
It's handy for things like rewriting ++e so it can be used more than
once but is only evaluated once:
(tmp = ++e, tmp)
Uh? How is that different from ++e
You can then use tmp more than once with only one increment of e.
how does that differ from using ++e the
On Thu, Jul 9, 2009 at 7:08 PM, Walter Brightnewshou...@digitalmars.com wrote:
Jérôme M. Berger wrote:
Walter Bright wrote:
Nick Sabalausky wrote:
Walter Bright newshou...@digitalmars.com wrote in message
It's handy when you want to prefix one expression to another, as in:
(foo(), x +
Bill Baxter wrote:
If it's internal to the parse tree can't you make the syntax whatever you want?
Something like (expr1 __exprSequencer expr2) should do just fine, right?
No reason it has to be a precious one-character symbol syntax.
What if you're writing a program that generates D code?
On Fri, Jul 10, 2009 at 12:09 AM, Walter
Brightnewshou...@digitalmars.com wrote:
Bill Baxter wrote:
If it's internal to the parse tree can't you make the syntax whatever you
want?
Something like (expr1 __exprSequencer expr2) should do just fine, right?
No reason it has to be a precious
Jarrett Billingsley wrote:
On Fri, Jul 10, 2009 at 12:09 AM, Walter
Brightnewshou...@digitalmars.com wrote:
Bill Baxter wrote:
If it's internal to the parse tree can't you make the syntax whatever you
want?
Something like (expr1 __exprSequencer expr2) should do just fine, right?
No reason it
Rainer Deyke wrote:
Andrei Alexandrescu wrote:
Derek Parnell wrote:
I would not complain if trailing dot and leading dot were disallowed.
I think the question that should be asked is: would anyone complain if
they were kept? We have bigger rocks to move than that one.
It seems rather
Derek Parnell wrote:
So ...
... just in case you look over your shoulder:
Octal literals are so common that we need compiler/language support.
We don't need, we have it.
Character ranges are so rare that we do not need compiler/language support.
This is just immature. It's not that
Hello Walter,
BCS wrote:
What would you sell it outright for? As in I would own it and have
every right I would have if I was the original author.
As a non-exclusive license, probably $500.
Not a license, *own*. As in I *own* my hat. (ignoring the question of would
you still own your
BCS wrote:
BCS wrote:
What would you sell it outright for? As in I would own it and have
every right I would have if I was the original author.
As a non-exclusive license, probably $500.
Not a license, *own*. As in I *own* my hat. (ignoring the question of
would you still own your copy)
Walter Bright wrote:
BCS wrote:
Hello Walter,
Jarrett Billingsley wrote:
Totally agree. They're cruft that just complicate lexical analysis.
Not a significant issue, as the code to lex it is done, works, and is
readily available.
But that assumes that just using the lexer is
Walter Bright wrote:
Jarrett Billingsley wrote:
On Tue, Jul 7, 2009 at 11:20 PM, Walter
Translating C code to D.
I don't see this as a reasonable justification. Octal isn't used that
much in C either, and D is already so far from C that you need an
automated tool to do it, so you might as
Walter Bright wrote:
Back in the 80's, there was some n.g. discussion about what xy meant
and how it was lexed and parsed. The best answer was:
Here a plus, there a plus, everywhere a plus plus.
What I'd really like to see is a lexer that parses operators by rules
rather than lists. If
Walter Bright:
Not a significant issue, as the code to lex it is done, works, and is
readily available.
It's not an issue for the compiler, but a modern programming language has to be
designed for programmers, to be as little bug-prone as possible. Literals as .5
and 5. are not correct in my
Andrei Alexandrescu:
I can't understand what's going on. It starts looking like a disfunctional
relationship: the more Walter and others do, the less content people on the
group are. I don't care much for being pat on the back, but it's extremely
disheartening to see that the more we do the
Don wrote:
Make a leading 0 illegal,
I'm not sure what benefit that accomplishes.
and either:
(1) change the octal syntax into 0c77733,
or(better) (2) provide an octal conversion function in the standard
library.
Because of CTFE, so we can actually do (2) very nicely. I don't see any
bearophile wrote:
Walter Bright:
Not a significant issue, as the code to lex it is done, works, and is
readily available.
It's not an issue for the compiler, but a modern programming language has to be
designed for programmers, to be as little bug-prone as possible. Literals as .5
and 5.
Mike James Wrote:
case 1 to 5:
Can't resist... :)
case foreach (n; 1..6):
Ali
Compatibility with C is paramount, except when it's not.
You didn't understand. Compatibility with C is important in the sense
that we want to have a clean-cut answer to a function rsa_encrypt()
taken from C and pasted into D: either it compiles and runs with the
same result, or it doesn't
Jarrett Billingsley, el 7 de julio a las 22:28 me escribiste:
On Tue, Jul 7, 2009 at 8:08 PM, bearophilebearophileh...@lycos.com wrote:
Nick Sabalausky:
why in the world is anyone defending the continued existance of 5.
and .5?
I'm for disallowing them; 5.0 ad 0.5 are better.
Anyone
Jarrett Billingsley, el 7 de julio a las 23:40 me escribiste:
On Tue, Jul 7, 2009 at 11:20 PM, Walter
Brightnewshou...@digitalmars.com wrote:
Jarrett Billingsley wrote:
Totally agree. They're cruft that just complicate lexical analysis.
Not a significant issue, as the code to lex it
grauzone wrote:
Compatibility with C is paramount, except when it's not.
You didn't understand. Compatibility with C is important in the sense
that we want to have a clean-cut answer to a function rsa_encrypt()
taken from C and pasted into D: either it compiles and runs with the
same result,
*cough* pot *cough* kettle *cough* black... :o)
Are you alright?
Don wrote:
Walter Bright wrote:
Don wrote:
Make a leading 0 illegal,
I'm not sure what benefit that accomplishes.
It catches occasional mistakes such as:
int [] foo = [
001
010
100
];
which are admittedly very rare, though it actually happened to me
earlier this year. It's quite
Leandro Lucarella wrote:
That's not a good enough reason. Having *one* front-end
(lexer/parser/semantic analizer) is not good enough. D was supposed to
make this easy to encourage different implementations. If the D specs are
twisted and making a new lexer is... confusing, I think that's a
Walter Bright wrote:
Don wrote:
It catches occasional mistakes such as:
int [] foo = [
001
010
100
];
I see your point, but I'd like to add that it is rare enough that it has
never happened to me in 30 years.
It has happened to me once or twice. I have never intentionally used an
Jérôme M. Berger wrote:
So, the correct way to define an inclusive range is with +1 except
when it's with nextUp, unless you're talking about the right end of
the range where it is inclusive by default and the right way to make it
exclusive is with +1 except when it's with nextUp?
On Wed, Jul 8, 2009 at 4:12 PM, Andrei
Alexandrescuseewebsiteforem...@erdani.org wrote:
Jérôme M. Berger wrote:
So, the correct way to define an inclusive range is with +1 except
when it's with nextUp, unless you're talking about the right end of the
range where it is inclusive by default
Bill Baxter wrote:
I think what Jerome is getting at is that we could be getting more
mileage out of the xpr1..xpr2 syntax. It would be useful syntax for
more than just integral, dense ranges in foreach and slices. The
equivalents I've used or seen in Ruby, Python and Matlab are more
versatile
Hello Walter,
BCS wrote:
BCS wrote:
What would you sell it outright for? As in I would own it and have
every right I would have if I was the original author.
As a non-exclusive license, probably $500.
Not a license, *own*. As in I *own* my hat. (ignoring the question of
would you still
BCS wrote:
I don't see where the gotcha is. It's not trivial, but it's
specifiable, and the code implementing it is there and is correct.
well for one thing the spec is wrong:
http://d.puremagic.com/issues/show_bug.cgi?id=1466
That issue has nothing to do with octal literals, and removing
Hello Walter,
BCS wrote:
I don't see where the gotcha is. It's not trivial, but it's
specifiable, and the code implementing it is there and is correct.
well for one thing the spec is wrong:
http://d.puremagic.com/issues/show_bug.cgi?id=1466
That issue has nothing to do with octal
Walter Bright wrote:
I'm tired of typing this multiple times, so please indulge me while I
cut paste from one of them:
I don't mean to frustrate. I thought it may be in at least on of those
replies but I think it deserves it's own subject.
Having a very different meaning means it should
Walter Bright wrote:
Now a FAQ entry!
http://www.digitalmars.com/d/2.0/faq.html#case_range
But it only explains the inclusive/exclusiveness and not any of the
other points. Do you not agree that the syntax looks a little ugly?
And here we go again!
*sigh*
switch( foo )
{
case 0:
..
case 5:
blah();
break;
default:
bork();
}
Doesn't look so bad, does it? For the record, I think the current
syntax is ugly. But:
* it WORKS,
* it is reasonably distinct from all
On Tue, 07 Jul 2009 17:56:31 +1200, Tim Matthews wrote:
I want to try and using similar terminology to show that 'static' is used
with the same principle.
static import bar; //must use fully qualified name
The module owns the members (functions, globals). Since the owner is
the module you
Tim Matthews wrote:
But it only explains the inclusive/exclusiveness and not any of the
other points.
Let's start with agreeing on why:
case X..Y:
is not appropriate.
Do you not agree that the syntax looks a little ugly?
I haven't seen any thing less ugly that is workable.
Daniel Keep wrote:
would have written.
Can we please, please stop the useless bike-shedding on this NG?
Rather than sift through replies to a release announcement (which I have
done since first post and still have an answer) it deserves its own
subject. The release announcement already has:
Tim Matthews wrote:
Daniel Keep wrote:
would have written.
Can we please, please stop the useless bike-shedding on this NG?
Rather than sift through replies to a release announcement (which I have
done since first post and still have an answer) it deserves its own
subject. The release
Tim Matthews wrote:
Daniel Keep wrote:
would have written.
Can we please, please stop the useless bike-shedding on this NG?
Rather than sift through replies to a release announcement (which I have
done since first post and still have an answer) it deserves its own
subject. The release
Walter Bright wrote:
Tim Matthews wrote:
But it only explains the inclusive/exclusiveness and not any of the
other points.
Let's start with agreeing on why:
case X..Y:
is not appropriate.
Do we have to be so immature about this, it's an actual topic rather
than the random trolls that
Tim Matthews wrote:
Walter Bright wrote:
Tim Matthews wrote:
But it only explains the inclusive/exclusiveness and not any of the
other points.
Let's start with agreeing on why:
case X..Y:
is not appropriate.
Do we have to be so immature about this, it's an actual topic rather
than
Andrei Alexandrescu wrote:
I swear if I didn't know anything about the feature and saw the syntax
case a: .. case b: I'd know exactly what it does in a millisecond. Why
would the syntax seem inconsistent to new D users? First of all,
inconsistent with what? And how would you treat the issue
Andrei Alexandrescu wrote:
I swear if I didn't know anything about the feature and saw the syntax
case a: .. case b: I'd know exactly what it does in a millisecond. Why
would the syntax seem inconsistent to new D users? First of all,
inconsistent with what? And how would you treat the issue
Tim Matthews wrote:
Walter Bright wrote:
Tim Matthews wrote:
But it only explains the inclusive/exclusiveness and not any of the
other points.
Let's start with agreeing on why:
case X..Y:
is not appropriate.
Do we have to be so immature about this, it's an actual topic rather
than
Andrei Alexandrescu wrote:
Existing actual or perceived inconsistencies are not an argument for
adding more of them.
Seriously?
a) It is not arguably better and more suggestive than the syntax in place.
I can't guarantee that it's better but I do think an argument can prove
a result.
Tim Matthews Wrote:
The case range statement is currently this
case FirstExp : .. case LastExp :
Would it be ambiguous to the compiler if it was
case FirstExp .. case LastExp :
or even
case FirstExp .. LastExp :
Considering that we can correctly identify a slice rather than
Mike James wrote:
Tim Matthews Wrote:
The case range statement is currently this
case FirstExp : .. case LastExp :
Would it be ambiguous to the compiler if it was
case FirstExp .. case LastExp :
or even
case FirstExp .. LastExp :
Considering that we can correctly identify a slice rather
Daniel Keep daniel.keep.li...@gmail.com wrote in message
news:h2uoju$5f...@digitalmars.com...
And here we go again!
*sigh*
switch( foo )
{
case 0:
..
case 5:
blah();
break;
default:
bork();
}
Doesn't look so bad, does it? For the
Daniel Keep daniel.keep.li...@gmail.com wrote in message
news:h2usvm$e9...@digitalmars.com...
This community has a horrible tendency to become focused on bike-shed
issues and I really, really don't want to see this particular one start
up all over again.
If you have a problem with bikeshed
Tim Matthews tim.matthe...@gmail.com wrote in message
news:h2v0ng$ko...@digitalmars.com...
b) (1,3) already means two things, neither of which has anything to do
Could you kindly state those?
I can see that just having (1,3) preceded with the case keyword makes
most other meanings
Nick Sabalausky wrote:
Tim Matthews tim.matthe...@gmail.com wrote in message
news:h2v0ng$ko...@digitalmars.com...
b) (1,3) already means two things, neither of which has anything to do
Could you kindly state those?
I can see that just having (1,3) preceded with the case keyword makes
most
On Tue, 07 Jul 2009 04:35:56 -0400, Mike James wrote:
Or you introduce a new keyword :-)
Ooooh you said the 'k' word, naughty boy.
--
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
Tim Matthews tim.matthe...@gmail.com wrote in message
news:h2v4pa$qd...@digitalmars.com...
Nick Sabalausky wrote:
Tim Matthews tim.matthe...@gmail.com wrote in message
news:h2v0ng$ko...@digitalmars.com...
b) (1,3) already means two things, neither of which has anything to
do
Could you
Derek Parnell Wrote:
On Tue, 07 Jul 2009 04:35:56 -0400, Mike James wrote:
Or you introduce a new keyword :-)
Ooooh you said the 'k' word, naughty boy.
--
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
It's my Pascal background - why use a hieroglyphic when an
Daniel Keep escribió:
Andrei Alexandrescu wrote:
I swear if I didn't know anything about the feature and saw the syntax
case a: .. case b: I'd know exactly what it does in a millisecond. Why
would the syntax seem inconsistent to new D users? First of all,
inconsistent with what? And how would
Daniel Keep wrote:
Andrei Alexandrescu wrote:
I swear if I didn't know anything about the feature and saw the syntax
case a: .. case b: I'd know exactly what it does in a millisecond. Why
would the syntax seem inconsistent to new D users? First of all,
inconsistent with what? And how would you
1 - 100 of 173 matches
Mail list logo
