I've brought this up on here awhile ago, and many people seemed
to be against it. Which I don't agree with, since the
ambiguities it creates are easily addressed (from a design
perspective at least) and only exist so that C-style code is
usable within D. It could work like:
auto func(a, b)
On Friday, 2 August 2013 at 23:51:22 UTC, SteveGuo wrote:
Why is it a bad thing for it to be a systems language? :)
T
I'm just a little bit worry about, when new os borns, D has to
support it, time goes by, D will become another overstuffed C++?
I think it is more of a matter of writing c
"Hans Mustermann" wrote in message
news:ntjgrchqcyedtkjed...@forum.dlang.org...
> On Friday, 2 August 2013 at 19:05:30 UTC, Walter Bright wrote:
>
>> I'm not suggesting breaking support for XP. Just unofficial support,
>> meaning we won't break it, and we'll accept pull requests to fix issues
>
On 08/03/2013 01:05 AM, H. S. Teoh wrote:
Actually, I just pulled git HEAD again, and it's still working fine.
Maybe you just need to update your repo?
...
I think it pulled in the wrong version of druntime.
On 2013-08-03 00:51:19 +, F i L said:
I've brought this up on here awhile ago, and many people seemed to be
against it. Which I don't agree with, since the ambiguities it creates
are easily addressed (from a design perspective at least) and only
exist so that C-style code is usable within
On 2013-08-02 23:27:20 +, Timon Gehr said:
Also, you may want to replace some of the manually implemented ranges
where this makes sense.
Eg, datesInYear can be expressed more to the point as:
auto datesInYear(int year){
return Date(year,1,1).recurrence!((a,n)=>a[n-1]+1.dur!"days")
I've brought this up on here awhile ago, and many people seemed
to be against it. Which I don't agree with, since the ambiguities
it creates are easily addressed (from a design perspective at
least) and only exist so that C-style code is usable within D. It
could work like:
auto func(a, b)
On Sat, Aug 03, 2013 at 01:51:17AM +0200, SteveGuo wrote:
> >
> >Why is it a bad thing for it to be a systems language? :)
> >
> >
> >T
>
> I'm just a little bit worry about, when new os borns, D has to
> support it, time goes by, D will become another overstuffed C++?
C++'s problems aren't all b
Why is it a bad thing for it to be a systems language? :)
T
I'm just a little bit worry about, when new os borns, D has to
support it, time goes by, D will become another overstuffed C++?
On Friday, 2 August 2013 at 08:37:50 UTC, monarch_dodra wrote:
On Friday, 2 August 2013 at 05:35:28 UTC, H. S. Teoh wrote:
void func(S)(S input) if (isSomeString!S) {
string x = to!string(input);
... // use at will
}
+1. I saw this used recently,
The trouble with this is that sometimes people will use a type
without an identifier in order to indicate that the parameter
is not used:
auto Foo(int, unsigned x)
But also note that for lambdas, D does allow the form you
suggest, as there weren't backwards compatibility issues with
it.
On 8/2/2013 1:34 PM, SteveGuo wrote:
I'm not an expert on programming language, if I made a naive issue, just forgive
me:p
We never forgive, and the internet never forgets! :-)
Can we declare a template function like this?
auto Add(a, b) // Note a, b do not have type, that means a and b use
class A
{
auto n;
void foo(auto x) { ... }
}
int main()
{
scope a = new A;
scope b = new A;
a.foo(1); // this means A has a member function "void foo(int
x) {...}"
a.foo(1.1); // this means A has another member function "void
foo(double x) {...}"
// compiler will a
On Sat, Aug 03, 2013 at 01:20:02AM +0200, SteveGuo wrote:
>
> > class A
> > {
> > auto b(auto c) { ... }
> > }
> >
> >What are the template parameters of A?
>
> class A
> {
> void foo(auto x) { ... }
> }
>
> int main()
> {
> scope a = new A;
>
> a.foo(1); //
On 08/03/2013 12:02 AM, H. S. Teoh wrote:
On Thu, Aug 01, 2013 at 10:49:00PM -0700, Walter Bright wrote:
On 8/1/2013 10:24 PM, H. S. Teoh wrote:
Once this last bit worked, though, everything fell into place quickly.
After all unittests were passing, no more bugs were found!! The program
can pri
On 8/2/2013 3:02 PM, H. S. Teoh wrote:
OK, here's a draft of the article:
http://wiki.dlang.org/User:Quickfur/Component_programming_with_ranges
It looks like I may have to sort out some issues with compiler bugs
before officially posting this article, though, since the code
apparently f
On 8/2/2013 3:25 PM, Hans Mustermann wrote:
On Friday, 2 August 2013 at 19:05:30 UTC, Walter Bright wrote:
I'm not suggesting breaking support for XP. Just unofficial support, meaning
we won't break it, and we'll accept pull requests to fix issues with it.
Just to be sure that I understand co
class A
{
auto b(auto c) { ... }
}
What are the template parameters of A?
class A
{
void foo(auto x) { ... }
}
int main()
{
scope a = new A;
a.foo(1); // this means A has a member function "void foo(int
x) {...}"
a.foo(1.1); // this
On Sat, Aug 03, 2013 at 12:51:11AM +0200, SteveGuo wrote:
> D is a system language. I noticed that D support os like win32 via
> standard library.
>
> But I want to know why D was designed to be a system language? Why D
> wasn't designed as a non-system language? Is there any reason?
Why is it a
On Sat, Aug 03, 2013 at 01:03:36AM +0200, SteveGuo wrote:
> >I like this syntax.
> >
> >I'm worried, though, about how it will interact with explicit
> >template parameters. E.g., how would you express this:
> >
> > bool func(R,T,U)(T t, U u) { ... }
> >
> >in the new syntax?
> >
> > bool f
On Fri, Aug 02, 2013 at 03:00:01PM -0700, H. S. Teoh wrote:
> On Fri, Aug 02, 2013 at 08:49:30PM +0200, Timon Gehr wrote:
[...]
> > I get the dreaded forward reference errors with at least DMD 2.060,
> > DMD 2.063 and DMD 2.063.2 and the 2.x build on dpaste.
>
> Can you send me the error messages?
I like this syntax.
I'm worried, though, about how it will interact with explicit
template
parameters. E.g., how would you express this:
bool func(R,T,U)(T t, U u) { ... }
in the new syntax?
bool func(R)(auto t, auto u) { ... }
?
What if we have variadics on either side?
I
D is a system language. I noticed that D support os like win32
via standard library.
But I want to know why D was designed to be a system language?
Why D wasn't designed as a non-system language? Is there any
reason?
On Fri, Aug 02, 2013 at 03:19:33PM -0700, Andrei Alexandrescu wrote:
> On 8/2/13 3:17 PM, Timon Gehr wrote:
> >On 08/03/2013 12:06 AM, Andrej Mitrovic wrote:
> >>On 8/2/13, Andrei Alexandrescu wrote:
> >>>auto fun(auto x, auto y) { … }
> >>>
> >>>Truth be told, at the time of that decision
> >>>pa
On 08/03/2013 12:19 AM, Andrei Alexandrescu wrote:
On 8/2/13 3:17 PM, Timon Gehr wrote:
On 08/03/2013 12:06 AM, Andrej Mitrovic wrote:
On 8/2/13, Andrei Alexandrescu wrote:
auto fun(auto x, auto y) { … }
Truth be told, at the time of that decision
parameter names (viz. x and y) could not be
On Friday, 2 August 2013 at 19:05:30 UTC, Walter Bright wrote:
I'm not suggesting breaking support for XP. Just unofficial
support, meaning we won't break it, and we'll accept pull
requests to fix issues with it.
Just to be sure that I understand correctly what this thread is
about: Are you
On Friday, 2 August 2013 at 22:12:29 UTC, SteveGuo wrote:
void foo(int)
{}
Is perfectly legal.
We could change the language definition, make things like "void
foo(int) {}" illegal
No. Useless breaking change.
On 8/2/13 3:17 PM, Timon Gehr wrote:
On 08/03/2013 12:06 AM, Andrej Mitrovic wrote:
On 8/2/13, Andrei Alexandrescu wrote:
auto fun(auto x, auto y) { … }
Truth be told, at the time of that decision
parameter names (viz. x and y) could not be used in template
constraints. Now they could, so in
On 08/03/2013 12:06 AM, Andrej Mitrovic wrote:
On 8/2/13, Andrei Alexandrescu wrote:
auto fun(auto x, auto y) { … }
Truth be told, at the time of that decision
parameter names (viz. x and y) could not be used in template
constraints. Now they could, so in a way that reopens the question.
You
void foo(int)
{}
Is perfectly legal.
We could change the language definition, make things like "void
foo(int) {}" illegal
void foo(int)
{}
Is perfectly legal.
But we can make a compiler which think its illegal.
void foo(int); // function declaration
void foo(int a) {} // function definition
auto foo(a) {} // template function definition
On 8/2/13, Andrei Alexandrescu wrote:
> auto fun(auto x, auto y) { … }
>
> Truth be told, at the time of that decision
> parameter names (viz. x and y) could not be used in template
> constraints. Now they could, so in a way that reopens the question.
You'd still have to use typeof(x) and typeof(
On Friday, 2 August 2013 at 22:00:44 UTC, SteveGuo wrote:
He meant that when you only have a single token it is parsed
as PARAMTYPE and not varname.
EG:
void foo(int);
Thanks for pointing out my misunderstanding.
But we can make a compiler which can "understand" what we want
it understan
He meant that when you only have a single token it is parsed as
PARAMTYPE and not varname.
EG:
void foo(int);
Thanks for pointing out my misunderstanding.
But we can make a compiler which can "understand" what we want it
understand.
void foo(int); // this is just a declaration, not a de
On Thu, Aug 01, 2013 at 10:49:00PM -0700, Walter Bright wrote:
> On 8/1/2013 10:24 PM, H. S. Teoh wrote:
> >Once this last bit worked, though, everything fell into place quickly.
> >After all unittests were passing, no more bugs were found!! The program
> >can print beautifully laid out calendars w
On Fri, Aug 02, 2013 at 08:49:30PM +0200, Timon Gehr wrote:
> On 08/02/2013 07:24 AM, H. S. Teoh wrote:
> >...
> >Anyway. Enough hand-waving in the air. Let the actual code speak for
> >itself:
> >
> > https://github.com/quickfur/dcal/blob/master/dcal.d
> >...
>
> Which version of the compiler
On Friday, 2 August 2013 at 21:36:38 UTC, SteveGuo wrote:
Note that currently this is parsed as having _only_ PARAMTYPE.
I just tested _only_
void foo(_only_ a)
{
}
but the compiler complaints "undefined identifier _only_"
He meant that when you only have a single token it is parsed as
P
On Friday, 2 August 2013 at 21:29:12 UTC, SteveGuo wrote:
Question is "should we"? It creates syntax ambiguity (a and b
can be already existing types) and does not really improve
language.
Sorry for my pool English:p
I think compiler can detect the difference.
auto Add(a, b) {} // Compiler
On 2013-08-02 21:30:20 +, Dicebot said:
On Friday, 2 August 2013 at 21:20:55 UTC, SteveGuo wrote:
We know that normal function parameter declaration is the form of
"PARAMTYPE param"
Wrong. Specifying only types was perfectly legal in C and remains so in
D. It would have been a major brea
Wrong. Specifying only types was perfectly legal in C and
remains so in D. It would have been a major breaking change.
auto Add(a, b) {}
Is it feasible? "Specifying only types was perfectly legal in C
and emains so in D"
Why don't we change our thinking way? Why we couldn't eliminate
"PAR
Note that currently this is parsed as having _only_ PARAMTYPE.
I just tested _only_
void foo(_only_ a)
{
}
but the compiler complaints "undefined identifier _only_"
On Friday, 2 August 2013 at 21:20:55 UTC, SteveGuo wrote:
We know that normal function parameter declaration is the form
of "PARAMTYPE param"
Wrong. Specifying only types was perfectly legal in C and remains
so in D. It would have been a major breaking change.
Question is "should we"? It creates syntax ambiguity (a and b
can be already existing types) and does not really improve
language.
Sorry for my pool English:p
I think compiler can detect the difference.
auto Add(a, b) {} // Compiler can detect "there is nothing in
front of a and b, so a and
On 08/02/2013 11:20 PM, SteveGuo wrote:
I think it could get pretty confusing. I.e.:
module foo;
struct a { }
struct b { }
module bar;
import foo;
auto Add(a, b) { } // [1]
[1] Here the unsuspecting programmer thinks he's writing a template
function, not knowing that one module h
I think it could get pretty confusing. I.e.:
module foo;
struct a { }
struct b { }
module bar;
import foo;
auto Add(a, b) { } // [1]
[1] Here the unsuspecting programmer thinks he's writing a
template function, not knowing that one module he's importing
actually specifies 'a' an
On Friday, 2 August 2013 at 20:50:00 UTC, SteveGuo wrote:
But I mean if the syntax can be more simple?
auto Add(A, B)(A a, B b); // type A, B appears twice
// Can we just make it more simple?
auto Add(a, b)
{
}
Question is "should we"? It creates syntax ambiguity (a and b can
be already exis
On Friday, 2 August 2013 at 20:50:00 UTC, SteveGuo wrote:
auto Add(A, B)(A a, B b); // Yes, this is the template function
declaration of D manner
But I mean if the syntax can be more simple?
auto Add(A, B)(A a, B b); // type A, B appears twice
// Can we just make it more simple?
auto Add(a, b
On Friday, 2 August 2013 at 01:55:35 UTC, JS wrote:
What is the difference between
class A
{
int x;
}
class A
{
private int _x;
@property int x() { }
@property int x(int v) { }
}
? From the outside world there is suppose to be no difference.
In the first case other modules ca
On Friday, 2 August 2013 at 20:37:55 UTC, monarch_dodra wrote:
On Friday, 2 August 2013 at 20:34:04 UTC, SteveGuo wrote:
I'm not an expert on programming language, if I made a naive
issue, just forgive me:p
Yes, this would have been better asked in .learn, but no matter.
Can we declare a tem
On Friday, 2 August 2013 at 20:34:04 UTC, SteveGuo wrote:
I'm not an expert on programming language, if I made a naive
issue, just forgive me:p
Yes, this would have been better asked in .learn, but no matter.
Can we declare a template function like this?
auto Add(a, b) // Note a, b do not ha
I'm not an expert on programming language, if I made a naive
issue, just forgive me:p
Can we declare a template function like this?
auto Add(a, b) // Note a, b do not have type, that means a and b
use template type
{
return a + b;
}
auto Sub(a, int b) // a uses template type, b is fixed
On 8/2/2013 6:41 AM, Adam D. Ruppe wrote:
On Friday, 2 August 2013 at 09:28:46 UTC, Dejan Lekic wrote:
Windows XP user-base is still very big. I would vote against ditching the XP
support.
Me too. I guess I'd be ok with it being "supported" rather than /supported/, but
XP is still a *lot* of u
On 8/2/2013 2:28 AM, Dejan Lekic wrote:
All I am trying to say is - XP is not dead, yet...
Is it feeling much better?
On 08/02/2013 07:24 AM, H. S. Teoh wrote:
...
Anyway. Enough hand-waving in the air. Let the actual code speak for
itself:
https://github.com/quickfur/dcal/blob/master/dcal.d
...
Which version of the compiler are you using?
I get the dreaded forward reference errors with at least DMD
On Friday, 2 August 2013 at 14:26:12 UTC, Daniel Murphy wrote:
It would be rather silly to stop officially supporting the
second most
popular desktop operating system.
Well, it is no longer supported by Microsoft itself, isn't it?
There is a difference between formally supporting and spendin
H. S. Teoh:
It would be nice to collect these custom ranges and see if
there's some common functionality that can be added to Phobos.
chunkBy seems OK for Phobos.
Bye,
bearophile
On 8/2/2013 1:53 AM, Stewart Gordon wrote:
On 02/08/2013 09:47, Jonathan M Davis wrote:
I'm not sure. Possibly. Given that we previously had code that checked the
version of Windows and used the A functions if it was running on Windows 9x,
there's probably a decent chance that something similar
On Fri, Aug 02, 2013 at 04:06:46PM +, Justin Whear wrote:
> On Thu, 01 Aug 2013 22:24:32 -0700, H. S. Teoh wrote:
> > Now, w.r.t. the roadblocks I alluded to.
> >
> > When I first started working on the code, my goal was to maximize
> > usage of existing Phobos facilities in order to show how
On Thu, 01 Aug 2013 22:24:32 -0700, H. S. Teoh wrote:
> Now, w.r.t. the roadblocks I alluded to.
>
> When I first started working on the code, my goal was to maximize usage
> of existing Phobos facilities in order to show how many batteries D
> already comes with. As it turned out, I could only us
On Friday, 11 May 2012 at 21:53:06 UTC, Jonathan M Davis wrote:
I know that haskell has such a function, and there were a
number of complaints
previously that we _didn't_ have an any function which does
exactly what
std.algorithm.any now does. It's a very functional approach to
use predicates
"Walter Bright" wrote in message
news:ktfgps$2ghh$1...@digitalmars.com...
> On 8/1/2013 10:17 PM, Jonathan M Davis wrote:
>> Regardless, the biggest gain by far will be being able to ditch support
>> for XP
>> and require at least Vista. As bad as Vista was, it had some major
>> improvements to
soywiz:
D didn't had a good IDE allowing refactoring by that moment
That's mostly a tools/ecosystem problem, but perhaps the language
design could help a little to perform the refactoring. How can a
language help refactoring?
Compilation times were huge. I was using lot of compile-time
c
On Friday, 2 August 2013 at 09:28:46 UTC, Dejan Lekic wrote:
Windows XP user-base is still very big. I would vote against
ditching the XP support.
Me too. I guess I'd be ok with it being "supported" rather than
/supported/, but XP is still a *lot* of users and can't be
completely ignored.
I just replied here with my motivations:
https://github.com/soywiz/pspemu/issues/1
"D is just fine to create an emulator. The problem was that I was
doing emergent design, so I was refactoring a lot. And design
flaws caused the refactorings to be massive. D didn't had a good
IDE allowing refac
On Friday, 2 August 2013 at 02:21:25 UTC, Maxim Fomin wrote:
On Thursday, 1 August 2013 at 21:56:46 UTC, John Colvin wrote:
You are asking for an "int" to be be implicitly convertable to
an "A", which isn't possible.
http://dpaste.dzfl.pl/c3cce6e2
import std.stdio;
class A
{
double x;
On Friday, 2 August 2013 at 01:55:35 UTC, JS wrote:
On Friday, 2 August 2013 at 01:46:28 UTC, Jesse Phillips wrote:
I'm going to provide a reduced case for the issue you are
having.
struct Foo {
double x;
alias x this;
}
void main() {
Foo a;
a = 8; // Alias this assignment
asse
On Friday, 2 August 2013 at 11:27:48 UTC, monarch_dodra wrote:
On Friday, 2 August 2013 at 11:19:05 UTC, Tobias Pankrath wrote:
On Friday, 2 August 2013 at 08:46:18 UTC, monarch_dodra wrote:
Without doing this, you face the eternal problem: Should I
return a "string", to give my end user more
On Friday, 2 August 2013 at 11:19:05 UTC, Tobias Pankrath wrote:
On Friday, 2 August 2013 at 08:46:18 UTC, monarch_dodra wrote:
Without doing this, you face the eternal problem: Should I
return a "string", to give my end user more guarantees, when
in fact my char array is perfectly mutable, o
On Friday, 2 August 2013 at 08:46:18 UTC, monarch_dodra wrote:
Without doing this, you face the eternal problem: Should I
return a "string", to give my end user more guarantees, when in
fact my char array is perfectly mutable, or should I return a
char[], forcing my end user to make an idup(o
On Friday, 2 August 2013 at 06:50:46 UTC, monarch_dodra wrote:
On Thursday, 1 August 2013 at 22:10:07 UTC, John Colvin wrote:
My hopes are with fusion. Specifically ITER. My research is on
diagnostics/data analysis for tokamaks, working with the guys
at Culham, UK (MAST and JET). They are cauti
02-Aug-2013 09:51, Sönke Ludwig пишет:
Am 01.08.2013 22:59, schrieb Stewart Gordon:
- Define a mixin template along the lines of __AW in newer versions of
MinGW, so that
version (Unicode) {
alias QwertW Qwert;
} else {
alias QwertA Qwert;
}
can become simply
On Friday, 2 August 2013 at 09:28:46 UTC, Dejan Lekic wrote:
On Thursday, 1 August 2013 at 23:00:09 UTC, Walter Bright wrote:
On 8/1/2013 3:28 PM, Stewart Gordon wrote:
What do people think we should do? Opinions please!
Even supporting XP is problematic because of the badly broken
thread l
On Thursday, 1 August 2013 at 23:00:09 UTC, Walter Bright wrote:
On 8/1/2013 3:28 PM, Stewart Gordon wrote:
What do people think we should do? Opinions please!
Even supporting XP is problematic because of the badly broken
thread local storage support for DLLs in it, which D heavily
relies o
On Friday, August 02, 2013 10:06:34 Stewart Gordon wrote:
> But that does suggest that good old C macros are considerably quicker to
> compile than mixins.
Strings get allocated and operated on when you're doing string mixins rather
than simply doing textual replacement like occurs with macros.
On 02/08/2013 02:55, Mike Parker wrote:
- Define a mixin template along the lines of __AW in newer versions of MinGW,
so that
version (Unicode) {
alias QwertW Qwert;
} else {
alias QwertA Qwert;
}
can become simply
mixin DECLARE_AW!("Qwert");
I would be cau
On 02/08/2013 09:47, Jonathan M Davis wrote:
I'm not sure. Possibly. Given that we previously had code that checked the
version of Windows and used the A functions if it was running on Windows 9x,
there's probably a decent chance that something similar could be done with the
Vista vs pre-Vista t
On Friday, 2 August 2013 at 07:50:28 UTC, Jakob Ovrum wrote:
Places in D that require `string` either do so because they
need the immutable guarantee or they do so out of error (e.g.
should have used a string of const characters instead). The
latter can of course be worked around, but the only
On Friday, August 02, 2013 01:27:11 Walter Bright wrote:
> On 8/2/2013 12:50 AM, Jonathan M Davis wrote:
> > Well, if you want to do that, I'm not against it. I'd actually like to
> > make
> > some changes to std.datetime which require Vista or later, so being able
> > to
> > not bother with XP wou
On Friday, 2 August 2013 at 05:35:28 UTC, H. S. Teoh wrote:
void func(S)(S input) if (isSomeString!S) {
string x = to!string(input);
... // use at will
}
+1. I saw this used recently, and I find it very clever.
On 8/2/2013 12:50 AM, Jonathan M Davis wrote:
Well, if you want to do that, I'm not against it. I'd actually like to make
some changes to std.datetime which require Vista or later, so being able to
not bother with XP would be nice (though I've managed to work around the
problems caused by not hav
On Wednesday, 31 July 2013 at 10:20:57 UTC, Chris wrote:
This is only losely related to D, but I don't fully understand
the separation of component programming and OOP (cf.
https://en.wikipedia.org/wiki/Component-based_software_engineering#Differences_from_object-oriented_programming).
In an OO
On Friday, 2 August 2013 at 05:35:28 UTC, H. S. Teoh wrote:
Recently, I discovered an interesting idiom for dealing with
transient
ranges, esp. w.r.t. strings / char[]. Many places in D require
string,
but sometimes what you have is char[] which can't be converted
to string
except by .idup. But
On Thursday, August 01, 2013 22:41:14 Walter Bright wrote:
> On 8/1/2013 10:17 PM, Jonathan M Davis wrote:
> > Regardless, the biggest gain by far will be being able to ditch support
> > for XP and require at least Vista. As bad as Vista was, it had some major
> > improvements to the Win32 API (lik
On 8/2/13 12:23 AM, Jeff Nowakowski wrote:
On 08/02/2013 01:30 AM, Walter Bright wrote:
We could go on for weeks back and forth with clever ripostes. I don't
really care to, this is the wrong forum for that.
I wasn't interested in "clever ripostes". I was interested in
intellectual honesty.
On 08/02/2013 01:30 AM, Walter Bright wrote:
We could go on for weeks back and forth with clever ripostes. I don't
really care to, this is the wrong forum for that.
I wasn't interested in "clever ripostes". I was interested in
intellectual honesty.
And while this is certainly the wrong foru
On 8/1/2013 11:10 PM, Brad Roberts wrote:
On 8/1/13 10:41 PM, Walter Bright wrote:
On 8/1/2013 10:17 PM, Jonathan M Davis wrote:
Regardless, the biggest gain by far will be being able to ditch support for XP
and require at least Vista. As bad as Vista was, it had some major
improvements to the
On 8/1/2013 11:46 PM, monarch_dodra wrote:
That's in the US. Most of Europe is on nuclear power.
If we set aside controversies on the dangers of plant meltdown (BTW, Fukushima
was hit by a mag 9 *and* a tidal wave, just saying), it *is* about over 9000
times greener.
IMO, nuclear power is like
88 matches
Mail list logo
