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
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
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
On Tue, 07 Jul 2009 02:35:44 -0400, Robert Jacques sandf...@jhu.edu
wrote:
On Tue, 07 Jul 2009 01:48:41 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Robert Jacques wrote:
On Mon, 06 Jul 2009 01:05:10 -0400, Walter Bright
newshou...@digitalmars.com wrote:
Something
Robert Jacques wrote:
On Tue, 07 Jul 2009 01:48:41 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Robert Jacques wrote:
On Mon, 06 Jul 2009 01:05:10 -0400, Walter Bright
newshou...@digitalmars.com wrote:
Something for everyone here.
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
Robert Jacques wrote:
Another inconsistency:
byte[] x,y,z;
z[] = x[]*y[]; // Compiles
Bugzilla is its name.
Andrei
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,
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
Ary Borenszweig wrote:
Jesse Phillips escribió:
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.
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
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
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?
They
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
On Tue, 07 Jul 2009 03:33:24 -0400, Andrei Alexandrescu
seewebsiteforem...@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
Robert Jacques wrote:
On Tue, 07 Jul 2009 03:33:24 -0400, Andrei Alexandrescu
seewebsiteforem...@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; //
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
newshou...@digitalmars.com
wrote:
Something for everyone here.
http://www.digitalmars.com/d/1.0/changelog.html
On Tue, Jul 7, 2009 at 11:33 AM, Andrei
Alexandrescuseewebsiteforem...@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
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
On Tue, 07 Jul 2009 11:36:26 -0400, Andrei Alexandrescu
seewebsiteforem...@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
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
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.
Robert Jacques wrote:
On Tue, 07 Jul 2009 03:33:24 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Robert Jacques wrote:
BTW: this means byte and short are not closed under arithmetic
operations, which drastically limit their usefulness.
I think they shouldn't be closed
Andrei Alexandrescu:
Safe D is concerned with memory safety only.
And hopefully you will understand that is wrong :-)
Bye,
bearophile
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
Bill Baxter wrote:
2009/7/7 Andrei Alexandrescu seewebsiteforem...@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.
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
Andrei Alexandrescu wrote:
Bill Baxter wrote:
2009/7/7 Andrei Alexandrescu seewebsiteforem...@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.
=
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
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote in message
news:h2vprn$1t7...@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
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
Nick Sabalausky wrote:
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote in message
news:h2vprn$1t7...@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
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
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
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
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.
Yup, that's what
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
Walter Bright wrote:
Andrei Alexandrescu wrote:
Bill Baxter wrote:
2009/7/7 Andrei Alexandrescu seewebsiteforem...@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.
On Tue, 07 Jul 2009 14:16:14 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Robert Jacques wrote:
On Tue, 07 Jul 2009 11:36:26 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Robert Jacques wrote:
Andrei, I have a short vector template (think vec!(byte,3),
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,
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. [)
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
On Tue, 07 Jul 2009 18:05:26 -0400, Derek Parnell de...@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
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
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
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
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
bearophile bearophileh...@lycos.com wrote in message
news:h3093m$2mu...@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
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote in message
news:h30907$2lk...@digitalmars.com...
Nick Sabalausky wrote:
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote in message
news:h2vprn$1t7...@digitalmars.com...
This is a different beast. We simply couldn't devise a
Nick Sabalausky wrote:
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote in message
news:h30907$2lk...@digitalmars.com...
Nick Sabalausky wrote:
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote in message
news:h2vprn$1t7...@digitalmars.com...
This is a different beast. We simply
Nick Sabalausky wrote:
bearophile bearophileh...@lycos.com wrote in message
news:h3093m$2mu...@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
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
On Tue, 07 Jul 2009 20:48:50 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org 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
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
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
Walter Bright newshou...@digitalmars.com wrote in message
news:h2s0me$30f...@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
On Tue, 07 Jul 2009 21:05:45 -0400, Walter Bright
newshou...@digitalmars.com wrote:
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
Thanks.
On Tue, 07 Jul 2009 23:01:58 -0400, Walter Bright
newshou...@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
Robert Jacques wrote:
On Tue, 07 Jul 2009 23:01:58 -0400, Walter Bright
newshou...@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
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
I am finding that the use of contracts in D2 doesn't help to locate bugs.
The messages given tell the file and line for the check, but not the
offending code. This makes it appear as though the error is the fault of
Phobos and not my code (which of course is not the case). Here are a few
of
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
Currently, template versions of opXXX_r appear to be useless.
Consider:
struct A
{
int opSub(T)(T x) { return 1; }
int opSub_r(T)(T x) { return -1; }
}
A a;
int x = a - a; // is this a.opSub(a) or a.opSub_r(a) ???
This is annoying and rather silly. I can't imagine a case where you
would
David B. Held Wrote:
I would be very surprised to hear about a large-scale
project in Python/Ruby/etc. (100k+ lines).
Dave
I've got a system here that is made in a dynamic language, and extends well
over 100k+ lines. Developed by more than 25 developers. That shows that dynamic
languages
Don wrote:
Currently, template versions of opXXX_r appear to be useless.
Consider:
struct A
{
int opSub(T)(T x) { return 1; }
int opSub_r(T)(T x) { return -1; }
}
A a;
int x = a - a; // is this a.opSub(a) or a.opSub_r(a) ???
This is annoying and rather silly. I can't imagine a case
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
Don wrote:
Currently, template versions of opXXX_r appear to be useless.
Consider:
struct A
{
int opSub(T)(T x) { return 1; }
int opSub_r(T)(T x) { return -1; }
}
A a;
int x = a - a; // is this a.opSub(a) or a.opSub_r(a) ???
This is annoying and rather silly. I can't imagine a case
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.
Andrei Alexandrescu wrote:
Don wrote:
Currently, template versions of opXXX_r appear to be useless.
Consider:
struct A
{
int opSub(T)(T x) { return 1; }
int opSub_r(T)(T x) { return -1; }
}
A a;
int x = a - a; // is this a.opSub(a) or a.opSub_r(a) ???
This is annoying and rather silly.
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:
One of the huge advantages of something like Python that a lot of people,
shockingly, seem unable to grasp is the interactive interpreter.
LDC compiler works on LLVM, so it's probably doable to add a standard built-in
interactive shell to LDC (and generally use the compiler at
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
On Tue, Jul 7, 2009 at 5:24 PM, Tim Matthewstim.matthe...@gmail.com wrote:
Andrei Alexandrescu wrote:
Existing actual or perceived inconsistencies are not an argument for
adding more of them.
Seriously?
d00d. Does that really need explanation? Two wrongs don't make a
right is all he's
Tim Matthews wrote:
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
On Mon, 06 Jul 2009 15:54:29 -0400, Jarrett Billingsley
jarrett.billings...@gmail.com wrote:
On Mon, Jul 6, 2009 at 3:12 PM, Steven
Schveighofferschvei...@yahoo.com wrote:
In addition, the workaround to get the desired
behavior is pretty straightforward (the alias base.function function
Andrei Alexandrescu wrote:
Prepare to be surprised. Compile this:
void main()
{
switch (2)
{
case (1, 2): break;
default: break;
}
}
I'm getting the message that it is impossible to override what is
already and expression evaluating to the last in the comma sequence
On Tue, 07 Jul 2009 04:35:56 -0400, 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 :
Jesse Phillips wrote:
On Tue, 07 Jul 2009 04:35:56 -0400, 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 :
On Tue, Jul 7, 2009 at 9:07 AM, Bill Baxterwbax...@gmail.com wrote:
On Tue, Jul 7, 2009 at 5:24 PM, Tim Matthewstim.matthe...@gmail.com wrote:
Andrei Alexandrescu wrote:
Existing actual or perceived inconsistencies are not an argument for
adding more of them.
Seriously?
d00d.
Woah woah
Walter Bright, el 6 de julio a las 22:24 me escribiste:
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
1 - 100 of 185 matches
Mail list logo