On 02/07/12 23:20, Walter Bright wrote:
On 7/2/2012 1:04 PM, bearophile wrote:
Walter Bright:
Put final in front of y, and it will compile. Remember, this was
done for D1
that didn't have const.
I see. So in D2 are we going to require that y to be immutable?
No. I don't agree there's a
On Tuesday, July 03, 2012 09:42:58 Don Clugston wrote:
On 02/07/12 23:20, Walter Bright wrote:
On 7/2/2012 1:04 PM, bearophile wrote:
Walter Bright:
Put final in front of y, and it will compile. Remember, this was
done for D1
that didn't have const.
I see. So in D2 are we going to
)?
Calling it a risk and killing is way, way overstating things.
This post is about two Scala annotations. If that's not a bug, is
something like
that first Scala annotation useful in D too?
I don't really see any problem requiring a solution. If you're working
on optimizations at that level
Don Clugston:
Do you have a reference for this Java behaviour? I did a quick
google, and everything I found indicates that case labels must
be constants.
Thank you for your answer, Don.
I have compiled this Java code:
class Main {
public static void main(String[] args) {
int x
On 7/2/2012 7:37 AM, bearophile wrote:
I have compiled this Java code:
class Main {
public static void main(String[] args) {
int x = 2;
int y = 2;
switch(x) {
case 1: break;
case y: break;
}
}
}
It gives:
Main.java:7:
Walter Bright:
Put final in front of y, and it will compile. Remember, this
was done for D1 that didn't have const.
I see. So in D2 are we going to require that y to be immutable?
Bye,
bearophile
On 7/2/2012 1:04 PM, bearophile wrote:
Walter Bright:
Put final in front of y, and it will compile. Remember, this was done for D1
that didn't have const.
I see. So in D2 are we going to require that y to be immutable?
No. I don't agree there's a problem. Nor do I care to break existing D1
bearophile bearophileh...@lycos.com wrote in message
news:dkpmzrcoppslcjqvd...@forum.dlang.org...
Currently this D2 code compiles:
void main() {
int x = 2;
int y = 2;
switch(x) {
case 1: break;
case y: break;
default:
}
}
I think that
On 5/27/2012 6:13 AM, bearophile wrote:
Currently this D2 code compiles:
void main() {
int x = 2;
int y = 2;
switch(x) {
case 1: break;
case y: break;
default:
}
}
I think that accepting that case y is a compiler bug, because y is a run-time
yet). Was
this automatic translation desire worth the troubles (like inner
classes, like the risk of killing switch optimizations by
mistake)?
This post is about two Scala annotations. If that's not a bug, is
something like that first Scala annotation useful in D too?
Bye,
bearophile
, way overstating things.
This post is about two Scala annotations. If that's not a bug, is something like
that first Scala annotation useful in D too?
I don't really see any problem requiring a solution. If you're working on
optimizations at that level, you ought to be comfortable examining
of killing switch optimizations by mistake)?
Calling it a risk and killing is way, way overstating things.
This post is about two Scala annotations. If that's not a bug, is
something like that first Scala annotation useful in D too?
I don't really see any problem requiring a solution. If you're
On Sunday, 27 May 2012 at 14:04:48 UTC, Dmitry Olshansky wrote:
IMHO if you use annotations for *this* then your language is as
good as dead.
There are far better things to aim annotations at.
I couldn't say it better. @switch might have some utility in rare
cases in a language with pattern
I have found two Scala annotations.
1) The first one is @switch:
http://www.scala-lang.org/api/current/scala/annotation/switch.html
Currently this D2 code compiles:
void main() {
int x = 2;
int y = 2;
switch(x) {
case 1: break;
case y: break;
default
On 27-05-2012 15:13, bearophile wrote:
I have found two Scala annotations.
1) The first one is @switch:
http://www.scala-lang.org/api/current/scala/annotation/switch.html
Currently this D2 code compiles:
void main() {
int x = 2;
int y = 2;
switch(x) {
case 1: break;
case y: break;
default
On 27.05.2012 17:13, bearophile wrote:
I have found two Scala annotations.
1) The first one is @switch:
http://www.scala-lang.org/api/current/scala/annotation/switch.html
Currently this D2 code compiles:
void main() {
int x = 2;
int y = 2;
switch(x) {
case 1: break;
case y: break;
default
Alex Rønne Petersen:
1) Any half-decent compiler *will* optimize this thanks to a
wide array of standard dataflow analyses.
'y' was meant to be a value unknown at compile-time.
I don't know from where people got this crazy idea that a
switch statement MUST compile to a jump table *no
17 matches
Mail list logo
