Robert Jacques:
What I worry about though is variable hijacking rules. e.g.
auto b = 5;
reduce!\a+b(map!\a+b([1,2,3,4));
Right, it's a bit too much magical and inflexible for my taste.
bye,
bearophile
On 2011-09-22 23:46, Walter Bright wrote:
On 9/22/2011 1:13 PM, Jacob Carlborg wrote:
I function/delegate that returns a value should be implicitly
converted to a
function/delegate that returns void.
That doesn't work in some cases - consider a function that returns an
object that the caller
Jacob Carlborg d...@me.com wrote in message
news:j5h98l$ors$1...@digitalmars.com...
What I'm saying is that you can ignore the returned value of a delegate
therefore I think it should be possible implicitly convert a delegate
returning a value, to a delegate returning void. The same for
On 2011-09-22 23:08, bearophile wrote:
Andrei Alexandrescu:
A function literal should be comparable to another for equality.
Are you willing to explain me why, and show an use case?
Bye,
bearophile
When using lambdas as event handlers:
class Foo
{
event[] events;
void
On 2011-09-22 22:54, Andrei Alexandrescu wrote:
On 9/21/11 5:17 PM, Walter Bright wrote:
I've collected a few from various languages for comparison:
[snip]
I think we should do the following:
1. Introduce a new token =
2. Add this rewrite to the grammar:
symbol = expression
translates to
On 2011-09-23 08:42, Daniel Murphy wrote:
Jacob Carlborgd...@me.com wrote in message
news:j5h98l$ors$1...@digitalmars.com...
What I'm saying is that you can ignore the returned value of a delegate
therefore I think it should be possible implicitly convert a delegate
returning a value, to a
Robert Jacques sandf...@jhu.edu wrote
What I worry about though is variable hijacking rules. e.g.
auto b = 5;
reduce!\a+b(map!\a+b([1,2,3,4));
Nice.
What if we extend your proposal to
\(comma_separated_params)simple_expression
\(comma_separated_params){expressions}
Then no variable
While we are about rewrites, it would be nice one:
symbol := expression; - auto symbol = expression;
1. shorter
2. conspicuous, more readable.
3. highlights distinction between assignment and initialization.
4. will not break any existing code.
Walter Bright wrote...
Once subtlety that Andrei and I suspect will have a huge impact in the future
is
that we've carefully designed the semantics of structs so they can be moved
around in memory with a simple bitcopy.
(In contrast, C++ must invoke the copy constructor.)
Only if a user
On 9/22/2011 11:55 PM, Jacob Carlborg wrote:
On 2011-09-23 08:42, Daniel Murphy wrote:
void delegate () foo = { bar(); };
Why can't the compiler do something similar automatically. Then we won't have
the problem if a lambda returns void or a value.
1. This can get arbitrarily expensive if
Alex_Dovhal alex_dov...@yahoo.com wrote
reduce!\(a)a+b(map!\(x)x+b([1,2,3,4));
Sorry, my mistake
reduce!\(a,b)a+b(map!\(x)x+b([1,2,3,4));
Timon Gehr , dans le message (digitalmars.D:145067), a écrit :
I did: http://pastebin.com/2rEdx0RD
Nice!
port of some haskell code from RosettaCode (run it ~20 min to get
results, haskell runs in less than 2s)
http://pastebin.com/Vx4hXvaT
The main performance issue is the garbage
On 2011-09-23 09:34, Walter Bright wrote:
On 9/22/2011 11:55 PM, Jacob Carlborg wrote:
On 2011-09-23 08:42, Daniel Murphy wrote:
void delegate () foo = { bar(); };
Why can't the compiler do something similar automatically. Then we
won't have
the problem if a lambda returns void or a value.
Andrei Alexandrescu , dans le message (digitalmars.D:145023), a écrit :
What is the problem with just inferring the `return`, allowing you to replace
(a,b) { return a + b; }
with
(a, b) { a + b; }
The objection is that it introduces a number of questions:
1. How about using
Jacob Carlborg , dans le message (digitalmars.D:145083), a écrit :
On 2011-09-22 22:54, Andrei Alexandrescu wrote:
On 9/21/11 5:17 PM, Walter Bright wrote:
I've collected a few from various languages for comparison:
[snip]
I think we should do the following:
1. Introduce a new token =
2.
zeljkog , dans le message (digitalmars.D:145087), a écrit :
While we are about rewrites, it would be nice one:
symbol := expression; - auto symbol = expression;
1. shorter
2. conspicuous, more readable.
3. highlights distinction between assignment and initialization.
4. will not break
On 9/23/2011 12:27 AM, Heinz Saathoff wrote:
Walter Bright wrote...
Once subtlety that Andrei and I suspect will have a huge impact in the future is
that we've carefully designed the semantics of structs so they can be moved
around in memory with a simple bitcopy.
(In contrast, C++ must invoke
Walter Bright , dans le message (digitalmars.D:145096), a écrit :
On 9/23/2011 12:27 AM, Heinz Saathoff wrote:
Walter Bright wrote...
Once subtlety that Andrei and I suspect will have a huge impact in the
future is
that we've carefully designed the semantics of structs so they can be moved
Le 23/09/2011 05:38, Andrei Alexandrescu a écrit :
http://www.reddit.com/r/programming/comments/kooiy/dangling_else_yet_again/
Andrei
This is a great idea. I'm used to use tools like checkstyle in java (or
some others depending on the language) that trigger an error if an if
statement
I recently faced a problem in java. I have lots of classes
inheriting from the same superclass. Thoses classes has to conform to
some behaviour expected when manipulation the superclass as Liskov
substitution principle says.
This is definitvelly hard to achieve. Solution promoted on
On Mon, Jul 18, 2011 at 8:18 PM, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
[snip..]
We need to keep this key strategic advantage. First off, the fact that this
code isn't accepted:
BinaryHeap!(uint[], function (a, b) {return a b;}) heap;
is a clear bug.
Worst case,
The only thing that D unittest do, is executing code if you
pass -unittest to the compiler. What you do in this code is entirely
up to you.
So, I think the answer is no. No you can't do this with
the current language and standard library.
When I started learning D, I thought the way D handles
class Superclass
{
abstract int do_some_stuff();
abstract int do_some_other_stuff();
}
class Foo1 : Superclass
class Foo2 : Superclass
class Foo3 : Superclass
unittest
{
// get an instance of all classes
Superclass[] instances = [new Foo1(), new Foo2(), new
On 2011-09-23 10:50, Christophe wrote:
Jacob Carlborg , dans le message (digitalmars.D:145083), a écrit :
On 2011-09-22 22:54, Andrei Alexandrescu wrote:
On 9/21/11 5:17 PM, Walter Bright wrote:
I've collected a few from various languages for comparison:
[snip]
I think we should do the
bearophile , dans le message (digitalmars.D:145005), a écrit :
So with a lconst array you are allowed to change its contents, but not
reassign it or change its length. A lconst doesn't implicitly cast to
immutable.
A solution to your problems could be to use a headconst keyword or
library
On 9/23/2011 12:06 AM, Jonathan M Davis wrote:
Okay. The review period for the region allocator is over (actually, it was
over about 2 days ago, but I've been busy and forgot to post about it). So,
the question is: Is it ready for a vote, or does it need further revision and
review?
Looking
So many times did i feel the need for this feature:
// -- first module --
module first;
static version = MY_API;
/*
* My API implementation.
*/
// -- second module --
module second;
import first;
version(MY_API)
{
// My API usage.
}
The behavior is
Yep, I'd also like defined versions to be global, but the problem is this
introduces an order-of-evaluation issue.
What if module second is processed before module one?
Also what if you compile each module separately with -c?
On Fri, 23 Sep 2011 06:44:44 +0300, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 9/22/11 9:11 PM, so wrote:
On Fri, 23 Sep 2011 02:40:11 +0300, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 9/22/11 6:00 PM, so wrote:
On Thu, 22 Sep 2011 17:07:25 +0300, Andrei
On 09/23/2011 10:07 AM, Christophe wrote:
Timon Gehr , dans le message (digitalmars.D:145067), a écrit :
I did: http://pastebin.com/2rEdx0RD
Nice!
port of some haskell code from RosettaCode (run it ~20 min to get
results, haskell runs in less than 2s)
http://pastebin.com/Vx4hXvaT
The
This is the way to do it in D:
// -- first module --
module first;
enum USE_MY_API = true;
/*
* My API implementation.
*/
// -- second module --
module second;
import first;
static if (USE_MY_API)
{
// My API usage.
}
One idiom used in C/C++ is
#if
On 23/09/2011 13:22, dsimcha wrote:
resize() will be changed to:
size_t resize(void* ptr, size_t minBytes, size_t nBytes);
where minBytes is the minimum amount to declare success and nBytes is
the desired amount.
and the value returned is the new size, which will always be between
minBytes
The same way C/C++ does it: put it into a single .di file and import it from
both
implementation and client code.
Not exactly.
You'll also need to include code, which checks if the symbol API_VER is defined
before checking it's value. This will make the code bloated. One way to do it is
to define a template which takes the symbol in the form of a string, but that
would look very ugly.
Gor F. Gyolchanyan gor.f.gyolchan...@gmail.com wrote in message
news:j5i2kv$2abh$1...@digitalmars.com...
Not exactly.
You'll also need to include code, which checks if the symbol API_VER is
defined
before checking it's value. This will make the code bloated. One way to do
it is
to define
== Quote from Alix Pexton (alix.dot.pex...@gmail.dot.com)'s article
On 23/09/2011 13:22, dsimcha wrote:
resize() will be changed to:
size_t resize(void* ptr, size_t minBytes, size_t nBytes);
where minBytes is the minimum amount to declare success and nBytes is
the desired amount.
and
If you wanted to use existance of a symbol instead of an enum's value,
static if(is(typeof())) should do the job.
Essentially, static if can already do what you're asking for, and is much
more flexible.
Which again raises the question why we have version at all.
I know it has its very own
I suggest to rewrite the version functionality as follows.
Replace all existing functionality regarding version with a single compile-time
built-in construct (much like the `is` expression)
version(/* boolean expression */)
, which will returns true if all symbols withing the expression are
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s
article
On 09/22/11 16:08, bearophile wrote:
Andrei Alexandrescu:
A function literal should be comparable to another for
equality.
Are you willing to explain me why, and show an use case?
An important application is
Am 23.09.2011, 17:14 Uhr, schrieb Gor F. Gyolchanyan
gor.f.gyolchan...@gmail.com:
I suggest to rewrite the version functionality as follows.
Replace all existing functionality regarding version with a single
compile-time
built-in construct (much like the `is` expression)
version(/*
Well, i know, that it breaks code, so i intended it for D3.
About enums:
the version keyword can also be made a storage class for global compile-time
declarations to distinguish version identifiers with all other identifiers.
I have a proposal to introduce and optional explicit separation of
compile-time facilities from run-time facilities.
There is a new keyword, called compiletime (or something similar).
The keyword can be used with `is` expression to detect whether the current
scope is executing in compile-time or
I hope there's no D3 for a very long time. Maybe 2020.
On Fri, 23 Sep 2011 11:51:35 -0400, Gor F. Gyolchanyan
gor.f.gyolchan...@gmail.com wrote:
I have a proposal to introduce and optional explicit separation of
compile-time facilities from run-time facilities.
There is a new keyword, called compiletime (or something similar).
The keyword can be
On Thu, 22 Sep 2011 11:22:10 +0200, Jacob Carlborg d...@me.com wrote:
auto newrange = filter!a5(map!2*a(range));
At first some people get the heebiejeebies when seeing string-based
lambda and the implicit naming convention for unary and binary
functions. More importantly, there's the
Adam Ruppe destructiona...@gmail.com wrote in message
news:j5iac7$2ole$1...@digitalmars.com...
I hope there's no D3 for a very long time. Maybe 2020.
I completely agree.
About enums:
the version keyword can also be made a storage class for global
compile-time
declarations to distinguish version identifiers with all other
identifiers.
How would that be superior to 'version = identifier;'?
I've been out of the 'loop' with D for quite awhile now so I haven't been
keeping up with current developments.
I will have a need for a decent 64-bit compiled language soon and I was
wondering how close D is away from this.
--
Derek Parnell
Melbourne, Australia
Steven Schveighoffer schvei...@yahoo.com wrote in message
news:op.v19qwjhqeav7ka@localhost.localdomain...
All of the rest of your points are solved with static if(__ctfe)
-Steve
You can't use __ctfe with static if - you can only use it where a runtime
variable would be used.
If you instantiate a variable with a function call at compile-time
then that function shouldn't be compiled in (AFAIK) unless it's
referenced elsewhere. And for disallowing user-code to use such a
function that's what access specifiers are for. The beauty of D is
that you write a function once and
About enum: it still stays. at least until D3 or so.
enum has it's own meaning too. the variable part is the least important part of
what i presented.
Not qite. __ctfe can solve many problems, but, for example, you can't use __ctfe
to determine whether you should use to!string or toStringNow.
because version = identifier is only local to a module.
because version can be either an identifier or an integer, whereas the version
tagged variable can be anything (string, for example).
Why don't you want D to have a backwards compatibility breaking release?
D2 got here, but D1 is still out there and gets it's occasional bug-fixes.
Having a backwards compatibility breaking release is a good way to fix mistakes,
made in the past. Not doing so leads to overly complicated and
Derek Wrote:
I've been out of the 'loop' with D for quite awhile now so I haven't been
keeping up with current developments.
I will have a need for a decent 64-bit compiled language soon and I was
wondering how close D is away from this.
--
Derek Parnell
Melbourne, Australia
About the write once: i agree, it's a valuable feature of D, regarding CTFE.
But there are many times, where a function can be made to be much faster if some
of it's arguments are known at compile-time.
Writing those kind of functions involves having lots of different kind of
templates with
== Quote from Derek (ddparn...@bigpond.com)'s article
I've been out of the 'loop' with D for quite awhile now so I haven't been
keeping up with current developments.
I will have a need for a decent 64-bit compiled language soon and I was
wondering how close D is away from this.
DMD now has a
It's great that you have taken an interest in the development of D!
Some of this is already in the language in other forms (enum, for instance)
and some has been discussed before (searching the newsgroup archive for
static arguments should find it) and rejected. The bar for new language
Gor F. Gyolchanyan gor.f.gyolchan...@gmail.com wrote in message
news:j5ibrn$2rn8$1...@digitalmars.com...
Why don't you want D to have a backwards compatibility breaking release?
D2 got here, but D1 is still out there and gets it's occasional bug-fixes.
Having a backwards compatibility
There's several reasons backward compatibility is important:
1) Breaking it annoys me. There's still stuff I like for new features,
so I'm not at the point where I'll never update again yet, but I
don't want my code to break more. Especially if non-trivial.
2) It splits people. Suppose you
Andrei Alexandrescu seewebsiteforem...@erdani.org wrote in message
news:j5ge8v$2a0h$1...@digitalmars.com...
On 09/22/11 16:08, bearophile wrote:
Andrei Alexandrescu:
A function literal should be comparable to another for equality.
Are you willing to explain me why, and show an use case?
On Windows this is because Optlink (the linker DMD uses on Windows) doesn't
work
with 64-bit objects. On Mac OS, I don't know what the bottleneck is.
On Mac OS X bottleneck is 64bit Mach-O object file generation (there
is problem with load-command alignment).
On 09/23/11 10:40, pillsy wrote:
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s
article
On 09/22/11 16:08, bearophile wrote:
Andrei Alexandrescu:
A function literal should be comparable to another for
equality.
Are you willing to explain me why, and show an use
On 09/23/11 10:59, Adam Ruppe wrote:
I hope there's no D3 for a very long time. Maybe 2020.
There won't. D2 is our flagship.
Andrei
On Fri, 23 Sep 2011 12:20:21 -0400, Gor F. Gyolchanyan
gor.f.gyolchan...@gmail.com wrote:
Not qite.
I apologize, you are right that __ctfe is a runtime variable, but I find
that interesting.
An optimizer will (hopefully) remove any if(__ctfe) branches, so even
though it's evaluated at
Thank you so much for an objective reply! Of course i realize, that there are
more
important issues with DMD (i recently suggested not to implement enhancement
requests to free up time to fix bugs). What i suggest is, as you correctly
noticed, a very big task and i realize that it's not gonna be
oh, you mean the timing. I completely agree. D2 is far from being ready to let
go.
When i said D3, i meant in a galaxy far far away, where there's nothing left to
do
for D2. :-)
It's not a performance issue.
You can't do this:
if(_ctfe)
to!string(...);
else
toStringNow!(...);
because the toStringNow!(...) won't compile, because it's argument is not a
compile-time value.
about non-functional style templates:
When you have a complex computation in your templates,
Er, you answered a question about const with an answer about immutable. :\
My point is, what in the world does transitive const have to do with
transitive immutable?
Can't you have immutable(T) be transitive while const(T) being normal,
as in C/C++? If not, why not?
On 9/22/2011 10:36 AM,
On 9/21/2011 8:21 PM, Jesse Phillips wrote:
On Wed, 21 Sep 2011 10:15:31 -0700, Mehrdad wrote:
I can't find the thread, but I remember someone (bearophile?) mentioned
that the reason we have transitive const is to support purity.
I don't think I understand why this is necessary, though --
Gor F. Gyolchanyan Wrote:
Thank you so much for an objective reply! Of course i realize, that there are
more
important issues with DMD (i recently suggested not to implement enhancement
requests to free up time to fix bugs).
I was going to say, for someone who wants to stop work on
On Fri, 23 Sep 2011 21:21:31 +0300, Mehrdad wfunct...@hotmail.com wrote:
Er, you answered a question about const with an answer about immutable.
:\
My point is, what in the world does transitive const have to do with
transitive immutable?
Can't you have immutable(T) be transitive while
On Fri, 23 Sep 2011 14:15:25 -0400, Gor F. Gyolchanyan
gor.f.gyolchan...@gmail.com wrote:
It's not a performance issue.
You can't do this:
if(_ctfe)
to!string(...);
else
toStringNow!(...);
because the toStringNow!(...) won't compile, because it's argument is
not a
compile-time
Thanks! You've been extremely helpful! You're right, asking for existing
solution
before proposing a new one is much better.
I've been studying D2 for several months non-stop. I've been paying close
attention to all discussions on D newsgroups and bugfixes on every DMD release.
It's time for me
On Friday, September 23, 2011 11:15 Gor F. Gyolchanyan wrote:
It's not a performance issue.
You can't do this:
if(_ctfe)
to!string(...);
else
toStringNow!(...);
because the toStringNow!(...) won't compile, because it's argument is not a
compile-time value.
So, use a normal function.
On Friday, September 23, 2011 11:21 Mehrdad wrote:
Er, you answered a question about const with an answer about immutable. :\
I gave more reasons than just immutability.
My point is, what in the world does transitive const have to do with
transitive immutable?
Can't you have immutable(T) be
Of course, if the entire D gets CTFE-able, the __ctfe will be completely
useless.
But i can't see that coming for a long time. Most of the major programming
problems are best solved with classes and that's where CTFE stops.
About templates:
void unpackIntoFunction(alias arrayOfVariants, alias
On Friday, September 23, 2011 11:06 Gor F. Gyolchanyan wrote:
Thank you so much for an objective reply! Of course i realize, that there
are more important issues with DMD (i recently suggested not to implement
enhancement requests to free up time to fix bugs). What i suggest is, as
you
Agreed.
There are lots of dark-magic compile-time D techniques yet to be discovered.
Even C++'s templates, which are decades old, don't stop getting new usage ideas.
I'll stop making enhancement requests until I face a problem with current
language, which not even D.learn can help solve.
On
I don't see why immutability has anything to do with constness... would
you mind clarifying? Why does having transitive immutable also imply
that we /must/ have transitive const?
One man's variable is other man's const.
foobar(const(char)[] data)
{
}
immutable(char)[] data = ;
On 09/23/2011 08:21 PM, Mehrdad wrote:
Er, you answered a question about const with an answer about immutable. :\
My point is, what in the world does transitive const have to do with
transitive immutable?
Can't you have immutable(T) be transitive while const(T) being normal,
as in C/C++? If
On 09/23/2011 08:47 PM, Gor F. Gyolchanyan wrote:
Of course, if the entire D gets CTFE-able, the __ctfe will be completely
useless.
But i can't see that coming for a long time. Most of the major programming
problems are best solved with classes and that's where CTFE stops.
About templates:
On 09/23/2011 08:50 PM, Gor F. Gyolchanyan wrote:
But that will lead me to writing the same functions twice (making a template
version, actually). Again, if D becomes entirely CTFE-able, the topic can be
closed for good. :-)
What can template versions compute that normal functions cannot?
On Fri, 23 Sep 2011 14:47:32 -0400, Gor F. Gyolchanyan
gor.f.gyolchan...@gmail.com wrote:
Of course, if the entire D gets CTFE-able, the __ctfe will be completely
useless.
But i can't see that coming for a long time.
Well, anywhere that it makes sense, it should be CTFE-able.
For example
Damn I must have missed the discussion where __ctfe was introduced.
What exactly is this new symbol for? It should be put in the docs
unless it's there already (I can't find it).
On 9/23/11, Andrej Mitrovic andrej.mitrov...@gmail.com wrote:
Damn I must have missed the discussion where __ctfe was introduced.
What exactly is this new symbol for? It should be put in the docs
unless it's there already (I can't find it).
Looks like it's not new, but I didn't know about it.
Okay, David Simcha wrote some modules intended to form the basis for custom
allocators in D, and that code has been reviewed in the Formal Review of
region allacator begins thread. The review period has passed, and it's time
to vote on whether we want to include it in Phobos as-is or not.
On Fri, 23 Sep 2011 15:38:30 -0400, Andrej Mitrovic
andrej.mitrov...@gmail.com wrote:
Damn I must have missed the discussion where __ctfe was introduced.
What exactly is this new symbol for? It should be put in the docs
unless it's there already (I can't find it).
On 9/23/2011 7:35 AM, Trass3r wrote:
Which again raises the question why we have version at all.
They're meant for a more global view of generating different versions from the
same source code.
On 2011-09-23 18:05, Simen Kjaeraas wrote:
On Thu, 22 Sep 2011 11:22:10 +0200, Jacob Carlborg d...@me.com wrote:
auto newrange = filter!a5(map!2*a(range));
At first some people get the heebiejeebies when seeing string-based
lambda and the implicit naming convention for unary and binary
On Friday, September 23, 2011 12:59:20 Walter Bright wrote:
On 9/23/2011 7:35 AM, Trass3r wrote:
Which again raises the question why we have version at all.
They're meant for a more global view of generating different versions from
the same source code.
Not to mention that version blocks
On 2011-09-23 12:55:25 +0300, deadalnix said:
I recently faced a problem in java. I have lots of classes
inheriting from the same superclass. Thoses classes has to conform to
some behaviour expected when manipulation the superclass as Liskov
substitution principle says.
This is
On 9/23/2011 1:09 PM, Jonathan M Davis wrote:
Yes, we technically _could_ get rid of version and do it all with static ifs,
but it wouldn't be as clean IMHO.
Right. It's the same reason for the existence of the debug conditionals. Such
could be done with version or with static if, but
On Fri, 23 Sep 2011 18:28:21 +0200, dsimcha dsim...@yahoo.com wrote:
== Quote from Derek (ddparn...@bigpond.com)'s article
I've been out of the 'loop' with D for quite awhile now so I haven't
been
keeping up with current developments.
I will have a need for a decent 64-bit compiled language
yes
On 9/23/11, Steven Schveighoffer schvei...@yahoo.com wrote:
On Fri, 23 Sep 2011 15:38:30 -0400, Andrej Mitrovic
andrej.mitrov...@gmail.com wrote:
Damn I must have missed the discussion where __ctfe was introduced.
What exactly is this new symbol for? It should be put in the docs
unless it's
Adam Ruppe destructiona...@gmail.com wrote in message
news:j5iac7$2ole$1...@digitalmars.com...
I hope there's no D3 for a very long time. Maybe 2020.
I still hope there is one at some not-too-distant point, though. The whole
version system really does need an overhaul. One of the big things, if
BTW, since the latest revision didn't get much review, I recommend we allow
conditional yes votes. If you find some small issue that you think really
needs
fixing, I think it's perfectly reasonable to say something like yes, but please
fix X..
== Quote from Jonathan M Davis
On Friday, September 23, 2011 14:13 dsimcha wrote:
BTW, since the latest revision didn't get much review, I recommend we allow
conditional yes votes. If you find some small issue that you think
really needs fixing, I think it's perfectly reasonable to say something
like yes, but please fix X..
On Friday, September 23, 2011 14:14 Nick Sabalausky wrote:
Adam Ruppe destructiona...@gmail.com wrote in message
news:j5iac7$2ole$1...@digitalmars.com...
I hope there's no D3 for a very long time. Maybe 2020.
I still hope there is one at some not-too-distant point, though. The whole
If there'something that you feel the need to discuss with regards to the
region allocator vote, please discuss it in this thread rather than clogging
up the voting thread with discussions or commentary.
- Jonathan M Davis
1 - 100 of 186 matches
Mail list logo
