I thought that the compiler could evaluate all intrinsics at compile
time, but this doesn't seem to be the case for std.math.yl2x(). Is my
assumption wrong, or is this a bug that should be reported?
-Lars
On 15/11/2010 11:00, Lars T. Kyllingstad wrote:
I thought that the compiler could evaluate all intrinsics at compile
time, but this doesn't seem to be the case for std.math.yl2x(). Is my
assumption wrong, or is this a bug that should be reported?
-Lars
Looks like it's not implemented because
Hello,
Is there a way to explore the current scope, meaning the set of currently
defined symbols?
(Equivalent of python's vars(), locals(), globals().)
I have 2 use cases for this:
1. name objects automatically
I need some objects to know their name (as field on themselves). the only
solution
On 15/11/2010 12:12, div0 wrote:
On 15/11/2010 11:00, Lars T. Kyllingstad wrote:
I thought that the compiler could evaluate all intrinsics at compile
time, but this doesn't seem to be the case for std.math.yl2x(). Is my
assumption wrong, or is this a bug that should be reported?
-Lars
Looks l
On Mon, 15 Nov 2010 13:03:03 +, div0 wrote:
> On 15/11/2010 12:12, div0 wrote:
>> On 15/11/2010 11:00, Lars T. Kyllingstad wrote:
>>> I thought that the compiler could evaluate all intrinsics at compile
>>> time, but this doesn't seem to be the case for std.math.yl2x(). Is my
>>> assumption wr
Hello.
Consider this code
void main()
{
l:
{
int v;
}
v = 5; // ok, v is defined
}
As I understand from D's grammar this behaviour is not a bug as
LabeledStatement:
Identifier : NoScopeStatement
and NoScopeStatement in turn takes BlockStatement without creating new
scope.
It
On Sat, 13 Nov 2010 15:57:50 -0500, spir wrote:
On Fri, 12 Nov 2010 08:03:26 -0500
"Steven Schveighoffer" wrote:
Essentially, if you change your line above to:
this.patterns = patterns.dup;
Works, but I don't understand why: isn't the duplicate also allocated on
the stack? I mean, dup
On Sun, 14 Nov 2010 05:28:29 -0500, Per Ångström wrote:
On 2010-11-11 17:21, Steven Schveighoffer wrote:
First, you can't forward-declare classes in one file that are defined in
another file, instead of importing. The reason is because in D, the
module is the namespace that the class is declar
My gut feeling is that the if statement's behavior is wrong and the
while statement's is correct, but it could go either way.
No need for a rationale for what can be adequately explained as a
compiler bug (this is a downside of dmd - it trains you to think like
this) It is curious, though, as
poking around a little more and I really don't know what's going on.
fun piece of trivia though: while loops get rewritten to for loops, so
for(;;) l1 {
int v;
}
v = 4;
exhibits the same behavior as the while loop.
do loops seem to do the same thing as the if statement
On 11/15/2010 10:34
Ellery Newcomer:
> No need for a rationale for what can be adequately explained as a
> compiler bug (this is a downside of dmd - it trains you to think like
> this)
Or: Any sufficiently incomprehensible behaviour is indistinguishable from a DMD
compiler bug :-)
Bye,
bearophile
spir:
> 1. name objects automatically
> I need some objects to know their name (as field on themselves). the only
> solution I can else imagine is for the user write:
> x = ...;
> x.name = "x";
What if you have two or more references to the same object?
Regarding your generic questi
quick question: are the following rewrites always valid:
e1 != e2 -> !(e1 == e2)
e1 !is e2-> !(e1 is e2)
e1 !in e2-> !(e1 in e2)
?
On Mon, 15 Nov 2010 14:06:34 -0500, Ellery Newcomer
wrote:
quick question: are the following rewrites always valid:
e1 != e2 -> !(e1 == e2)
e1 !is e2-> !(e1 is e2)
e1 !in e2-> !(e1 in e2)
I believe this is in fact what the compiler does (rewriting).
-Steve
On 15/11/2010 16:45, Ellery Newcomer wrote:
poking around a little more and I really don't know what's going on.
fun piece of trivia though: while loops get rewritten to for loops, so
for(;;) l1 {
int v;
}
v = 4;
exhibits the same behavior as the while loop.
do loops seem to do the same thing
parser definitely does it for !in, but it doesn't for the other ones,
and I didn't want to go digging all over the place for it.
Also, spec says yes for !in, but is silent for the other ones
On 11/15/2010 01:08 PM, Steven Schveighoffer wrote:
On Mon, 15 Nov 2010 14:06:34 -0500, Ellery Newcomer
On Mon, 15 Nov 2010 14:36:33 -0500, Ellery Newcomer
wrote:
parser definitely does it for !in, but it doesn't for the other ones,
and I didn't want to go digging all over the place for it.
Also, spec says yes for !in, but is silent for the other ones
http://www.digitalmars.com/d/2.0/opera
On Mon, 15 Nov 2010 12:44:24 -0500
bearophile wrote:
> spir:
>
> > 1. name objects automatically
> > I need some objects to know their name (as field on themselves). the only
> > solution I can else imagine is for the user write:
> > x = ...;
> > x.name = "x";
>
> What if you have two
On Monday 15 November 2010 11:47:11 Steven Schveighoffer wrote:
> On Mon, 15 Nov 2010 14:36:33 -0500, Ellery Newcomer
>
> wrote:
> > parser definitely does it for !in, but it doesn't for the other ones,
> > and I didn't want to go digging all over the place for it.
> >
> > Also, spec says yes fo
spir wrote:
On Mon, 15 Nov 2010 12:44:24 -0500
bearophile wrote:
spir:
> 1. name objects automatically
> I need some objects to know their name (as field on themselves). the
only solution I can else imagine is for the user write:
>x = ...;
>x.name = "x";
What if you have two or
a while ago, I assumed that
e1 += e2
gets rewritten as
e1 = e1 + e2
Yeah. It doesn't. It doesn't even behave the same wrt erroneously typed
arguments
On 11/15/2010 02:35 PM, Jonathan M Davis wrote:
As far as is, it doesn't explicitly say that rewriting is done, but, it
does spell out that
On Monday 15 November 2010 12:40:43 Ellery Newcomer wrote:
> a while ago, I assumed that
>
> e1 += e2
>
> gets rewritten as
>
> e1 = e1 + e2
>
> Yeah. It doesn't. It doesn't even behave the same wrt erroneously typed
> arguments
Well, that would potentially be two different set of operator ove
On Mon, 15 Nov 2010 15:40:43 -0500, Ellery Newcomer
wrote:
a while ago, I assumed that
e1 += e2
gets rewritten as
e1 = e1 + e2
Yeah. It doesn't. It doesn't even behave the same wrt erroneously typed
arguments
I understand the care taken, but the spec gives reasons to believe
otherwi
23 matches
Mail list logo
