Sat, 05 Dec 2009 20:03:28 -0500, Nick Sabalausky wrote:
> "grauzone" wrote in message
> news:hfeu6p$1ap...@digitalmars.com...
>> Nick Sabalausky wrote:
>>> "Ellery Newcomer" wrote in message
It's a useful divergence. It's a feature that should exist. But I
contend it makes more sense t
Ellery Newcomer wrote:
On 12/05/2009 11:17 PM, Don wrote:
Ellery Newcomer wrote:
On 12/05/2009 09:20 PM, Don wrote:
Nick Sabalausky wrote:
I just noticed in D1 that the values for the cases in a switch must be
known at compile-time (btw, the docs don't seem somewhat vague on
that). Is this al
On 12/05/2009 11:17 PM, Don wrote:
Ellery Newcomer wrote:
On 12/05/2009 09:20 PM, Don wrote:
Nick Sabalausky wrote:
I just noticed in D1 that the values for the cases in a switch must be
known at compile-time (btw, the docs don't seem somewhat vague on
that). Is this also true in D2? If so, I
Ellery Newcomer wrote:
On 12/05/2009 09:20 PM, Don wrote:
Nick Sabalausky wrote:
I just noticed in D1 that the values for the cases in a switch must be
known at compile-time (btw, the docs don't seem somewhat vague on
that). Is this also true in D2? If so, I don't suppose we could get
that chan
The point I'm trying to make is that a trivial translation to an if else
chain is not the only realistic choice. What you propose is non trivial and,
in a few minuets of thinking I've already thought of a number of ways it
breaks the expected semantics of the classic switch statement (it can end
Ellery Newcomer wrote:
On 12/05/2009 09:20 PM, Don wrote:
Nick Sabalausky wrote:
I just noticed in D1 that the values for the cases in a switch must be
known at compile-time (btw, the docs don't seem somewhat vague on
that). Is this also true in D2? If so, I don't suppose we could get
that chan
On 12/05/2009 06:25 PM, Nick Sabalausky wrote:
Also, I still don't see how there's any semantic difference between the
current switch and the switch-like if-else chain other than just the fact
that switch currently carries the restriction that the values being checked
against must be unique and
On 12/05/2009 09:20 PM, Don wrote:
Nick Sabalausky wrote:
I just noticed in D1 that the values for the cases in a switch must be
known at compile-time (btw, the docs don't seem somewhat vague on
that). Is this also true in D2? If so, I don't suppose we could get
that changed before the book? It'
Nick Sabalausky wrote:
I just noticed in D1 that the values for the cases in a switch must be known
at compile-time (btw, the docs don't seem somewhat vague on that). Is this
also true in D2? If so, I don't suppose we could get that changed before the
book? It's a real PITA for dynamic code.
Nick Sabalausky wrote:
> "Rainer Deyke" wrote in message
> news:hfeu0m$1af...@digitalmars.com...
>> So case labels could be variables but labels for 'goto case' would be
>> constant? That seems backwards and inconsistent.
>
> I guess I don't see it as inconsistent because I don't see case label
BCS writes:
> Lisp has something that workd like this.
Did you mean the "case" family¹ of forms?
,
| CL-USER> (case 3
|(1 "foo")
|(2 "bar")
|(otherwise "baz"))
| "baz"
| CL-USER> (case 4
|(1 "foo")
|((2 4) "bar")
|(othe
"BCS" wrote in message
news:a6268ffdcc98cc43ebb9955...@news.digitalmars.com...
> Hello Nick,
>
>> "BCS" wrote in message
>> news:a6268ffdcb78cc43db75126...@news.digitalmars.com...
>>
>>> Just jumping a ways down this rabbit hole...
>>>
>>> struct S { int i; int opCmp(S s) { return i-- == s.i++;
Hello Nick,
"BCS" wrote in message
news:a6268ffdcb78cc43db75126...@news.digitalmars.com...
Just jumping a ways down this rabbit hole...
struct S { int i; int opCmp(S s) { return i-- == s.i++; }
{
S a,b,c,d,e; ...
switch(a)
{
case b: break;
case c: break;
case d: break;
case e: break;
}
}
Oh
"div0" wrote in message
news:hff0n1$1f6...@digitalmars.com...
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Ellery Newcomer wrote:
>> On 12/05/2009 04:19 PM, Nick Sabalausky wrote:
>>> "Ellery Newcomer" wrote in message
More so than remembering to type break after each case blo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ellery Newcomer wrote:
> On 12/05/2009 04:19 PM, Nick Sabalausky wrote:
>> "Ellery Newcomer" wrote in message
>>>
>>> More so than remembering to type break after each case block?
>>
>> Good point, but that's really a separate issue.
>>
>>
>
> I don'
"BCS" wrote in message
news:a6268ffdcba8cc43e0db895...@news.digitalmars.com...
> Hello Nick,
>
>> Also, I still don't see how there's any semantic difference between
>> the current switch and the switch-like if-else chain other than just
>> the fact that switch currently carries the restriction t
"grauzone" wrote in message
news:hfeu6p$1ap...@digitalmars.com...
> Nick Sabalausky wrote:
>> "Ellery Newcomer" wrote in message
>>> It's a useful divergence. It's a feature that should exist. But I
>>> contend it makes more sense to make a new construct which *is*
>>> equivalent to a certain
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Sean Kelly wrote:
>>
>> In fact, it's already semantically equivilent to that, except that x and y
>> are currently required to be known at compile-time.
>
> D allows duplicate case values? I thought this was a compile error.
It does; from the swit
"Rainer Deyke" wrote in message
news:hfeu0m$1af...@digitalmars.com...
> Nick Sabalausky wrote:
>> "Rainer Deyke" wrote in message
>> news:hfenkl$ve...@digitalmars.com...
>>> I assume the same rule applies to 'goto case'?
>>
>> I think that amounts to a computed goto, which I don't think D curren
"Sean Kelly" wrote in message
news:hfeqbg$143...@digitalmars.com...
> Nick Sabalausky Wrote:
>
>> "Sean Kelly" wrote in message
>> news:hfelka$rh...@digitalmars.com...
>> > Nick Sabalausky Wrote:
>> >
>> >> I just noticed in D1 that the values for the cases in a switch must be
>> >> known
>> >>
Hello Nick,
Also, I still don't see how there's any semantic difference between
the current switch and the switch-like if-else chain other than just
the fact that switch currently carries the restriction that the values
being checked against must be unique and known at compile time.
For one;
Nick Sabalausky wrote:
"Ellery Newcomer" wrote in message
It's a useful divergence. It's a feature that should exist. But I contend
it makes more sense to make a new construct which *is* equivalent to a
certain pattern of nested ifs (switch isn't) and incorporate your feature
into that than t
Nick Sabalausky wrote:
> "Rainer Deyke" wrote in message
> news:hfenkl$ve...@digitalmars.com...
>> I assume the same rule applies to 'goto case'?
>
> I think that amounts to a computed goto, which I don't think D currently
> has, so that probably just wouldn't compile.
So case labels could be
"BCS" wrote in message
news:a6268ffdcb78cc43db75126...@news.digitalmars.com...
>
> Just jumping a ways down this rabbit hole...
>
> struct S { int i; int opCmp(S s) { return i-- == s.i++; }
>
> {
>S a,b,c,d,e; ...
>switch(a)
>{
>case b: break;
>case c: break;
>
"Ellery Newcomer" wrote in message
news:hfer6b$15d...@digitalmars.com...
> On 12/05/2009 04:19 PM, Nick Sabalausky wrote:
>> "Ellery Newcomer" wrote in message
>>>
>>> More so than remembering to type break after each case block?
>>
>> Good point, but that's really a separate issue.
>>
>>
>
> I
Hello Nick,
"Sean Kelly" wrote in message
news:hfelka$rh...@digitalmars.com...
Nick Sabalausky Wrote:
I just noticed in D1 that the values for the cases in a switch must
be
known
at compile-time (btw, the docs don't seem somewhat vague on that).
Is
this
also true in D2? If so, I don't suppo
Hello Ellery,
On 12/05/2009 04:19 PM, Nick Sabalausky wrote:
"Ellery Newcomer" wrote in message
More so than remembering to type break after each case block?
Good point, but that's really a separate issue.
I don't know about that. The issue seems to be you want switch to
behave
in a man
On 12/05/2009 04:19 PM, Nick Sabalausky wrote:
"Ellery Newcomer" wrote in message
More so than remembering to type break after each case block?
Good point, but that's really a separate issue.
I don't know about that. The issue seems to be you want switch to behave
in a manner unlike tha
Nick Sabalausky Wrote:
> "Sean Kelly" wrote in message
> news:hfelka$rh...@digitalmars.com...
> > Nick Sabalausky Wrote:
> >
> >> I just noticed in D1 that the values for the cases in a switch must be
> >> known
> >> at compile-time (btw, the docs don't seem somewhat vague on that). Is
> >> th
"Rainer Deyke" wrote in message
news:hfenkl$ve...@digitalmars.com...
> Nick Sabalausky wrote:
>> As I mentioned earlier, that should be semantically equivilent to:
>>
>> int x = 1, y = 1;
>>
>> if(z == x)
>> { ... }
>> else if(z == y)
>> { ... }
>>
>> In fact, it's already semantically equivilent
Nick Sabalausky wrote:
> As I mentioned earlier, that should be semantically equivilent to:
>
> int x = 1, y = 1;
>
> if(z == x)
> { ... }
> else if(z == y)
> { ... }
>
> In fact, it's already semantically equivilent to that, except that x and y
> are currently required to be known at compile-t
"Sean Kelly" wrote in message
news:hfelka$rh...@digitalmars.com...
> Nick Sabalausky Wrote:
>
>> I just noticed in D1 that the values for the cases in a switch must be
>> known
>> at compile-time (btw, the docs don't seem somewhat vague on that). Is
>> this
>> also true in D2? If so, I don't su
"Ellery Newcomer" wrote in message
news:hfekll$pb...@digitalmars.com...
> On 12/05/2009 03:39 PM, Nick Sabalausky wrote:
>> "Steven Schveighoffer" wrote in message
>> news:op.u4hhjisgeav...@localhost.localdomain...
>>> On Sat, 05 Dec 2009 16:08:00 -0500, Nick Sabalausky wrote:
>>>
I just n
Nick Sabalausky Wrote:
> I just noticed in D1 that the values for the cases in a switch must be known
> at compile-time (btw, the docs don't seem somewhat vague on that). Is this
> also true in D2? If so, I don't suppose we could get that changed before the
> book? It's a real PITA for dynamic
On 12/05/2009 03:39 PM, Nick Sabalausky wrote:
"Steven Schveighoffer" wrote in message
news:op.u4hhjisgeav...@localhost.localdomain...
On Sat, 05 Dec 2009 16:08:00 -0500, Nick Sabalausky wrote:
I just noticed in D1 that the values for the cases in a switch must be
known
at compile-time (btw,
"Steven Schveighoffer" wrote in message
news:op.u4hhjisgeav...@localhost.localdomain...
> On Sat, 05 Dec 2009 16:08:00 -0500, Nick Sabalausky wrote:
>
>> I just noticed in D1 that the values for the cases in a switch must be
>> known
>> at compile-time (btw, the docs don't seem somewhat vague o
"Don" wrote in message
news:hfeilp$m1...@digitalmars.com...
> Nick Sabalausky wrote:
>> I just noticed in D1 that the values for the cases in a switch must be
>> known at compile-time (btw, the docs don't seem somewhat vague on that).
>> Is this also true in D2? If so, I don't suppose we could
On Sat, 05 Dec 2009 16:08:00 -0500, Nick Sabalausky wrote:
I just noticed in D1 that the values for the cases in a switch must be
known
at compile-time (btw, the docs don't seem somewhat vague on that). Is
this
also true in D2? If so, I don't suppose we could get that changed before
the
b
Nick Sabalausky wrote:
I just noticed in D1 that the values for the cases in a switch must be known
at compile-time (btw, the docs don't seem somewhat vague on that). Is this
also true in D2? If so, I don't suppose we could get that changed before the
book? It's a real PITA for dynamic code.
I just noticed in D1 that the values for the cases in a switch must be known
at compile-time (btw, the docs don't seem somewhat vague on that). Is this
also true in D2? If so, I don't suppose we could get that changed before the
book? It's a real PITA for dynamic code.
40 matches
Mail list logo
