On Fri, 04 Dec 2009 20:05:13 -0800, Walter Bright
newshou...@digitalmars.com wrote:
Probably the biggest thing is opDispatch!
http://www.digitalmars.com/d/1.0/changelog.html
http://ftp.digitalmars.com/dmd.1.053.zip
http://www.digitalmars.com/d/2.0/changelog.html
Walter Bright wrote:
Probably the biggest thing is opDispatch!
http://www.digitalmars.com/d/1.0/changelog.html
http://ftp.digitalmars.com/dmd.1.053.zip
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.037.zip
Many thanks to the numerous people who contributed
Extrawurst wrote:
Walter Bright wrote:
Probably the biggest thing is opDispatch!
http://www.digitalmars.com/d/1.0/changelog.html
http://ftp.digitalmars.com/dmd.1.053.zip
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.037.zip
Many thanks to the numerous
Extrawurst wrote:
Extrawurst wrote:
Walter Bright wrote:
Probably the biggest thing is opDispatch!
http://www.digitalmars.com/d/1.0/changelog.html
http://ftp.digitalmars.com/dmd.1.053.zip
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.037.zip
Many thanks
Extrawurst wrote:
Walter Bright wrote:
Probably the biggest thing is opDispatch!
http://www.digitalmars.com/d/1.0/changelog.html
http://ftp.digitalmars.com/dmd.1.053.zip
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.037.zip
Many thanks to the numerous
Walter Bright wrote:
Probably the biggest thing is opDispatch!
http://www.digitalmars.com/d/1.0/changelog.html
http://ftp.digitalmars.com/dmd.1.053.zip
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.037.zip
Many thanks to the numerous people who contributed
Walter Bright wrote:
Probably the biggest thing is opDispatch!
http://www.digitalmars.com/d/1.0/changelog.html
http://ftp.digitalmars.com/dmd.1.053.zip
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.037.zip
Many thanks to the numerous people who contributed
Extrawurst wrote:
Walter Bright wrote:
Probably the biggest thing is opDispatch!
http://www.digitalmars.com/d/1.0/changelog.html
http://ftp.digitalmars.com/dmd.1.053.zip
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.037.zip
Many thanks to the numerous
Andrei Alexandrescu Wrote:
After a very long delay, Safari finally updated the TDPL draft on their
Rough Cuts service (http://my.safaribooksonline.com/roughcuts). They
claim things will be back to normal now, and that another update
(containing almost the entire book) is due in a week.
There's a large number of changes!
I don't understand what No more comma operators allowed between [ ]. means.
I have tried the D2 compiler a little with this code:
import std.stdio: writeln;
import std.math: pow;
struct S1 { int x; }
void main() {
struct S2 { int x; }
static struct S3
bearophile bearophileh...@lycos.com wrote in message
news:hfdt87$1nu...@digitalmars.com...
There's a large number of changes!
I don't understand what No more comma operators allowed between [ ].
means.
I assume that means:
int[1,2,3] foo; // - formerly created an int[3], now (presumably)
bearophile wrote:
5 ^^ 2 doesn't work yet, I guess it's not implemented yet.
But what do I have to import from math to use 5.2 ^^ 2 ?
Anyway, the need to explicitly import something to use a built-in operator like
^^ looks like a bad idea.
A very bad idea indeed! The idea is to save
Walter Bright, el 4 de diciembre a las 20:05 me escribiste:
Probably the biggest thing is opDispatch!
http://www.digitalmars.com/d/1.0/changelog.html
http://ftp.digitalmars.com/dmd.1.053.zip
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.037.zip
Ary Borenszweig:
Can't import std.math : pow; be added to the current module when this
is needed?
Note that this code doesn't compile:
import std.stdio: writeln;
import std.math: pow;
void main() {
writeln(5.2 ^^ 2);
}
This is what the compiler shows:
test.d(5): Error: undefined
== Quote from Don (nos...@nospam.com)'s article
All kinds of stuff is still missing. a ^^ b won't be constant-folded,
for example.
It's desperately important that the language spec becomes stable before
Andrei's book comes out. That leaves only a couple more releases left in
D2 where features
dsimcha wrote:
== Quote from Don (nos...@nospam.com)'s article
All kinds of stuff is still missing. a ^^ b won't be constant-folded,
for example.
It's desperately important that the language spec becomes stable before
Andrei's book comes out. That leaves only a couple more releases left in
D2
On Sat, 05 Dec 2009 05:05:13 +0100, Walter Bright
newshou...@digitalmars.com wrote:
Probably the biggest thing is opDispatch!
http://www.digitalmars.com/d/1.0/changelog.html
http://ftp.digitalmars.com/dmd.1.053.zip
http://www.digitalmars.com/d/2.0/changelog.html
Simen kjaeraas wrote:
I get a compile error:
std\conv.d(2506): Error: undefined identifier module traits.staticIndexOf
Line 2506 in std.conv should be changed from
if (std.traits.staticIndexOf!(Unqual!S, uint, ulong) = 0
isSomeString!T)
to
if (std.typetuple.staticIndexOf!(Unqual!S,
On Sun, 06 Dec 2009 03:35:42 +0100, Walter Bright
newshou...@digitalmars.com wrote:
Simen kjaeraas wrote:
I get a compile error:
std\conv.d(2506): Error: undefined identifier module
traits.staticIndexOf
Line 2506 in std.conv should be changed from
if
Would it be a good idea to allow overloading on opDispatch to make the
following compile, what do you think?
import std.stdio;
class C
{
void opDispatch(string s, ARGS...) (ARGS args)
{
writefln(S.opDispatch('%s', %s), s, typeof(args).stringof);
}
void foo (string s)
Jacob Carlborg wrote:
Would it be a good idea to allow overloading on opDispatch to make the
following compile, what do you think?
import std.stdio;
class C
{
void opDispatch(string s, ARGS...) (ARGS args)
{
writefln(S.opDispatch('%s', %s), s, typeof(args).stringof);
}
Walter Bright:
http://jessenoller.com/2009/12/04/pythons-moratorium-lets-think-about-this/
That blog post doesn't list the costs for Python of that stasis, some developer
may leave looking for more interesting grassy fields to work on.
I agree that D2 has to give time to people to create a D2
The strange part is that, for some reason, this works:
import std.stdio: writeln;
class Foo {
float bla() { return 0.0; }
void foo() {}
}
void exportObject( TClass, members... )()
{
foreach( uint i, member; members )
writeln( typeid(typeof(__traits(getVirtualFunctions, Foo,
Currently in D (r283) opPow is left-associative:
import std.stdio;
void main() {
// prints 19683 instead of 7625597484987:
writeln(3.0 ^^ 3.0 ^^ 3.0);
}
But the mathematical convention is a^b^c == a^(b^c).
Languages which the power operator is right-associative (3^3^3==7e12):
Walter Bright wrote:
Nice to see some statistical evidence of what we've known to be true for
a long time:
http://www.reddit.com/r/programming/comments/a96kd/embeddedcom_the_use_of_assertions_a_new_study/
The new study is 2006 vintage.
Andrei
retard wrote:
Mon, 30 Nov 2009 04:51:19 +, dsimcha wrote:
By
far the two most important pieces of I/O functionality I need are:
1. Read a text file line-by-line.
foreach (line; new Lines!(char) (new File (foobar.txt)))
Cout (line).newline;
}
2. Read a whole file into an array of
KennyTM~:
But the mathematical convention is a^b^c == a^(b^c).
Languages which the power operator is right-associative (3^3^3==7e12):
- Python, Haskell, Ruby, Perl, Mathematica, Bash.
Doing things as in mathematical convention, Mathematica and Python sounds
better.
This was just the release
Daniel Ribeiro Maciel:
Note that this foreach is a static foreach because members is a tuple, it's not
an array:
void exportObject( TClass, members... )()
{
foreach( uint i, member; members )
writeln( typeid(typeof(__traits(getVirtualFunctions, Foo, members[i])
)) );
}
I
== Quote from bearophile (bearophileh...@lycos.com)'s article
This was just the release V.0.1 of the built-in pow, it needs several
improvements :-)
See also bug 3577. ^^ should have higher precedence than * and / to be
consistent
w/ mathematical convention.
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.
bearophile wrote:
KennyTM~:
But the mathematical convention is a^b^c == a^(b^c).
Languages which the power operator is right-associative (3^3^3==7e12):
- Python, Haskell, Ruby, Perl, Mathematica, Bash.
Doing things as in mathematical convention, Mathematica and Python sounds
better.
This
On Fri, 04 Dec 2009 21:15:39 -0500, Don nos...@nospam.com wrote:
Phil Deets wrote:
On Fri, 04 Dec 2009 11:06:31 -0500, Don nos...@nospam.com wrote:
Here's a table of equivalences.
a!=b (a!=a) || (b!=b)
ab (a==a) (b==b) (a!=b)
a!b (a!=a) || (b!=b) || (a!=b)
a=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.
On Sat, 05 Dec 2009 16:08:00 -0500, Nick Sabalausky a...@a.a 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
Don nos...@nospam.com 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
Steven Schveighoffer schvei...@yahoo.com wrote in message
news:op.u4hhjisgeav...@localhost.localdomain...
On Sat, 05 Dec 2009 16:08:00 -0500, Nick Sabalausky a...@a.a 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
Don nos...@nospam.com wrote in message
news:hfei3u$kv...@digitalmars.com...
bearophile wrote:
KennyTM~:
But the mathematical convention is a^b^c == a^(b^c).
Languages which the power operator is right-associative (3^3^3==7e12):
- Python, Haskell, Ruby, Perl, Mathematica, Bash.
Doing
On 12/05/2009 03:39 PM, Nick Sabalausky wrote:
Steven Schveighofferschvei...@yahoo.com wrote in message
news:op.u4hhjisgeav...@localhost.localdomain...
On Sat, 05 Dec 2009 16:08:00 -0500, Nick Sabalauskya...@a.a wrote:
I just noticed in D1 that the values for the cases in a switch must be
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
Ellery Newcomer ellery-newco...@utulsa.edu wrote in message
news:hfekll$pb...@digitalmars.com...
On 12/05/2009 03:39 PM, Nick Sabalausky wrote:
Steven Schveighofferschvei...@yahoo.com wrote in message
news:op.u4hhjisgeav...@localhost.localdomain...
On Sat, 05 Dec 2009 16:08:00 -0500, Nick
Sean Kelly s...@invisibleduck.org 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
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-time.
I
Rainer Deyke rain...@eldwood.com 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 to
Nick Sabalausky Wrote:
Sean Kelly s...@invisibleduck.org 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
On 12/05/2009 04:19 PM, Nick Sabalausky wrote:
Ellery Newcomerellery-newco...@utulsa.edu 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
Hello Ellery,
On 12/05/2009 04:19 PM, Nick Sabalausky wrote:
Ellery Newcomerellery-newco...@utulsa.edu 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
Hello Nick,
Sean Kelly s...@invisibleduck.org 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?
BCS n...@anon.com 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;
Nick Sabalausky wrote:
Rainer Deyke rain...@eldwood.com 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
Nick Sabalausky wrote:
Ellery Newcomer ellery-newco...@utulsa.edu 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
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;
Sean Kelly s...@invisibleduck.org wrote in message
news:hfeqbg$143...@digitalmars.com...
Nick Sabalausky Wrote:
Sean Kelly s...@invisibleduck.org 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
Rainer Deyke rain...@eldwood.com wrote in message
news:hfeu0m$1af...@digitalmars.com...
Nick Sabalausky wrote:
Rainer Deyke rain...@eldwood.com 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
grauzone n...@example.net wrote in message
news:hfeu6p$1ap...@digitalmars.com...
Nick Sabalausky wrote:
Ellery Newcomer ellery-newco...@utulsa.edu 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*
-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 switch
BCS n...@anon.com 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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ellery Newcomer wrote:
On 12/05/2009 04:19 PM, Nick Sabalausky wrote:
Ellery Newcomerellery-newco...@utulsa.edu wrote in message
More so than remembering to type break after each case block?
Good point, but that's really a separate issue.
div0 d...@users.sourceforge.net 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 Newcomerellery-newco...@utulsa.edu wrote in message
More so than remembering
Hello Nick,
BCS n...@anon.com 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:
BCS n...@anon.com wrote in message
news:a6268ffdcc98cc43ebb9955...@news.digitalmars.com...
Hello Nick,
BCS n...@anon.com 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-- ==
BCS n...@anon.com 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)
|
Walter Bright newshou...@digitalmars.com writes:
Thanks, I also discovered that Ada supports it.
As does Common Lisp with the dynamic variable *read-base*¹, the
sharpsign R reader macro², and, less interestingly, the function
parse-integer³.
Footnotes:
¹
Nick Sabalausky wrote:
Rainer Deyke rain...@eldwood.com 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
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.
Lionello Lunesu wrote:
Is anybody else here experiencing problems with Thunderbird 3 RC?
I use thunderbird 2.0.0.23 and am not having a problem here.
On 12/05/2009 08:21 PM, Lionello Lunesu wrote:
Is anybody else here experiencing problems with Thunderbird 3 RC? On my
laptop many post that are clearly replies to an existing thread appear
as new top-level posts.
When I first started using Thunderbird 3 beta this happened in my IMAP
folder as
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?
Don wrote:
bearophile wrote:
KennyTM~:
But the mathematical convention is a^b^c == a^(b^c).
Languages which the power operator is right-associative (3^3^3==7e12):
- Python, Haskell, Ruby, Perl, Mathematica, Bash.
Doing things as in mathematical convention, Mathematica and Python
sounds
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
Tim Matthews wrote:
Don wrote:
bearophile wrote:
KennyTM~:
But the mathematical convention is a^b^c == a^(b^c).
Languages which the power operator is right-associative (3^3^3==7e12):
- Python, Haskell, Ruby, Perl, Mathematica, Bash.
Doing things as in mathematical convention, Mathematica
Why do YOU think D failed? What model has the D-man followed? How is that model
bad? Is it bad? I know so (duh). D model in a nutshell: a child who influences
other children. What is wrong with this model? Is the D-man bad? Was he good
once but now cashing in so now bad? They imprison people
On Sat, 05 Dec 2009 21:21:57 -0500, Lionello Lunesu
l...@lunesu.remove.com wrote:
On my laptop many post that are clearly replies to an existing thread
appear
as new top-level posts.
I use Opera 10.10 and this happens to me too.
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
Don wrote:
It was a quick patch to determine if Walter could be swayed to include
it, if he didn't need to implement it. I didn't get any positive
feedback about it until it was put into svn.
Ok thanks a lot for getting a truly important operator implemented. I
tried to give my feedback in
BCS wrote:
Troll.
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
Should we sack lazy? I'd like it to have a reasonable replacement. Ideas
are welcome!
Andrei
Andrei Alexandrescu wrote:
Should we sack lazy? I'd like it to have a reasonable replacement. Ideas
are welcome!
Andrei
According to the doc page:
http://www.digitalmars.com/d/2.0/lazy-evaluation.html
you (and/or Tomasz Stachowiak) were the one who suggested it in the
first place. How'd it
Tomek Sowiñski:
How do I achieve this with std.format?
I think you can't (and I haven't had the need to do it).
Bye,
bearophile
bearophile wrote:
Tomek Sowiñski:
How do I achieve this with std.format?
I think you can't (and I haven't had the need to do it).
It's somtimes needed with I18N code.
I don't suppose there's an easy general way to get the paramaters of a
templated type just from the type itself? Ie, a way to get around this:
class Foo(char[] str) {}
static assert(Foo!(a).stringof != Foo!(b).stringof)
// ^ fails because it evaluates to Foo != Foo
I can probably work around it
Tomek Sowiński wrote:
An extract from java.util.Formatter docs:
// Explicit argument indices may be used to re-order output.
formatter.format(%4$2s %3$2s %2$2s %1$2s, a, b, c, d)
// - d c b a
How do I achieve this with std.format? The ddocs only say that variadic
arguments are consumed in
Greetings!
I have this program,
import dfl.all;
import myform2;
void main()
{
Form d = new MyForm();
d.text = Hello...;
//d.Name.text = name;
d.show();
}
that compiles fine. Here is myform2 code:
/*
Generated by Entice Designer
Entice Designer written by Christopher E. Miller
jicman Wrote:
However, when I uncomment the this line, //d.Name.text = name;,
import dfl.all;
import myform2;
void main()
{
Form d = new MyForm();
d.text = Hello...;
d.Name.text = name;
d.show();
}
I dont have DFL installed, but try this:
import dfl.all;
import
aalm Wrote:
jicman Wrote:
However, when I uncomment the this line, //d.Name.text = name;,
import dfl.all;
import myform2;
void main()
{
Form d = new MyForm();
d.text = Hello...;
d.Name.text = name;
d.show();
}
I dont have DFL installed, but try this:
jicman wrote:
aalm Wrote:
import dfl.all;
import myform2;
void main()
{
//Form d = new MyForm();
//MyForm d = new MyForm();
auto d = new MyForm();
d.text = Hello...;
d.Name.text = name;
d.show();
}
thanks. That worked. Would you care to explain? :-) I know what
On Sat, Dec 5, 2009 at 5:36 PM, Nick Sabalausky a...@a.a wrote:
I don't suppose there's an easy general way to get the paramaters of a
templated type just from the type itself? Ie, a way to get around this:
class Foo(char[] str) {}
static assert(Foo!(a).stringof != Foo!(b).stringof)
// ^
On Sun, 06 Dec 2009 02:36:58 +0100, Nick Sabalausky a...@a.a wrote:
I don't suppose there's an easy general way to get the paramaters of a
templated type just from the type itself? Ie, a way to get around this:
class Foo(char[] str) {}
static assert(Foo!(a).stringof != Foo!(b).stringof)
// ^
Inspired by Nick's post on stringof weirdness, I started wondering - is
there a way to get ahold of the FQN of the template (not the
instantiation), given an instantiation? Same goes for getting a typetuple
of the parameters. Anyone know?
Basically, what I thought might work would be:
template
http://d.puremagic.com/issues/show_bug.cgi?id=3575
Summary: CTFE: member structs not initialized correctly
Product: D
Version: 1.051
Platform: Other
OS/Version: Windows
Status: NEW
Keywords: patch, rejects-valid
http://d.puremagic.com/issues/show_bug.cgi?id=3575
--- Comment #1 from Don clugd...@yahoo.com.au 2009-12-05 01:56:24 PST ---
Created an attachment (id=522)
Patch against DMD2.037 svn 283.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving
http://d.puremagic.com/issues/show_bug.cgi?id=3576
Summary: Can't overload explicitly instantiated template
functions
Product: D
Version: future
Platform: Other
OS/Version: Windows
Status: NEW
Keywords:
http://d.puremagic.com/issues/show_bug.cgi?id=3577
Summary: Wrong precedence for opPow
Product: D
Version: future
Platform: Other
OS/Version: Windows
Status: NEW
Keywords: wrong-code
Severity: major
http://d.puremagic.com/issues/show_bug.cgi?id=3578
Summary: Impossible to run a struct invariant using assert(s)
Product: D
Version: 1.041
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
http://d.puremagic.com/issues/show_bug.cgi?id=3579
Summary: Broken Links to Compiler
Product: D
Version: unspecified
Platform: Other
URL: http://www.digitalmars.com/d/
OS/Version: All
Status: NEW
Severity:
http://d.puremagic.com/issues/show_bug.cgi?id=3577
Don clugd...@yahoo.com.au changed:
What|Removed |Added
CC||clugd...@yahoo.com.au
---
http://d.puremagic.com/issues/show_bug.cgi?id=3577
--- Comment #2 from Don clugd...@yahoo.com.au 2009-12-05 12:56:29 PST ---
To make it right-associative, change the key line in parsePowExp into:
---
case TOKpow: nextToken(); e2 = parsePowExp(); e = new PowExp(loc,e,e2);
continue;
--
http://d.puremagic.com/issues/show_bug.cgi?id=3420
--- Comment #15 from Vladimir thecybersha...@gmail.com 2009-12-05 13:15:26
PST ---
So, my programs relied on a bug in DMD, which was recently rightfully fixed.
Well, that sucks.
Hoping your patch is accepted.
--
Configure issuemail:
http://d.puremagic.com/issues/show_bug.cgi?id=3580
Summary: Update docs s/invariant/immutable/
Product: D
Version: unspecified
Platform: Other
URL: http://www.digitalmars.com/d/2.0/features2.html
OS/Version: Linux
1 - 100 of 105 matches
Mail list logo
